Why I Don't Care for JSF

I recall in 2001 as Struts was just starting to take off in popularity that the next big thing was being advertised as JavaServer Faces. I have followed this specification's progress off and on since then, but have been disappointed with JSF implementations each time I have made a real effort to learn to JSF. I have wanted to like it because it is a standard specification and many vendors have been pushing it. Unfortunately, each time I work with JSF, I leave disappointed. It is difficult to summarize all the frustrations and issues, but I think it boils down to truly being far more difficult than it should be. The difficulty of applying JSF is more obvious when it is compared to alternatives such as Flex, OpenLaszlo, Ruby on Rails, WebWork, Tapestry, and even several other Java web frameworks.

It almost seems unfair to compare Flash-based web applications developed with either Flex or OpenLaszlo to JSF. After all, Flex and OpenLaszlo enjoy the ability to compile into applications that run in an environment that supports highly fluid animation and allows developers to code free of concern about browser idiosyncrasies. Flex and OpenLaszlo both allow for developers new to these frameworks to easily begin working with the frameworks and quickly master the basics of each framework. Both OpenLaszlo and Flex provide rich component sets and both are heavily based on standards (XML and ECMAScript).

If an application must be a browser-based application, it is difficult to think of an easier way to accomplish this than by leveraging the abstraction provided by Flash and acquired easily with OpenLaszlo or Flex. While I think Flash-based web applications are easier to build and maintain than DHTML/Ajax-based web applications, the JSF-based applications seem to be the most difficult of all.

I am being relatively kind in my treatment of JSF in this blog entry. Matt Raible, who certainly knows a thing or two about Java-based web development, stated "... JSF sucks. Especially when used with JSP - which is what most folks are doing. JSF continues to be the most over-hyped under-used framework in Javaland." Ouch. Painful but true. Matt also points out something that really irritates me as well regarding JSF; it simply takes too long to be what it wants to be and other frameworks and tools are leaping ahead.

Adam Winer is much nicer about JSF, but acknowledges it is more difficult than it should be in his blog entry Usability Problems in JSF.

In The Real Problem with JSF, Spencer Uresk states that the real problem with JSF is people making misinformed statements about it. While there may be some truth to that, it is my experience that JSF is the most difficult to use of any of the web frameworks that I have tried (and I have tried several). So, while it admittedly may be just me, I personally don't have much use for the seemingly unnecessary complexity of JSF. This is driven home even more whenever I try JSF in the same relative time frame that I work with Flex or OpenLaszlo.

To be fair, some JSF implementations are better than others. However, I grow weary of people arguing about JSF's advantage being its standardization. My experience has been that many JSF implementations have trouble implementing even the core functionality correctly or completely. Some of the commercial (or formerly commercial) JSF frameworks are significantly better, but many of them use proprietary features to be better and that reduces the argument of a standardization advantage for that particular JSF implementation.

Frederic Simon beat me to the punch on comparing JSF to earlier versions of Enterprise JavaBeans. The push from Sun and vendors to use "the standard" despite its many flaws and relative problems compared to other available frameworks feels like EJB 1.x and 2.x being foisted upon us all over again. The Spring Framework and other forces led to making EJB usable and I'd like to think that all these other innovative web frameworks will have the same positive effect on JSF. Unfortunately, many of us have heard the JSF hype repeatedly and been burned repeatedly as we gave it another try. Just as many are reluctant to give up their Spring-based applications to even try the vastly improved EJB 3, it is likely that many of us will be very reluctant to try JSF again if one of these alternative frameworks is satisfying our needs.

In the article Improving JSF by Dumping JSP, Hans Bergsten points our that using JSP as one of JSF's main views is problematic. In that article, he encourages use of other view technologies in conjunction with JSF.

The article Java Opinions: Geary vs Raible on JavaServer Faces provides a nice summary of some of the discussion regarding JavaServer Faces and summarizes my thoughts on it. While it could be argued that it is the implementations that are the problem rather than the specification itself, that doesn't help me feel much better if the implementations are all I have to use. Even if one or two is a decent implementation and the rest are more trouble than they're worth, it reduces the value of a "standard" because I cannot easily switch between them or rely on the same behavior across them.

Matt Long writes of his frustration with JSF in Nobody Users JavaServer Faces and he compares it to ASP .NET (which I have not used). He says, "As much as I despise ASP .NET, it is a dream compared to JSF." He adds, "And that brings me to the point. JSF is a technology that looks good on paper, but when it comes to actually using it, it stinks." This is echoed by others critical of JSF (including me) who like many things about it conceptually, but find it much dissatisfying in practice. Matt also mentions another telling characteristic of JSF -- even the "introductory tutorials" must use long code samples and explanations even for the most basic of applications. I liked a quote from a person providing feedback to this article (and defending JSF): "That said, in it's current offering it's much more a bare fundamental technology on which interesting things can be built, than a ready to use high-level framework." Since 2001, JSF has consistently seemed to be "almost there."

I think most people who have used JSF directly would have a hard time arguing that JSF simplifies web development. However, one of the big arguments for JSF has been that tools would make it easier to use and this is where vendors seemed to really be interested from the beginning. After all, any chance to sell a tool to make a complicated framework or language easier to use is better for a vendor's business than a framework that does not need a tool. One of the facets of the Agile Manifesto is "Individuals and Interactions over processes and tools." If I have my choice, I'd rather have something simple to write manually (and still use tools if I choose to) rather than something that is so complicated or tedious (EJB 1.x, EJB 2.x, XML Schema, etc.) that they almost necessarily require use of tools.

I have heard proponents of JSF argue that simply reading a good book on JSF will overcome the many complaints with JSF. The problem with this argument, in my opinion, is that one probably doesn't need to read a good book to get well under way with OpenLaszlo or Flex. Admittedly, a good book comes in handy as one progresses with either of these frameworks, but I did not find myself relying nearly as much on these books as I needed to rely on my JSF book for even simple things (or things that should be simple).

From its beginning, one of the mantras of JSF has been its desire to allow for a flexible architecture in which view technologies could be easily swapped. For those who truly need this, the complexity of JSF may be justified if the ease of swapping view technologies becomes reality. Generally speaking, with great flexibility comes great complexity. Why endure the complexity if you don't really need the flexibility?

I am curious to see if JSF is able to survive and eventually thrive. To do so, it may have to go through a evolution or even revolution like EJB did. It seems like the best bet for a successful and less painful JSF experience is to use a framework like JBoss Seam, Oracle's Application Development Framework (ADF), or Apache Beehive (former BEA product). Note, however, that Seam and ADF offer much more than simply JSF implementations.

There is already tough competition for JSF in the web development community and the rise of Silverlight and JavaFX to emulate Flash will likely make the competition for web developers' hearts and minds even more fierce. There is much I like about Java (both SE and EE), but I have serious doubts about the viability of JSF in the near-term future without significant changes. JSF has certainly come a long way, but I question whether it has come along far enough fast enough to remain a viable option compared to the many other choices out there. Just as "being the standard" was not enough for earlier versions of EJB, this cannot continue to be the main advantage of JSF if it is to be successful.

We all know that the major players in web (Google, Amazon, etc.) using Ajax technologies and Flex. Do they use JSF as well? I don't know and it certainly doesn't seem to be advertised as well if they do.

This blog entry is not meant to belittle anyone who has had success with JSF. After all, we each should select technologies that work best for us, for our clients, and for the problem at hand. For example, those who need their application rendered on many different platforms/devices and have access to or willingness to write the appropriate render kits, JSF may be the best alternative.

UPDATE (28 January 2008): Ed Burns, co-lead of the JavaServer Faces specification, left a feedback message below with this reference to a JSF 2.0 requirements scratch pad. It is reassuring to see active work to improve JSF. It will be interesting to see if JSF can compete with the increasingly popular Flex+Java combination as well as with JavaFX if that starts getting heavy adoption.

This blog entry is meant to be a simple summary of things I have experienced with JSF, especially when compared to Flex. While my experience leads me to strongly prefer Flex or OpenLaszlo over JSF for web-based applications, I believe just as strongly in the principle of "To each his or her own!" In addition, I'd like to see JSF succeed because, when all else is equal (or even very close to being equal), I do prefer to develop to the standards-based product.

Here are some other interesting opinions on JSF. I have mixed some positive reviews of JSF with the negative ones.

Ed Burns Blog ADDED 28 January 2008

JSF for Nonbelievers: Clearing the FUD about JSF

What to do about Java and JSF?

JSF: The Ultimate in Flexibility? Or Complexity?

Developing Web Applications with JavaServer Faces

JavaServer Faces: Web Applications Made Easier

JavaServer Faces Versus Tapestry

GAME OVER - Java Sever Faces (Added 3 May 2008)

Is JSF Fixable? (see feedback as well for interesting counterarguments) [Added 5 November 2008]

JSF Anti-Patterns and Pitfalls (see feedback as well) [Added 20 December 2008]