December 19, 2005

Tapestry or JSF

I admit it. In two years, from when I started evaluating best web application frameworks for my current (big) employer and later on finishing two JSF based applications, I've become a JSF guy. It's been fun to learn it and after some years of hacking with Struts, JSF felt it was light years ahead. However, the journey hasn't been without considerable uphills and struggles with oddities in JSF spec and implementation. Mostly, I've been okay with dropping to request/response level and working around with problems like loosing messages with redirect, filter interaction with JSF lifecycle and so on, but recently I've been more and more wary about performance and scalability of JSF. And don't get me wrong. With any decent architecture, the bottleneck is almost always the database, so most of the time it doesn't matter if supporting a better UI frameworks takes a few more CPU cycles or a little bit more memory. Furthermore, if you only plan to support only a few hundred simultaneous users (for perhaps a few thousand or tens of thousand total users) any single box (Opteron :) server can handle the load just fine. (Proved by back of the hand calculation: average time to serve a JSF page with database access around 10-50ms -> ~30 request / sec -> ~100 000 request / hour).

However, with the raise of AJAX (you know, it's NOT news but I've been suckered into the hype and let's just stick with the AJAX name so everybody knows what I'm talking about) and exponential increase in the amount of HTTP requests hitting the server, the careless object creation and memory consumption in JSF has started to worry me. Meanwhile I keep reading studies about performance of hyper-cached Ruby on Rails and scalability of simple PHP and have "seen the light" with custom IoC frameworks such as Spring. I've always been doubtful about JSF promise of multiple renderers to support any given client. All the additional built-in flexibilty in JSF adds unnecessary layers of abstraction with little benefits if most people will still use it for rendering HTML. In addition, having made a few JSF components, I can only note its way too cumbersome and error-prone to foster lively environment for custom components.

Enter Tapestry. Originally, in my evaluation of web application frameworks, I dismissed it not because of lack of features, but its too small userbase. JSF seemed to offer functionality in-par with Tapestry, tool support and additional extensions points. Tapestry is much more streamlined and focused than JSF. Building a component tree is simpler because you cannot add or remove components to it runtime, which in turns makes it possible to use cache aggressively and allows for much simpler architecture: everything you need, nothing less, nothing more. But Tapestry is very much one man show. Not to say it's necessarily bad, the biggest innovations often comes from a sole contributor that has the vision, but even still, how viable option Tapestry really is in the future? With that in mind, I started doing *a lot* of research, comparing Tapestry to JSF and other frameworks. I read everything I could find from the web, the mailing lists, the discussion, the articles and whatever I could get to from Google and via links posted as comments in tiny little blogs. Also with countless times, I abandoned Tapestry for whatever reason, but always came back to it.

I actually wanted to write this blog entry for others to make their research easier. The five best comparative studies on Tapestry and JSF I coud find are:
http://www.theserverside.com/articles/article.tss?l=JavaOne_Day4
http://www.theserverside.com/articles/article.tss?l=JSFTapestry
https://equinox.dev.java.net/framework-comparison/WebFrameworks.pdf
http://wiki.osafoundation.org/bin/view/Projects/WebFrameworkComparison
http://sandbox.sourcelabs.com/kosta/web_ui_compare/readme/index.html (with some performance comparisons!)

Of course, not to forget Howard's own comments on the issue. He's biased, naturally, but his opinions are well justified:
http://howardlewisship.com/blog/2005/02/tapestry-jsf-and-fud.html

When I started with Tapestry, I used all kinds of starter apps: from clean Tapestry project and Tapestry sample apps to Raible's AppFuse with Tapestry. However, by far the best I've seen is Trails. The efficient use of annotations and auto-generated pages do help and increase the speed of development a lot. Now the concept in JSF Facelets as well as Shale Clay are very similar to Tapestry, but it might take a long while either project reach the maturization level of Tapestry/Trails. I've seen some performance tests and comparison with Tapestry, but not a single good one for JSF. Anyone? Anyway, for now at least, I'll be using Trails and reconsider JSF-based solutions once (and if) they catch the lead of Tapestry.

Posted by thoughts at 02:29 PM | Comments (5) | TrackBack