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.
You can see from my old posts that I have been a strong supporter of JSF from the beginning. I continued to believe in its potential even when it was new and lacked features.
JSF 2.0 was supposed to address the shortcomings with, for example, bookmarkable URLs and view parameters. But JSF 2.0 still has many flaws, and I still have to jump through hoops and deal with incompatible implementations despite the specifications of JavaEE to get certain things to work.