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?