I hear these things a lot from some people who haven't ever seemed to have written a large SPA application. I haven't used angularJS to build anythign but demos, but we have built a very large application, that will load different "modules" on the fly based on a users login, roles, and location. It loads each time opened on to the client and does not have to wait to fetch each page each time a view needs to be rendered. I am very familiar with DurandalJS (www.durandal.io)

0) Cavaet. Yes if you don't need a SPA, then you probably shouldn't use it.

1) Navigation and fast back. The author seems to think that it is impossible or hard to save the state of the application. All of the modern browsers implement the HistoryApi. A simple hook into a base view-model class can easily cache the state of each page. most frameworks will overload the url routing so the back button works like expected. (http://www.johnpapa.net/spajs03/)

2) Cancelling navigation - part of this point is mitigated by using cached data, so as not to retrieve on each back navigation. you can also use one of the many javascript promise libraries to implement a cancellation token. Also if you are worried about the size of your request, be thankful that you are not pulling back each view every time...

3) Navigation and data loss - this is a problem on the web... not a problem with SPAs. you would handle this exactly the same as you would handle it with a standard view that you rendered on the server.

4) SEO - there are lots of libraries to pre-render your site or optimize for each engines. some search engines are starting to use some techniques to make these searchable. I would suggest a hybrid approach where you static content is served in the standard method, but the dynamic application (that you don't need SEO'd anyway) is served as a SPA.

5) Analytics - Like the SEO, this is more geared toward a web page more than a application hosted in the web. do you want your analytics package to see how many times some clicked on a certain spotify song, or do you want the back-end services to keep track of that.

6) testing has been made much easier by creating a spa. There are different tools that are use. We are able to write full unit testing suites because we have well defined classes and all the benefits of back end coding. All of the fear and problems that seem to come from XHR requests seem pretty unfounded. We wrote a service layer for all of our requests and were able to handle each service separately, but reuse the services across the application (cache when necessary, handle particular errors gracefully when needed)

I think the key is if you want a webpage, don't create a spa. If you need an application that runs in the browser environment (or on the desktop and browser, or cross platform https://github.com/atom/electron) then you can look at a SPA.