Web Framework Design: Standing on the Shoulders of Giants

Over the last couple of weeks, I started to toy with the idea of writing a web framework in Scala (as if the world needed yet another web framework..). Whether I go through with it, or just write some code over a few evenings before getting tired of it and/or balking at the size of the task is another matter altogether. We’ll see, it’s possible it’s yet another one to go into the drawer of “hair-brained ideas mr Faler never followed through on”.

Learning From the Best
My thoughts are not an indictment of the state current JVM web frameworks, apart from my obvious dislike of Struts and JSF, I think there are a number of very impressive frameworks out there.
In fact, I’d say that my thoughts are those of “a small man standing on the shoulders of giants”, to paraphrase Bernard of Chartres. At the same time, all frameworks (including any I write) will have some shortcomings and blind spots, simply because they are addressing a specific problem from a specific angle.

Why I’m Considering “Yet Another Framework”
The way I see it, there are 3-4 frameworks that really stand out for my tastes:

Apache Wicket is my long time favourite, and excellent in so many ways, in particular in writing stateful apps and being approachable for people with more of a grounding in OO than HTTP. However it’s distinct weaknesses are that it doesn’t play nicely with JQuery without serious bending over backwards, and that it above all is not very RESTful, because it has chosen to excel at being a stateful framework.

Lift is another framework I’ve looked at, while technically impressive, I’ll admit to not quite “getting it”: while it has some excellent ideas I’d be happy to pick off (even some libraries, like Lift-JSON), I find it lacks a coherent idea, and doesn’t seem to have an “opinion” on how to do things, in some ways, it’s flexibility is it’s downfall.

Play Framework is another contender, quite clearly heavily influenced by Rails, and in a good way. I’d be inclined to steal a bunch of ideas from Play if I where to write a framework: the way it has a Rails like approachability, scaffolding, embracing REST etc are all things I really like about it. What leaves me luke-warm though is that it has built it’s own build system (though parts of it obviously aid developer productivity a LOT), that it allows code in templates (I’m a big proponent of logic-less templates) and that “everything is a static”.

Where My Ideas Are Heading
Here are some of the thoughts of what another framework should bring to the table:

• Embrace REST, HTTP & AJAX: Embrace REST, HTTP & Ajax, allow easy use of any Javascript framework with a minimum of integration code (even better: make it simpler), and ideally provide a JSON over REST API “for free” in addition to the templating mechanism.
• Logicless templates (HTML, CSS & JS only for the client): People do stupid things with code in templates. The best way of stopping them is not allowing it. I’m thinking along the lines of using something like Scalate’s Mustache implementation.
• Focus on developer productivity: steal the best ideas from Wicket, Play and Rails, Wickets re-usability, Play’s & Rails lack of boilerplate in terms of having the framework do the heavy lifting for you, convention over configuration, a level of abstraction that allows for using the compiler to assert type-safety of your code.
• Embrace SBT (Simple Build Tool): Both Play and Rails have their own set of tools to generate things like Scaffolding. SBT is an excellent build tool, and like Lifty proves for Lift, you could write something similar to Rails and Plays tools, but as an extension Processor to SBT.
• Unit testability outside a container: Might be tricky/impossible for Javascript based UI logic, but should be possible for anything that isn’t Javascript based, including the whole “request cycle”.

As to the first point, I’m actually thinking almost along the lines of a “RESTful framework, that also happens to be good at webapps”.

Not Starting From Scratch
As far as I have thought about this (which isn’t very far yet), I’m not likely to “start from scratch”, in fact, I feel that I’m very likely to use a couple of other frameworks to build on top of:

• Scalatra: for HTTP abstraction and route definition
• Scalate: for templating, in particular it’s Mustache style templating, which is logicless.
• Lift-JSON: for JSON serialization/deserialization.
• SBT: Simple Build Tool, for building, with a few custom processors to enable scaffolding and other generation of boilerplate code.

I’m thinking by using the work of others, as well as picking of the best ideas from other frameworks creating something useful shouldn’t be too hard.

Of course if and when I do write something, it will have it’s fair share of weaknesses and blindspots like any other framework, simply because of the trade-offs and choices made. I’m hoping though that those trade-offs will be chosen knowingly, rather than by accident.