On it's latest technology radar, the guys at ThoughtWorks recommended avoiding JSF because it's attempt to create statefulness over HTTP ends up causing a whole host of problems involving shared server-side state.I've been using JSF 2.x for almost a couple years now, I like it and I can't say I've encountered any problems like that. But I don't have that much experience with it and much less with alternatives, so I would like to understand what are those whole host of problems?Questions about JSF usually raise some heated discussions, so I think it pays to be clear: this is about JSF 2.x, but not about it being better or worse than X or Y, whether it's architecturally right to put state in HTTP, or anything like that. I'd just like to know what are those problems since the radar doesn't go on specifics. 
JSF problems due to shared server-side state
http;client side;jsf
I've managed to find some useful facts about problems in the stateful HTTP model. The original whole host of problems involving shared server-side state still sounds vague to me, but some of the references I've gathered do cover it up to some extent (and interpretation).First comes performance issues, one of the most common complaints. JSF has to create, manage and send the view state back and forth, between the client and the server, and that's quiet costly. This cost may be minimized to some degree by:Using a different implementation. I've found a 2012 blog post that points out that 2.1.7 MyFaces is less resource intensive than it's Mojarra counterpart. Keep in mind that, as it always is with performance issues, this may change in future versions.Disable state saving, which should actually fix all those problems, but the performance is still not optimal. This answer shows that JSF 2.2 with disabled state is still slower than plain servlet. Notice that an user questions whether that's a valid comparison or not.Second, delivering a RIA experience may be harder when the state does not belong to the client. This also boils down to performance, but it seems to be more than that. To simulate a desktop-like experience in a stateful HTTP application, developers end up dealing with the complexity of view state directly. I believe implementing some kind of UI flow is a nice way to see that. It works, but it's quite messy. JSF 2.2 provides the flow scope to make the developer job easier, but I found it still a little rough around the edges.This post gives a simple example of this kind of problem.Finally, relying on the session to hold view state makes the job of clustering your application harder since you'll have to share that session between instances. Application servers do provide mechanisms to do that, but you'll end up using more resources. Also, some PaaS providers will charge for session replication. Using that just because of JSF does not strikes as a good idea.