Why the bias against JSF?
In my last post about InfoQ's Top 20 Web Frameworks for the JVM, I received a thought-provoking comment from henk53:
There is one little thing that does bother me in those presentations, and that's your fairly obvious bias against JSF.
...
If you are presenting yourself as, more or less, an authority on comparing web frameworks, then having a fairly obvious biased against one of them is just peculiar. I, all of my team, and various clients distrust your ranking of JSF. We do look at your data if the choice is between other frameworks, but as soon as JSF comes into the picture we just look elsewhere.
I'm not really sure where this bias comes from. Yes, JSF 1.0 sucked and 1.2 was only marginally better, but 2.0 is really cool and productive and there are SUPERB component and utility libraries now like PrimeFaces and OmniFaces. As a researcher of this topic I think you should keep up the date and not stick to some old grudge.
This is true, I am biased against JSF. It all started with my first JSF experience back in August 2004. If you remember correctly, 2004 was a big year: JSF 1.0, Spring 1.0 and Flex 1.0 were all released. The "AJAX" term was coined in early 2005.
By 2007 and 2008, JSF still hadn't gotten any better. In late 2009, JSF 2.0 was released and I upgraded in March 2011. As you can see from the aforementioned post, I ran into quite a few issues upgrading. JSF was also the hardest one to get working with extension-less URLs.
Most of my issues with JSF come from having maintained an application built with it since 2004. If I were to start a new application without any legacy migration issues, I imagine it wouldn't be as difficult. However, if you compare it to Struts 2 and Spring MVC, I've had little-to-no issues upgrading those applications over the years.
Also, I'm not just biased against JSF, but most component-based web frameworks. Just ask the Tapestry and Wicket folks. They've felt my criticisms over the years. My reason for preferring request-based frameworks like Struts 2/Spring MVC and Grails/Play has been because I've never seen the appeal in component-based frameworks. Often I've found that their components are just widgets that you can get from any decent JavaScript framework. And chances are that JavaScript framework can work with any web framework. Also, I've worked on a lot of high-traffic web applications that require statelessness for scalability.
I see the value in component-based frameworks, I just don't think components should be authored on the server-side. Most of the Java-based component frameworks require 2+ files for components (one for the component, one for the view, possibly one for the config). I love GWT's component concept in that you can just extract a class and re-use it. With JS frameworks, you can often just include a script. These days, when I think of good component-based frameworks, I think of jQuery UI and Twitter Bootstrap.
All that being said, there's a lot of folks praising JSF 2 (and PrimeFaces moreso). That's why I'll be integrating it (or merging your pull request) into the 2.3 release of AppFuse. Since PrimeFaces contains a Bootstrap theme, I hope this is a pleasant experience and my overall opinion of JSF improves.
In other component-based frameworks in AppFuse news, Tapestry 5 has gotten really fast in the last year. I imagine this is because we have a Tapestry expert, Serge Eby, working on it. And we're planning on adding Wicket in the 2.3 release.
So even though I prefer request-based frameworks with REST support and Bootstrap, that doesn't mean everyone does. I'll do my best to be less-biased in the future. However, please remember that my view on web frameworks is as a developer, not an analyst. And aren't developers supposed to be opinionated? 
"I see the value in component-based frameworks, I just don't think components should be authored on the server-side."
Totally agree. Having been working with JSF (ADF Faces) for 5 years, I really think it is the wrong direction. Spring MVC is my favorite, it is much simpler and easy to maintain.
Posted by Yuan Ji on November 08, 2012 at 04:52 PM MST #
Matt - IMO you worry too much about Henk's comment. He single-handedly posted the most comments on my blog in all its years of existence, all of them attempting to defend JSF, in a most verbose and argumentative manner. If he thinks you are biased, by the same yardstick he can be considered a rabid fanatic or clinically insane.
While I've disagreed with some of your opinions on Wicket in the past, I fully agree with your assessment of JSF. My opinions have changed on some things, just like yours have - all good developers keep an open mind and really don't hold any grudges or biases - in fact I use less of Wicket nowadays and feel that client- side JS is the way to go.
But however hard I tried to find JSF a compelling choice, it just didn't click for me.
Posted by Peter Thomas on November 09, 2012 at 02:59 AM MST #
Bare bones JSF 2.0 is still not up to the job in my opinion. JSF + Spring WebFlow + RichFaces/PrimeFaces on the other hand is a combination, that makes AJAX ridiculously simple, takes care of conversations and their state, and doesn't even demand boilerplate in return. Alas, these amenities only extend to XHTML. Presenting PDF, documents and spreadsheets etc. isn't really convenient.
Enter Spring MVC: The choice of the output format is reduced to a configuration entry or an annotation. Even introducing a new format isn't exactly rocket science.
So, I would base my choice of web framework on the application's focus: input = JSF, reporting = Spring MVC.
I limit my choice to these two options, because they are the ones that take I18N and L10N seriously. Just allowing to use ResourceBundles isn't enough for that.
Posted by Frisian on November 09, 2012 at 06:51 AM MST #
Although I'm more or less on the same page, the choice of technology highly depends on the needs (and skills/knowledge of the programmers).
For an internal, web based, application I probably would use JSF 2.x however for high-traffic, stateless web applications I still prefer request-based frameworks with client-side JS (or maybe server-side javascript with the NodeJS / Vert.x movement nowadays).
Posted by Marten Deinum on November 09, 2012 at 07:56 AM MST #
Posted by Sakuraba on November 09, 2012 at 08:41 AM MST #
I can't argue with the experience you obtained with those older versions. When 1.0 came out, and we only had the bug-ridden Sun implementation and no available examples or guides for best practices, I was a JSF hater too.
Regarding your upgrade experience, ajax4jsf was probably not JSF 2 compatible. Using RichFaces 4 instead should indeed solve that. Seeing what a major change JSF 2 was, I personally think the upgrade issues you encountered are relatively mild, but maybe that's just me.
Extension-less URLs are rather simple with the help of OmniFaces, see ExtensionlessURLs - OmniFaces Showcase and org.omnifaces.facesviews
One thing to note about components is that they are not necessarily about state. In fact, there's nothing in JSF's component model that demands it. That said, several component authors do use it too carelessly and put silly things there that are not strictly needed. The entire concept of state handling is one of the last big things that I know of that is still open in JSF for revision. (partial state saving did greatly improve the situation in JSF 2.0, but there's still more to be done) See JAVASERVERFACES_SPEC_PUBLIC-1055 for some more details about that.
Overall I think the amount of criticism against JSF largely dried up after 2.0. Before that there were tons of articles about how bad it all was (Peter Thomas admittedly did a great job of collecting a fair amount of those on his blog). After 2.0 I've seen very few of those and the ones I did see were often from people who weren't even aware of 2.0 and assumed nothing ever changed.
You are also right that much of JSF 2's popularity is because of PrimeFaces, but don't forget it always has been the goal of JSF to allow such a component library to be created in the first place.
@Peter
Nice to hear from you again, it's been a while ;)
Posted by henk53 on November 09, 2012 at 10:36 PM MST #
Posted by Bruno Borges on January 09, 2013 at 03:10 PM MST #
Hi there,
congratulations! This is one of the best and most inspiring blogs on the what-is-the-best-java-web-framework topic I ever found.
All the comments here helped me a lot to find orientation in what framework I should choose. I also tried to use JSF2 for my project (which has lots of database stuff in) but I resiled to use it because of all that MVC stuff around which I think is a big (and not neccessary) overhead.
Alex
Posted by Alex on April 06, 2013 at 03:24 PM MDT #
JSF fanatics have all the answers to every technical problem you throw at them. But they can not deny the fact that using JSF slows down the productivity of a team, by at least a factor of 3.
I am involved in several projects on different companies for 3-4 years now. All of them either regretted their choice later, or were so impressed how much productive they became to be when they switched to simple request response frame such as Sprinv MVC.
I hate JSF with a passion. It makes you stuck with a problem that you don't know how to solve and how much time you will solve it. 1 hour? 1 day? 1 week? 1 month?
Posted by John on February 14, 2014 at 02:15 PM MST #
Using component based framework is over engineering in my point of view. Even simple things that happens in real world application, you need to hack the framework to make it work. Things are hard, and you need to read so much materials before you can be any good.
With request response, every thing is easy. The features you need to do are straightforward. You don't get stuck with any problem, because there is no added complication, and the flow is so simple.
Sorry for commenting again, I really hate JSF with a passion that's why. My perception is that only companies with so much money to burn uses JSF as framework. Those that can hire so much resource programmers, and time is in their hands.
Posted by John on February 14, 2014 at 02:15 PM MST #
I do not agree with John about JSF being only suitable for large companies.
I had a very small project with Search/Edit/View pattern (rather than long Workflows). We managed to use JSF 1.2 back at those times because of time constraints.
We even had a separate Web Designer who were designing the pages in pure HTML and we managed to feed them directly to our JSF pages.
We had a small team, very tight budget and that specific usage pattern. And I am sure we made the correct choice on the technology. JSF saved us a hell lot of time by making us productive in a very short matter time.
All being said I felt by my bones all the pains in JSF 1.2 (integration with Ajax, other JS libraries, mixing the logic and layout, etc.).
So, although the Component-based model seems like a paradox in Web, it brings us with high reusability that we knew from rich-client desktop applications.
Posted by Ali on April 07, 2014 at 01:22 AM MDT #