In general, it depends: there are many different use cases where SPA is fine and others where they are not. It's especially good for long-running consoles that

In general, it depends: there are many different use cases where SPA is fine and others where they are not. It's especially good for long-running consoles that don't need much navigation (given using the appropriate JS framework which doesn't leak resources on most browsers). SPA doesn't make much sense (apart from in-web app search live results searching) for static pages that need to be SEO crawlable and can be served up fast from static CDNs. Perhaps the core engineering tradeoff is whether to breaking the stateless RESTful contract by managing state with session cookies and/or JavaScript, and doing so in a way that may or may not be sharable to other users, history-friendly, SEO-friendly, etc. Ruby's turbolinks is a clever hack and mostly works approach to make nav-based (browser history- and crawler SEO-compatible) almost as responsive as SPA... it replaces assets, title, meta and body on-the-fly and updates the url location with javascript to save a whole page update. It's basically a hybrid of client+server coordinated fragment caching. There are some gotchas and workarounds for onLoad() and other JS hooks, but it mostly works pretty well.