To JSF or not to JSF

21 Feb 2006 16:40 - (0) comments

Is learning JSF a waste of time? Of the people I personally know who have been using it extensively, most think it sucks. After listening to Tim Shadel's excellent podcast 'The 7-Layer Burrito I Won’t Eat Again', I'm convinced most of them are right.

Tim's points in short

In the podcast Tim takes an in-depth look at JSF. But in short it comes down to the following points.

Everything in JSF is a POST. Not having useful GETs breaks up the whole REST notion of the web and is silly for most websites. Bookmarks and back buttons stop working, and Google can't index your site (I wonder if the recent hoopla about BMW using special link pages for Google is the result of BMW using JSF).
There are ways to hack in GETs but all these hacks lead to applications with Broken Windows, not reusable and maintainable applications.

Another point Tim makes is that the views don't allow presentation logic. This means that presentation logic leaks into the model.

Tim also talks about the RenderKit layer. This layer should allow you to build a site for both a browser and a mobile phone just by switching the renderer. Since these sites have very different screen sizes and flows, only a handful of people would find it useful. This makes the RenderKit a useless layer that just produces ugly html.

Underlying problem

But all these problems are just symptoms of the underlying problem. All the succesful frameworks like Hibernate, Rails and Spring have been developed using real world experience. They have a strong focus on a real world problem they want to solve.

JSF is a typical example of design by committee: "Its defining characteristics are needless complexity, internal inconsistency, banality, and the lack of a unifying vision."

JSF wasn't meant to build highly interactive web applications quickly, reusably and maintainably. JSF was meant to attract Visual Basic programmers with little web development knowledge to the Java platform. It was meant to sell you products from toolmakers.

To quote CardSharp:

I‘m sure it started out with folks wanting a simple component-based web framework with a solid event model. Then someone from IBM decided that multiple-markup language support was a requirement, and someone from Macromedia thought that kick-ass VB tooling was important, then BEA wanted it to be more like .NET, ...

Instead of trying to solve specific problems based on real world experience, JSF wants to be the academic Golden Hammer. The resulting trade-offs can only result in a mediocre compromised solution.

On TheServerSide Cameron Purdy puts it less diplomatic:

1. Someone goes off an writes Struts, which is an abomination, but for some odd reason (kind of like MS DOS 3 beating MacOS in the market) lots of people end up using it, and most end up loathing it.

2. The same someone who wrote Struts feels like his/her technology was validated, based solely on the large number of poor souls stuck using it.

3. Unfortunately, the same someone who wrote Struts doesn't realize that Struts is a complete horror that makes Java look bad. Instead, he/she decides to build a bigger abomination, with roughly the same amount of input from people actually building web applications (read: zero).

4. Sun decides, after most of the damage was already done and baked in to "JSF", to make it a JSR.

If you are still unconvinced, even mcClannahan himself recognizes (40:00) that after a year there are relatively few public succes stories.