I tend to think of it in terms of horses for courses. In other words, let your requirements drive your architectural choices, rather than going in with the prec

I tend to think of it in terms of horses for courses. In other words, let your requirements drive your architectural choices, rather than going in with the preconceived notion that there are architectures 'no one needs'. I recently threw together a small blog engine and wouldn't even have thought of writing it as an SPA... there was no point. Then again, a blog is mostly static document service, so it shouldn't be a surprise that picking a document service architecture made sense. For me at least, some of the specific reasons to pick an SPA might be this: * I'd like my user to be able to make change to a document without disrupting where they've scrolled in the document. * It's possible to build retry logic into the SPA to get a bit of offline capability if the network connection isn't great. * There's a block of data on a page that takes an unmanageably long time to render and I'm okay with it showing up after the body of the page. * There's a large volume of data that can be maintained and incrementally updated within the client, rather than reload every time. * There's a need to automatically stream and update the page in real time (and meta refresh, etc. won't work.) * The developers assigned to the project are more comfortable with SPA and associated tooling. * There is a high likelihood of one of the above becoming true soon enough that we wouldn't be able to rewrite to an SPA to accommodate the requirement when it arises. Not exhaustive, but a big list anyway.... so there are often good reasons to select an SPA design. But not always. As engineers/architects, we have to do the work of understanding the requirements and planning our design..