For a long time JSF for me was just another webframework I didn’t cared too much about. This changed. After being forced to use it for a couple of months now, I consider it a major project risk in almost all cases. Here I present the reasons for this verdict.
Bad entanglement of UI and processing Logic. The official tutorial claims the following about the benefits of JSF:
One of the greatest advantages of Java Server Faces technology is that it offers a clean separation between behavior and presentation for web applications.
The opposite is the case. Facelets, the preferred presentation technology of JSF looks at first sight like an ordinary templating technology like the good old JSP or Thyme Leaf. But if you look closer the horror becomes obvious. In the same place where you structure your HTML, you also place the logic what parts of the UI should get updated on an action. A clear violation of the separation of concerns principle in my book.
Even better is the immediate attribute which changes the server side life cycle! And if this isn’t enough it does it in different ways depending on what tag you use it on. You can’t make stuff like this up.
It tries to abstract what you can not abstract. Except some weird edge cases clients and server of web application are located on rather different computers, separated by some kind of network. From this follows a simple fact: communication between client and server is slow and unreliable. JSF tries to abstract away the separation of client and server. It processes everything on the backend wildly communicating between client and server in a hard to control way. The result are all kind of failure scenarios just popping into existence because you use JSF. For me the most annoying one is this one: If you open a JSF page, let’s say a simple search page, wait an hour, then hit the submit button you will get an exception because the server side state expired. WAT? Why is there server state of any relevance for a trivial search page? (Yes I know you can change that behavior with the latest versions of JSF, but it is still the way JSF is designed to work) I though everybody learned since EJBs: If you want to abstract over the fact, if two parts of an application run on the same machine or not, you have to assume they don’t. Everything else is just hiding problems until they grow so large that they can eat your project for breakfast.
Making stuff complex and complicated that was easy to start with.The architecture of the World Wide Web is a simple one. Simple meaning: It consists of a small set of concepts with limited interaction. This is what made it so widely successful. It also makes it not obvious for beginners how to use it to implement certain features. I’m sure most of us remember the first time they tried to implement something like a shopping cart without having session state. But the solutions for almost all these problems are well known and understood by know. And all you need is a little reading and what you gain is a strong conceptual understanding how to solve this kind of issue. And again, the basics are extremely simple: You send a request to an URL, with some headers and content using a HTTP verb. And you reply with some resource containing links and some headers. And you don’t have state in the server session. Making load balancing and fail over rather simple. Making bookmarkable URLs trivial. Making your site searchable for zero costs. Making your site cachable. Allowing the user to use their back buttons, history and tabs as they wish. Making it trivial to have nice URLs
Compare that to the live cycle model of JSF: The page from which a user submitted a request will get synchronized with a model on the server side, then submitted values validated, converted, events generated and processed. As mentioned above the order in which things happen, and if they happen at all are controlled by XML Tags hidden away in a document camouflaged as markup. Apart from hardly anybody properly understanding all this (BalusC seems to be the only one available in the interwebs) it has the following effect on your application: The URLs become ugly. You’ll see the URL of the resource you came from instead of the one you are looking at, thus making bookmarking URLs as useful as a doorknob on your knee. Same for caching, fail over, load balancing and so on.
Sure you can fix it with some convention here, and an additional library there. Which of course makes perfect sense when you are in the business of breaking stuff so people have to pay you for fixing it. I personally prefer helping to solve real problems.
Hindering testability: I can’t speak for most frameworks but I can compare Spring MVC with JSF. Let me tell you this: If anybody is telling you JSF is nicely testable he probably doesn’t know automatic testing. With JSF you can test your backend beans using unit tests. You can test the whole UI, by deploying the application to a server and hitting it with Selenium. That’s basically it.
Just in case you are wondering what else one should be able to test: Load a static version of a page in a browser and testing it with selenium, in order test your Client side UI behavior. Test your generated markup without starting a full blown application server. Test the mapping of attributes/parameter to bean methods. Test your generated markup without bootstrapping a complete application. All this is perfectly possible with Spring MVC and probably with many other sane server side frameworks, but not with JSF …
Again: I’m aware there are fixes for many issues, but the simplest fix is> Don’t use JSF.
| Reference: | Why you should avoid JSF from our JCG partner Jens Schauder at the Schauderhaft blog. |
I’ve never used JSF, but I have about 4 years of Apache Wicket experience. The two UI rendering paradigms are very similar in that they are component based UI frameworks, and manage the clients page state on the server. I agree the that server side state tracking is extremely fragile. Though I find the component orientation of the the separate web parts to be liberating as far as development is concerned. My take is to only create stateless components (which is an option in Wicket), and have each component just request, load and manage resources (i.e. html, css, js, and… Read more »
Jens, thank you for sharing your experience. BTW: Which Ui Framework do you use in your projects?
Hi!
What do you recommend instead JSF?
To make this as easy without the use of javascript
G’Day Jens
I disagree – you are missing the point. It is a great developer tool to work with. We use JSF coupled with PrimeFaces – the coding is crisp and clean. Easy to maintain and get the task required done quickly. Allows us to move to the next task quickly.
Brisbane
Australia
Fully agree!!!
I would recommend to not harry with such verdict and conclusion re JSF, especially not giving any advice on the replacement for JSF. The second point to be considered while choosing and deciding on framework for your next project – is scope of the project: – in case you are developing some social app for million users – maybe some state-less one will be the best choice (like PHP+Yii); – but in case of some Corporate system with PKI and other corporate features – the winner is state-full framework, like JSF. P.S. I do use JSF ver ~1.2 (IBM XPages)… Read more »
Working at an Oracle partner I have worked with many people with ADF experience. They often share the many shortcomings that can be really frustrating with Oracle’s JSF offering. I have read many things about JSF but it can be troublesome to work with.
I do agree with Ivor. I have been using JSF and Primefaces for a while and it’s a great productivity tool. The separation of concern is not as you expect between presentation and logic in general. The separation is in creating a self contained UI component (compared to the idea of object in general) where one does not have to be concerned about browser specifics, JavaScript pitfalls, themes, data representation etc. but leverage a rather “canned” approach of ready to use powerful components which let you generate great looking applications in hours, rather then in weeks. I give you that… Read more »
I can’t agree more for your points.
I have worked on JSF about one and half years. What I can feel is this framework make the simple things be complex and hard to debug due to its high abstraction.
Now I feel I love simple code more.
I am still learning this framework and it looks cool, It is so cool to read observations from experts this gives us beginners some ideas on what to look for and as we explore we are reminded of some facts, agree or disagree with them, Thanx guys.
I disagree wih you.I woked on jsf with pimefaces,ichfaces n icefaces.All of them works very nicely.
Unfortunately you dont understand JSF and you does not know what whit JSF already developed a lot of big projects and a lot of new frameworks try to copy JSF life cycle, you should know what JSF already part of Java EE and it is a web standard , ebay and amazon used JSF also, and you cant say what ebay and amazon’s developers did not understand web development. Of course Struts and Spring MVC also good, but today for a business you cant use Struts which is too old and Spring MVC which is very similar with Struts can… Read more »
Sorry but I’m very happy with JSF, I’m using PrimeFaces since v. 2 and the development experience is a pure joy, really fast and simple !!!
A mi no me parece malo JSF, lo uso hace años, con RichFaces y SEAM, buena combinación !!!
I love JSF, but I have to agree that it has a lot of complexity that makes it challenging (perhaps that’s why I love it so much…). Yeah, and BalusC is THE MAN when it comes to JSF!
simply disagree with this article.