JSF is Not Fixable
Last week, at the Colorado Software Summit, I gave a session on RESTful Web Apps. In this session, I made a comment that the proponents of JSF failed to consider the web architecture, and that it is not fixable. My goal in that session was to point out the consequences of design choices made by some web frameworks, but not necessarily to point fingers at those frameworks.
Matt Riable attended my session, and shared his notes on his blog at RESTful Web Applications with Subbu Allamaraju. His post incited some comments, to one of which I would like to respond here.
Diego Plentz said that
I haven't come to the conclusion that JSF is not fixable yet. It looks like there are some major overhauls going on related to state saving and RESTful URLs in JSF 2.0.
I think this comment misunderstands what it means to be "RESTful". The ability of an app to create a link that can be submitted via GET to some non-JSF app does not make the app RESTful. Period. I don't have problems with JSF focusing on usability, but I do think it should have paid attention to the web architecture. Given that JSF is a Java standard, those who want to rely on standards have no choice but to build web apps that fail the web architecture and can not take advantage of common web infrastructure. The design choices made in JSF are poor, and I don't see an exit strategy other than dumping the current standard, and going back to the drawing board. Bill de hÓra echoed a similar thought:
But it’s hard to be non-critical about a spec that got things so wrong - not just REST, but basic HTTP usage. A JSF that supports REST is going to be a complete overhaul, no?
I have not read the latest JSF 2.0 draft thoroughly, but upon a quick reading of all the changes, I don't see anything to address the basic web usage. Unless there are more changes coming that will magically fix the core without an overhaul, JSF should the follow JAX-RPC into the JSR-graveyard.
Update:
Looking at some of the heated comments below and the links posted, I can't help but comment that JSF (community) has recently discovered the web architecture, viz., that GET is the de facto means of navigation and that POST is an exception and used solely for unsafe and non-idempotent operations. This is unfortunate for a standard. Secondly, the ability to pass parameters to a URI does not fix JSF as long as JSF's notion of a form is always driven by POST. That does not make JSF a bad framework, it just makes it a special-purpose framework that can be used to build certain kind of stateful applications. That, IMHO, is a too low a bar for a standard framework.
Can you please describe what you mean by RESTful? Give specific examples
Mainly that it can not use applications to use GET to submit requests back to the JSF app. Consequently, it fails to take advantage of HTTP caching.
To elaborate on my previous response, ideally, it should let the app decide when and whether to use POST. Unfortunately, it makes that choice for you. Secondly, it should make it easy for applications to enforce best practices regarding caching, redirect-after-POST etc.
I’m surprised how you assert that JSF simply cannot be changed to do that when Seam has offered this functionality to JSF developers for a long time. The JSF 2.0 expert group has explicitly said that they are going to be standardizing it. It is not in the spec yet, but will be soon.
I doubt many developers use JSF 1.x on its own. You need Facelets + Seam. With those two it is serious competition to any web framework.
Even IBM says Seam makes JSF RESTful:
And in the JSF 2.0 spec requirements:
Allow for bookmarkable JSF pages. More broadly, if HTTP GET can be used, it should be used.
Allow JSF application resources to be accessed via REST.
Add support for REST (JSR 311)
http://jcp.org/en/jsr/detail?id=314
Shame on you for spreading uninformed FUD about JSF at the Colorado Software Summit without fact checking. I’m sure you lost credibility to any JSF developers in your audience who uses Seam and knows anything about JSF 2.0.
You also misinterpreted my comment, and did NOT follow the link I provided in Matt Raible’s blog. No I am NOT talking about HTTP GET links to *non* JSF apps. You are too closed minded and have already made up your mind about JSF.
No need to jump into a flame war, but could you explain how Seam fixes the problem?
By the way, Seam’s notion of conversational scope does require a session to manage that conversational state. This is perhaps a good compromise given the stateful nature of JSF. Therefore I stand by my comments.
http://docs.jboss.com/seam/latest/reference/en-US/html/tutorial.html#blog
http://www.jtict.com/blog/seam-form-url-rewriting
and I stand by my comments.
Fair enough. As I said before, my comments were solely based on JSF as it exists. If some future version of JSF fixes these problems, well and good. You can flame me for saying that JSF is not fixable, but by being a Java standard, JSF has a much higher bar to cross. That is, it needs to make writing web apps that adhere to the web architecture possible and easy to implement.
Ok, and I will agree that JSF 1.2 needs addons like Facelets, Seam and component libraries to make it competitive. Your blog says JSF is not fixable. The point I am trying to make is that it is fixable, the existing JSF extensions prove it, and they are being standardized in JSF 2.0.
Oracle’s ADF framework also offers the ability to set Get as the method to invoke JSF as well as bookmarking JSF pages.
Someone in the JSF expert group told me that fixing state saving is the top most issue being worked on right now. They hope to have it in the public review draft which is due out very soon.
Thanks for the update. By the way, the key issue is not necessarily how to manage state, but to allow stateless applications. State management is nice to have when an app needs it, but that should be an option.
Yes. The issue tracker has tickets that talk about making JSF stateless wherever possible, and improving the state saving mechanism for when state is necessary. I look forward to reading about this and full HTTP GET support in the next public draft.
It’s been a long time since I wanted to post about JSF being not fixable… This post gave me the kick in the but.
Subbu, I agree with you. Seam, et. al. actually encourages and promotes stateful, session-heavy, web applications. If you’ve ever heard Gavin King’s talks on Seam, you’d see that is one of the first things he tries to hammer into the audience. That a stateful applications are “modern”. Conversations are *central* to Seam and a conversation requires a lot of state on the server in his implementation.
Thanks. I never heard him speak, but I found the same from their docs. I don’t understand why the other “Anonymous” commenter was so defensive about JSF. Let’s call a spade a spade.
I use JSF at work as part of maintaining a mature intranet web application. Proxy caching is not possible since we use JSF directly. It has proven so difficult to make our system work on the latest MyFaces release that we have chosen to stick with the old version. I have serious misgivings about a technology standard that fails so badly for existing developers as it matures. While it has proven to be quite useful on getting the application working and in front of customers it has also imposed significant scalability problems.
JSF encourages a stateful programming model that facilitates unscalable web application designs. I would go so far as to say that it encourages it. JSF can be fixed, but doing so would make it completely incompatible with JSF as we know it today. This would effectively require a complete rewrite of our web application component. Given the obvious lack of attention paid to HTTP in JSF 1.x I intend to do everything in my power to discourage my company from adopting it. I believe that Sun has too many big shot RPC advocates egos on the line to abandon this obviously flawed protocol tunnel they have built on top of HTTP.
In short I agree with this article completely and say it is time for JSF to go away and stop wasting valuable time and resources.