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.
