Is there evidence to suggest Thoughtworks' assertion that JSF is a broken abstraction? [closed]

Question

On the Thoughtworks Technology radar - they put Java Server Faces on Hold - stating:

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.

As I understand it, they're basically saying you can fall into a trap if you wrap a stateless protocol like http with a stateful abstraction. ie that a team can run into trouble wrapping their heads around this.

My question is: Is there evidence to suggest Thoughtworks' assertion that JSF is a broken abstraction?

Juvenile

Probably going to get closed as subjective, but I like the question. I do concur with the premise, but there are teams that may find these abstractions useful. They are saving you time, if used correctly. That said, the whole stack has so many ways that can lead you astray I can easily see that sticking to the basics actually is a net benefit. – Moonshiner

As @Moonshiner says, that's not a question for SO. However, it would be nice to discuss about that somewhere else. For me, having used JSF for about 2 years, I found a lot of people who criticizes it just because they've used the 1.x versions and think that 2.x should be the same mess.. Certainly it's not true. Appart from that, I agree JSF doesn't fit standard HTTP lifecycles. However it HAS the possibility to use it statelessly, so you can make your choice. Being stateful is an enhacement for the standard HTTP lifecycle. But problem begins when people using JSF doesn't know about HTTP itself. – Baalbek

@XtremeBiker your last sentence is probably what drove the decision by thoughtworks, because that's the very definition of a leaky abstraction. But show me one in the arena that isn't. – Moonshiner

@XtremeBiker, you can implement sessions with js on browser and have one less burden on server side. The server ends up as an API provider, I believe that's a much better architecture to work with and evolve. Also note that HTML5 is working hard to provide proper user Session Management on Browser. I agree it's a broken abstraction because it attemps to hide "complexity" with something even more complex and it hides things that programmers should be aware of (HTML, CSS, HTTP Requests, Cookies, etc.). – Stewpan

@Stewpan if you want to minimize server side loads, there's the chance to bring the view states to the client, with JSF 2.2 you can even work in stateless mode. For your last sentence, it probably does hide things, but if you need to control everything by your own, then it wouldn't be a framework, would it? Remind you can access the requests, cookies, etc using the JSF context, you can even make it write your own HTML code using your custom renderer (although usually you aren't required to do so). BTW ,does anybody know any good place to discuss that things? – Baalbek

@ivan.aguirre: Absolutely right. I like you statement, ' programmers should be aware of (HTML, CSS, HTTP Requests, Cookies, etc.).' – Devorahdevore