Ahhh, yes, in that case it seems like you might possibly be better off (and happier ! :-) ) with just using a page-oriented architecture. It seems like the cli

Ahhh, yes, in that case it seems like you might possibly be better off (and happier ! :-) ) with just using a page-oriented architecture. It seems like the client-side state is just getting in your way, as opposed to being helpful in any way. The way that I look at it is this: if you're going to do an SPA, then do it like you're writing a desktop client application: all content is manipulated on the client, the only requests to the back-end are for data (JSON/XML), and the client typically will maintain quite a bit of state. Complex applications that are ports of desktop applications and sit behind authentication dialogs are ideal candidates for SPAs. Here's an example case study of such an application from our company web site: https://www.elevatesoft.com/articles?action=view&category=ewb&article=case_study_environment_canada_weather_reporting_application https://www.elevatesoft.com/articles?action=view&category=ew... The one exception to this would possibly be something like an online manual/help browser application, in which you might be able to make an exception and have the content driven by an SPA, thus allowing for more control over advanced content navigation via a tree view or vertical menu. In general, though, if you find yourself needing to do a lot of history/page management, then that is a good indication that you might be trying to shoehorn a traditional, page-oriented architecture into an SPA.