http://www.thoughtworks.com/radar/#/languages-and-frameworks/683 - ThoughtWorks Technology Radar - January 2014
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.
http://www.jfokus.se/jfokus/talks.jsp - Search for JSF... (one hit on why you should leave it)
http://architecture-musings.blogspot.se/2012/01/jsf-dead-on-arrival.html
>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.
http://www.youtube.com/watch?v=9ei-rbULWoA#t=47m - James Gosling about JSF
http://java.dzone.com/articles/j2ee-dead-long-live-javascript
This enables our front-end developers to be incredibly productive. They don't need to run a server of any kind. We stub out the JSON services with flat files, and they can plow ahead, cranking out kick-ass look and feel and slick UX. To be honest, they probably haven't heard the acronym J2EE. (and probably never will) Meanwhile, back at the (server) farm, our java-heads can crank out light-weight services, which replace the stub JSON files with real services that interact with the back-end systems. T
http://java.dzone.com/articles/why-java-ee-lost-and-spring - Interesting read about JSF and Java EE
Server-managed state began as a workaround for browsers that couldn’t hold state, where each page was re-rendered and cut from whole cloth. Later, with XMLHttpRequest/AJAX, browsers could manage state, but server-managed state was still used because of how much simpler it was to code (until you have a lot of it and the server crashes). Server-managed state has become a monster and complexity is being manufactured.
first link changed to:
https://www.thoughtworks.com/radar/languages-and-frameworks/jsf
this is also worth checking out since its a comparison of alternatives by the same people:
https://www.thoughtworks.com/radar/languages-and-frameworks