JSF: Dead on Arrival

This post could have been written 5 years ago. I spent so much time working with JSF because it was forced down on us in my previous job, that I decided to write it, no matter how late.

There is a compilation of articles on why JavaServer Faces is bad for the planet. The compilation is titled "JSF sucks" and here is the link: http://ptrthomas.wordpress.com/2009/05/15/jsf-sucks/.

Complexity is the main criticism, and its ability to make things convoluted. I will not go into each of the details, but rather narrate a story to make my point.

In the JavaOne conference in 2006, Google announced GWT which I attended. In that first presentation itself, they talked about back button support, bookmarkability, integration with JUnit, and co-existence with other technologies, even Microsoft technologies.

With JSF, we struggled with bookmarkability for years. I filed an enhancement request (for our internal JSF implementation) which was smartly rejected. The chief Architect had a ready reply "of course we support it". What they supported actually was that user had to click a button (which you had to code) that would give a bookmarkable link. That was a spin on bookmarkability, because actual bookmarking happens from the browser menu or a keyboard shortcut.

Everything can be done, but the question is how convoluted it is. My company's implementation took convolution to another level. Those CSS selectors: whoever designed them should be banned from the software industry.

Still, complexity, convolution and disregard for popular paradigms are not my main rants. But before I begin, some more background: 1. My previous company replaced the JSF life cycle with a proprietary life cycle. 2. My previous company had a component development team, which was separate from application development teams. Even though my experiences are based on using my company's implementation, by and large, these apply to JSF in general. Okay, now lets start the rants:

1. No matter how many or how smartly JSF components are implemented, they are only good for back-office applications. Inability to extend these components programmatically and unavailability of any scripting on these components mean that they are not flexible. Do not, I repeat, do not attempt to write an app similar to Facebook using JSF.

2. JSF components are rendered on the server side, rather than on the client side. so for any tiny winy change on the UI, a backend server is consulted. It goes through the long JSF cycle and performance goes down the toilet.

3. JSF components can do AJAX if implemented that way, but application developers have no control, and so these are not optimized. If you periodically need to fetch data and refresh some UI table, read through your component documentation and find a convoluted solution, if any.

4. Form POST when it should be simple GET for simple view-only pages.

Summary

Server side UI rendering and lack of client-side scripting ensures that JSF will not succeed as the paradigm has shifted. You will hear of many improvements in JSF 2.0, but I am not looking.

Gmail was announced to public in the same year when the first version of JSF came out, in fact within a month. Symbolically it marked the end of JSF, because it established a new way how future web applications would be written.