Web framework comparison - Prototyping

Some may say I have a biased opinion on the topic at hand. True. I hereby declare that I have a clear preference for dojo+DWR+Spring MVC. But I happen to have a cruel client as well and when they asked me to prepare a comparison between several modern web frameworks they purposely left Spring behind. The aim here was to build quick prototypes of enterprise applications to test new ideas proposed by the business people. Obviously they current architecture is a little bit outdated and not suitable for the task.

They gave me a blank sheet to start although they did mention Ruby On Rails and GWT. The first one was in the origin of everything, a new board member had recently joined the company and in his former position they were using RoR for the task. The second was probably due to the fact that several projects had spawned recently with Flex+BlazeDS as the client side technology but noone was really sure if it was the right path.

Given this requirements I selected Seam, AribaWeb and Grails as well.

Obviously this is not an apples-to-apples comparison. Ariba and Seam are both full Java stacks. RoR and Grails are server side backends very oriented to relational database repositories. While GWT is a RIA tool to layout views in pure Java with some communication middleware, like say, dojo+DWR or, as already mentioned, Flex+BlazeDS could be.

But it makes for an interesting analysis anyway.

The criteria to elect the champion contain the following points:

• Learning curve
  We are talking about three hundred programmers that haven't ever coded in anything but JSF 1.1. Let's make the jump feasible.


• Prototyping
  How suited for the task is the project? A scripting language seems better to throw something quickly even though it's not maintainable later. On the other hand, a good IDE with good component integration, a drag'n drop visual editor and a preview screen makes stupidly easy to churn pages.


• Productivity
  How good are the APIs and third party libraries? How much code and configuration is needed to kick start a project? How easily is to connect client and server development?


• CRUD
  Enterprise applications today always need to interact with a persistent backend.


• Killer features
  Selling points for the upper management. What does this framework better? Where does it really shine? What unique characteristics does it put on the table?


• Weakness
  And what about these...?


• Maturity, popularity
  Is it a safe choice? Will it be around in the not so distant future?

There were others but neither as interesting (licensing, standardization) nor useful to you (migration, code reusability) so these make a good list. I'm not posting the tabular data for two reasons, first it depends heavily on the weights you assign to each column and second it's subjective and I don't want to start a flame war.

But here are my personal conclussions.

In the first round both RoR and GWT fell off the roaster but for very different reasons. In the case of RoR it scored very well in every technical category but, even if I could use it, the truth is a company like this is pretty commited to Java/JEE and such a rupture means time and money. And they're both scarce this days. Maybe for highly innovative teams in core areas but not as a general purpose tool. GWT didn't fare equally well. First for a RIA builder it lacks a decent widget library. Then I like DWR remoting better(biased again?). And finally it shuns standards like a plague. With this conditioning you're better served by Flex. Any day.

The second round saw, and this was a suprise, Grails fail. Grails happens to have the same punch as Rails and then some more. A great ORM that simplifies greatly CRUD operations (nothing really can beat code generation and a book.save()), scripting capabilities, joint compilation, Spring et al. Unfortunately it lacks a matching client plug-in. Flex is not there yet and dojo is too much work for a solution specifically looking for speed of development. The syntax is concise but many times awkward and in general Groovy/Grails still lack maturity (IDE support is minimum, plug-ins quality varies greatly, too many bugs yet). I guess you get used to Java's 24 months release cycle with bullet proof quality. Groovy is different in this aspect. I have good feelings about it (more with SpringSource behind the projects) but it takes time.

The two final candidates provide the full stack, client and server. Seam is IMHO more powerful and a safer choice in general. The people behind Seam are the same that participate in several JSRs and other high profile projects like Hibernate. JBOSS has always been a very active OSS player and the quality of the components (EJB3, Richfaces, JBOSS Tools, Hibernate) is out of question. There's very little bad I can say about Ariba. It's new (very new) in the OSS space and the look&feel is not spectacular (subjective I know). That last bit was important because you want the wow factor when showing a innovative project to the final user. I have to admit that JSF weighed in favor of Seam here but in the end it was a worthy winner for us this time. Kudos to them!

Book review - Spring Web Flow Web Development

This article was promoted to JavaLobby as well

Right now there are two trends to develop web applications, either you choose the RIA model or a conversational approach. In the former, say Flex with Cairgorm, both the model and the state is handled by the client. In the later, the server manages the scope sending a view to the browser which acts as a renderer. Of course, interactivity has improved over the years and nowadays partial requests are a must to improve user experience. Spring WebFlow is the SpringSource approach to a server side (work/page) flow management for web applications and Spring Web Flow Web Development, the book, (I could think of better names!) tries to explain how to leverage it.

The task is not minor because, let's face it, Java is a very complex platform and to start with WebFlow you should have a good understanding of JEE (at least JSF and the Servlet APIs), Spring and MVC in general. AJAX is welcome as well. The book, of course, can't help you there (you'd need a whole collection for that). This is not for novices! Fortunately a lot of people have learned JEE and Spring through the years and it's a matter of learning Webflow step by step but in depth.

Now, here the book shines. I like the formating, very clear and clean, and the language, simple and direct. I would have changed the chapter structure a little though. I missed individual chapters for persistence (Security has one) and Spring MVC (Faces has one) and I would have reordered some things here and there (configuration is scattered) but that's subjective and overall the steps make sense. The concepts (flow, action, state, transition, continuation) are well defined and you get a grasp pretty soon but some times the book is too comprehensive like when enumerating the methods and fields of the available variables (messageContext, flowExecutionContext et al). This makes for a hard reading but it will be invaluable as a reference book to some. I prefer IDEs for that task though. In the same sense I missed more diagrams and graphs (I'm not referring to UML class diagrams here). In a book about flows it should be pretty easy to plot concepts using some circles here and there. In my mind, circles are not less valuable than XML snippets (the book has tons of these don't worry) and the reader will gladly accept some pictures to clarify concepts (and thank you for them). Nothing too fancy, this one (extracted from the book) is more than enough:


In summary, the book is extensive and a great tool to learn first, and as a reference guide later, to Spring Webflow. It's dense and it explains lots of concepts in depth. Be warned that to extract all value this book requires previous knowledge of complex notions, among them: Spring, JSF, AJAX, persistence/ORM, Security, unit testing and probably more. The authors have made the effort to introduce all these libraries/skills when they're first used but that just lessens the burden (a bit). All in all, an easy candidate to recommend to those who need to extract all the power that Webflow 2 has to offer or teams that are about to start a new project and need an initial push with the technology.

PhoneGap, my new toy

The best thing about being a consultant is the fact that you have to work for different clients and different projects all the time. My last assignment included a lot of Flex and, now, mobile development.

Being a lazy developer, as I am, I tried to find similarities with web development which, well, feels comfortable. PhoneGap is a OSS project to build cross-mobile (native) applications using the familiar HTML/CSS/Javascript stack. It currently targets Android, iPhone and BlackBerry. This last one was the most important for me this time and, unfortunately, the one that was lagging behind, with a poor overall situation (the maintainer had abandoned development).

No problem, that's the beauty of Open Source development! A quick look at the code (because that's actually the best available documentation) and I got a good idea of the intents both in iPhone, the core platform, and BlackBerry. It seemed that many lines were copied from the BlackBerry documentation and did not serve any obvious purpose. Given that the current code was failing to execute in the simulator I started to refactor...here and there, you know? By the afternoon I had a preview version with a Javascript Hello World and I was pretty happy. I sent the code to the PhoneGap team and got a warm welcome and some advice. Another day and I've been able to submit to the mailing list a working implementation of part of the API: telephony, vibration, location (GPS) and device information. Not bad for a couple of days! Even more so knowing it was my first mobile development ever (a fellow co-worker had to show me the use of the simulator...endless shame).

And now for Windows Mobile...a much bigger job given that there's no code to start with. An implementation from scratch and with C#. Too daunting a task indeed! Let's see how it turns out.