We continue to see teams run into trouble using JSF– JavaServer Faces — and are recommending you avoid this technology.
Teams seem to choose JSF because it is a J2EE standard without really evaluating whether the programming model suits them. We think JSF is flawed because it tries to abstract away HTML, CSS and HTTP, exactly the reverse of what modern web frameworks do. JSF, like ASP.NET webforms, attempts to create statefulness on top of the stateless protocol HTTP and ends up causing a whole host of problems involving shared server-side state. We are aware of the improvements in JSF 2.0, but think the model is fundamentally broken.
We recommend teams use simple frameworks and embrace and understand web technologies including HTTP, HTML and CSS.
This is exactly how I am feeling about Java Server Faces today.
If you go back through the old posts on this blog, you will see that I have been an avid supporter of Java Server Faces from the beginning. Even when it lacked in many aspects, I believed that it would get better and worked around the shortcomings.
The promises were supposedly fulfilled with JSF 2.0, what with bookmarkable URLs, view parameters, and so on. But, JSF still does not work properly in many cases, and when it does, there are so many hoops to jump through and so many different behaviours from one implementation to another that JSF as part of the JavaEE specifications is but a farce.