The BalusC Code: Disadvantages of JSF, a bit of history

This is a copy of my answer on stackoverflow.com.

JSF 2.0 disadvantages? Honestly, apart from the relative steep learning curve when you don't have a solid background knowledge about basic Web Development (HTML/CSS/JS, server side versus client side, etc) and the basic Java Servlet API (request/response/session, forwarding/redirecting, etc), no serious disadvantages comes to mind. JSF in its current release still need to get rid of the negative image as it was grown during the early ages. In the history there were indeed several serious disadvantages.

JSF 1.0 (March 2004)

This was the initial release. It was cluttered of bugs in both the core and performance areas you don't want to know about. Your webapplication didn't always work as you'd intuitively expect. You as developer would run hard away crying.

JSF 1.1 (May 2004)

This was the bugfix release. The performance was still not much improved. There was also one major disadvantage: you can't inline HTML in the JSF page flawlessly. All plain vanilla HTML get rendered before the JSF component tree. You need to wrap all plain vanilla in <f:verbatim> tags so that they get included in the JSF component tree. Although this was as per the specification, this has received a lot of critism.

JSF 1.2 (May 2006)

This was the first release of the new JSF development team lead by Ryan Lubke. The new team did a lot of great work. There were also changes in the spec. The major change was the improvement of the view handling. This not only fully detached JSF from JSP as view technology, but also allowed developers to inline plain vanilla HTML in the JSF page without hassling with <f:verbatim> tags. Another major focus of the new team was improving the performance. During the lifetime of the Sun JSF Reference Implementation 1.2 (which was codenamed Mojarra since build 1.2_08, around 2008), practically every build got shipped with (major) performance improvements next to the usual (minor) bugfixes.

The only serious disadvantage of JSF 1.x (including 1.2) is the lack of a scope in between the request and session scope, the so-called conversation scope. This forced developers to hassle with hidden input elements, unnecessary DB queries and/or abusing the session scope whenever one want to retain the initial model data in the subsequent request in order to successfully process validations, conversions, model changes and action invocations in the more complex webapplications. The pain could be softened by adopting a 3rd party library which retains the necessary data in the subsequent request like MyFaces Tomahawk <t:saveState> component, JBoss Seam conversation scope and MyFaces Orchestra conversation framework.

Another disadvantage is that JSF uses the colon : as ID separator character to ensure uniqueness of the HTML element id in the generated HTML output, especially when a component is reused more than once in the view (templating, iterating components, etc). Because this is an illegal character in CSS identifiers, the CSS developers would need to use the \ to escape the colon in CSS selectors, resulting in ugly and odd-looking selectors like #formId\:fieldId {} or even #formId\3A fieldId {}.

Also, JSF 1.x didn't ship with ajaxical facilities out of the box. Not really a technical disadvantage, but due to the Web 2.0 hype, it became a functional disadvantage. Exadel was early to introduce Ajax4jsf, which was thoroughly developed during the years and became the core part of JBoss RichFaces component library. Another component libraries were shipped with builtin ajaxical powers as well, the well known one being IceFaces.

About halfway the JSF 1.2 lifetime, a new XML based view technology was introduced: Facelets. This offered enormous advantages above JSP, especially in the area of templating.

JSF 2.0 (June 2009)

This was the second major release. There were a lot of technical and functional changes. JSP is replaced by Facelets as the default view technology and Facelets was expanded with capabilities to create custom components using pure XML (the so-called composite components). Ajaxical powers were introduced in flavor of the <f:ajax> component and like which has much similarities with Ajax4jsf. Annotations and convention-over-configuration enhancements were introduced to kill the verbose faces-config.xml file as much as possible. Also, the ID separator character : became configurable. All you need to do is to define it as init-param in web.xml with the name javax.faces.SEPARATOR_CHAR and ensuring that you aren't using the character yourself anywhere in client ID's, such as -.

Last but not least, a new scope was introduced, the view scope. It eliminated another major JSF 1.x disadvantage as described before. You just declare the bean @ViewScoped to enable the conversation scope without hassling all ways to retain the data in subsequent (conversational) requests. A @ViewScoped bean will live as long as you're subsequently submitting and navigating to the same view (independently of the opened browser tab/window!), either synchronously or asynchronously (ajaxical).

Although practically all disadvantages of JSF 1.x were eliminated, there are JSF 2.0 specific bugs which might become a showstopper. If you track the currently open JSF 2.x issues, you'll see that relatively a lot of them are related to the sometimes unintuitive behaviour of <ui:repeat> and the new partial state saving implementation, which in turn often only exposes in relatively complex views. Also, the @ViewScoped fails in tag handlers due to a chicken-egg issue in partial state saving. Most of those are however workaroundable. With the upcoming JSF 2.2, a lot of those issues should have been fixed.

With JSF 2.0, more nice-looking component libraries were born, among others PrimeFaces and OpenFaces.

Component based MVC vs Request based MVC

Some may opt that the major disadvantage of JSF is that it allows very little fine-grained control over the generated HTML/CSS/JS. That's not JSF's own, that's just because it's a component based MVC framework, not a request (action) based MVC framework. If a high degree of controlling the HTML/CSS/JS is your major requirement when considering a MVC framework, then you should already not be looking at a component based MVC framework, but at a request based MVC framework like Spring MVC. You only need to take into account that you've to write all that HTML/CSS/JS boilerplate yourself.