The problem is with any site that uses stuff after the hash to distinguish between what should be different application states. From the REST perspective, these applications just have one huge state and thus miss out on many of the benefits of REST.
What's worse, fixing this flaw necessitates breaking all of the application's URLs.
When pushState is used properly, a single-page app essentially becomes a transparent client-side proxy/cache, which maps much better onto REST.
Sorry but REST is fine with forcing the client to maintain its own state (in fact it's pretty much assumed the client will, for any non-trivial application). Using hashes in this manner shouldn't require the server to maintain additional state. If I'm missing something here, could you please elaborate?
Well, an application has many kinds of state on many different levels. The sort of state that serves as the S in REST is the one that a client changes by requesting and manipulating representations of resources identified by URIs.
An application composed of a single representation that implements the entire app with code-on-demand is not exploiting the REST architecture very much.
Actually, even if the application is properly broken up into URIs, it's still not entirely RESTful because the "engine of application state" has become Javascript + secret protocol rather than hypermedia.
What's worse, fixing this flaw necessitates breaking all of the application's URLs.
When pushState is used properly, a single-page app essentially becomes a transparent client-side proxy/cache, which maps much better onto REST.