Wille Faler is an experienced software developer, architect and agile coach with experience across a number of different industries as an independent consultant. Wille specializes in backend, integration, and Java technologies, but has more recently found a passion for Scala and text mining/analysis. Wille is a DZone MVB and is not an employee of DZone and has posted 42 posts at DZone. You can read more from them at their website. View Full User Profile

Web Framework Design: Standing on the Shoulders of Giants

12.06.2010
| 7097 views |
  • submit to reddit

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.

References
Published at DZone with permission of Wille Faler, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Richard Kennard replied on Mon, 2010/12/06 - 8:20pm

Wille,

A recent lively discussion here on DZone (link) saw Jonathan Locke (of Swing and Wicket fame) and Andrew McVeigh suggesting it might be possible to design a better UI framework using the unique features of other languages (such as Scala traits).

Specifically, one could avoid the dilemma of 'abstract base classes are too limiting' versus 'granular interfaces are too cumbersome'. I would be very interested in such a framework for Metawidget.

Just a thought.

Richard.

Michal Gruca replied on Tue, 2010/12/07 - 4:54am

Hi Wille,

if you like Wicket then you should also like Tapestry 5. About 2 years ago I was deciding between those two and found that Tapestry had all you wold like to have in Wicket.
You won't find in it rails scaffolding level but nevertheless it is component framework that has some default components that gives a big boost to productivity.

As for my best knowledge it gives everything you mentioned in your ideas + it has community providing support. If you like scala then I recall that there was blog that described how to use scala with Tapestry 5.
Regards
Michał Gruca

E Micklei replied on Tue, 2010/12/07 - 11:59am

Hi,

How about not using templates at all? and writing all components in plain Java? A few months ago, I started writing such a library motivated by the increasing complexity that I saw with using JSP. I took some ideas from Seaside and created a new project called renderSnake.  It plays nicely with jQuery and because it is all Java, you can use all the power of the language (inheritance, type safe, composition) and your IDE (refactoring, unit testing). As a first proof of concept, I build the site using this technology (eating my own dog food).

Wille Faler replied on Wed, 2010/12/08 - 8:51am

Richard: Thanks for the tip, will check it out! I'm definitely on the same page as Jonathan Locke when it comes to trying to stick to "micro-architectural principles". Coming from a Java world with interfaces and abstract classes, I'm still trying to get my head around where Scala traits with partial implementations best fit in, though I can definitely see them as a useful tool to "decorate" implementation classes with default behavior in cases where something required for a context is missing/desirable, for instance: val myController = new MyController with ValidatingBehavior (not a great example, but shows how you can do decoration with traits in Scala without having to have MyController explicitly extend ValidatingBehavior).

Jose Maria Arranz replied on Thu, 2010/12/09 - 4:57pm

Take a look to ItsNat

* Embrace REST, HTTP & AJAX and allow easy use of any Javascript framework

 REST is not the focus because ItsNat is server centric but it is strongly based on AJAX, in fact, ItsNat promotes Single Page Interface (SPI) web sites (that is, no reload, like Twitter, Google or FaceBook) SPI not only for web applications.

 In spite of ItsNat is a server centric framework, integration with JS frameworks is very easy because you have absolute control of the HTML layout, and the framework in no way uses id, onX, class... attributes. You can inject new JS code from server because all AJAX events return JavaScript code.

  Take a look to this demo of a real time auction site mixing jQuery (for visual effects) and ItsNat (for anything else)

* Logicless templates (HTML, CSS & JS only for the client)

 In this game the only players are Wicket and ItsNat (do you really think Moustache templates are clean of logic?), and ItsNat is 100% plain HTML/JS (or SVG or XUL or any inline/embedded option including MathML), no custom tags. Because the logic is Java W3C DOM.

* Focus on developer productivity

 This is not a strong feature of ItsNat because it is intentionally a low level framework, said this, because logic is in Java (or in your favourite JVM based language) you can reuse view logic as you want, in fact ItsNat components do not include HTML because many different layouts can be attached to the same component (an example of reusing).

 The main advantage of a low level framework is meanwhile you are stopped trying to fit your special feature required for your application/site in a higher level framework, in ItsNat you know how to do it if you know HTML, JS and DOM (in this case the code is in Java W3C DOM) with or without the help of your favourite JS framework if you need some cool movement of timed visual change.

* Embrace SBT (Simple Build Tool)

  Scaffolding for Single Page Interface web sites?

* Unit testability outside a container

 Try with this example:

http://www.innowhere.com:8080/itsnat/feashow_servlet?itsnat_doc_name=feashow.main&feature=feashow.comp.functest.notBrowser.default

 To understand what is behind the scenes read the explanation and see the source code and try with the browser based version:

http://www.innowhere.com:8080/itsnat/feashow_servlet?itsnat_doc_name=feashow.main&feature=feashow.comp.functest.usingBrowser.ex

Enjoy

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.