Web frameworks, aka low hanging fruit.

I was reading Shannon Behrens's post about how everyone writes a web framework.

I think he hit the nail on the head. Web programming feels like a cesspool of knockoffs and "me-too" developers. Of course, brilliant people throw their hat in every now and then, but the overwhelming noise drowns it out.

I think there are a few types of framework creators. Those that have written a few applications of the same form and evaluate how to make similar jobs easier by abstracting part of the coding away. I've written a framework like this once - for interfacing a hospital registration system. These sort of frameworks are generally very useful, and have very limited use cases. On the other hand there's the J2EE style framework. A bunch of people with some minor experience in the project domain get together and attempt to predict every situation their framework could ever be used in. I've had the unfortunate experience of using a framework like this once, and I will never do it again unless I'm literally starving and it's the only job I can get.

The third example of what gets called a "framework" is really a domain specific language. Ruby on rails, while probably the leading example of this, is not really a good demonstration of this power. A good domain specific language will allow non-programmers to believe they are scripting the system, while hiding the abstractions so far that they never leak. Visual Basic 6 is a good example of a well implemented domain specific language, and I haven't really seen a comparable example in the web framework market.

Anyway, I'm starting to get off topic. I wanted to concur, the reason we see so many web frameworks is that it's such low hanging fruit. I had to code a web server as a 2 week homework assignment once, most web-frameworks I've seen really aren't even as complex as a web server.

Back when I was an undergraduate it was all the rage for professors to say dumb things like "Your projects must have a web component." Apparently, they thought this was somehow harder than writing a high quality GUI app (using unexplainable logic). Usually we'd hear motivations like, "It's a good exercise, you will learn sockets." Sockets! Sockets!?! You heard me right, they thought we'd end up using sockets to write our web based programs. And you know what the worst part is? We did.

Here's how the discussion on such a project normally went. Hey guys, we need to throw together a web component, what language is everyone familiar with? Java Java Java C++. Ok well, C++ is out, so Java it is. Alight, does anyone know any Java tools for building web pages? "Uh, I sort of know JSP." Ok, then lets discuss the requirements. 45 minutes later we finally re-invented a login system (much to my annoyance... everyone loves rambling about web authentication). Then we'd move on to the database layer we'd spend an hour debating and my push for ORM's would always win (which I would then be responsible for creating). Then the core application structure would come up. Because of the requirements we'd make a 3-tiered architecture and me and the other smart kid on the team would pretend it was completely designed after a while and adopt responsibility.

Then came coding time, this is where the story gets interesting. I'd go to make the ORM. Mind you, while I've never been entrenched in the Java "frameworks" field, I'm aware things like "A library that converts my database into usable stuff" should exist. Of course, due to Java's dead-code static nature, I now realize it can't exist (making new types on the fly? hah). I'd spend 30-40 minutes looking at the current "trendy" database technologies, before realizing it'd take me longer to figure out the "framework" than it would take me to just write hand-rolled code for our 15 domain objects, further my code would make more sense to the rest of the team, as it matched our domain modelling discussions.

Then we'd move on to the "framework-y" bit. The glue code that handled web requests and sent requests to the database server. Every time we ended up using raw sockets. Not that we didn't look to see if someone else had written a better "web" framework, we always did. And after an hour of looking we came to the conclusion none of them could possibly be productive, and we'd just hand-roll something ourselves. In one project we used a session id based session manager, completely hand rolled. It took me about 5 hours to put everything together including the hand-rolled multithreaded server. All of this I of course considered a phenomenal waste, but there were really no better options. On the other project we used a python script to generate C# classes from a description of our over the wire protocol. This was a much better solution, and I was generally pretty happy with how that project turned out.

So after all that, I'm qualified to write a web framework, right? Obviously not. Yet, if I had a bigger ego and no self control, I'd get tapping away right now to release my new and improved web framework to the world. Naturally, it wouldn't solve any of the hard problems (how to separate presentation logic from HTML/Javascript crap code being the hardest), but it would undoubtedly be a "web framework."

As an afterthought I just noticed why all web frameworks aren't. They usually try to solve a few problems at once, in the same language. This is obviously not going to raise the level of thinking - Java describes Java, Java doesn't describe a ORM. An ORM can be built using Java, but to say Java does anything but allow it to happen is overstating Java's readability.

On the other hand, after our very successful over the wire code generation on our second project, I'm now thinking perhaps a framework should be about code generation. I cited two really annoying parts to program, both where I had to map a list of nouns to Java. The ORM transforms databases into objects that represent the domain model. I am fairly sure a very strong domain specific language that generated Java/C#/... code would be a perfect match here. And of course the wire stuff was already solved by us using a code generator / DSL.

PS: On one project we used Java beans for authentication, which worked semi-acceptably... it was only 150 loc to say "this app needs authentication". On the other app I think he hand-rolled authentication, though I wasn't involved.

Sean