In Buddhism, impermanence means that each and every existence, without exceptions, is in a constant state of flux. It is, but later when it evolves and mutates, is it still it? Take a look at web 2.0 today, pages mutate in real time, regardless of your actions.
Facebook page is updated (almost) whenever one of your friends does "facebooking", Gmail page is updated whenever you receive a new email, without having to refresh. They should not be called "pages" though, since they are applications more than anything else.
The need of SPA
Back in web 1.5, when JS got more attentions, this de factor web programming language was mostly used to manipulate a small number of DOM elements on the web page, and to do "magic" like right-mouse disabling, location redirect, etc. Gradually, with more DOMs to manipulate, web developers started to wonder, "When should the page be replaced by a totally new html file?" It should be noted that these html files were mostly dynamically generated anyway, with constant headers, footers, and other static widgets. There were no clear borders when to mutate the current page, and when to serve a totally new one. Furthermore, developers also faced difficulties with page states. Some displays depended on page states, which needed a list of interactions with web surfers, but were vulnerable to refresh/F5/Cmd+R.
With web 1.5 and below, every time a form was submitted (which includes both post CRUD and file upload), the whole web page hangs or blanks. Web surfers wished the upload button had not disrupted their reading, due to the nonconcurrence.
Internet has evolved to web 2.0. Some developers no longer care when to serve and when to mutate the page, they go with one-page-serve-all. The hashtag (#), which, at the dawn of WWW, was used as an anchor reference, now mostly serves as a page state identifier. Form submitting is now asynchronous - wishes have come true.
So what are the Achille’s heels? With SPA, search engine optimization (SEO) becomes complicated. Old search engines fetch only the html, mistakenly determine that it is an empty page (or with some bootstrapping text, such as "loading"). New ones may try to run the page in headless browser and take JS into serious consideration. Nevertheless, SPA has never meant to be SEO friendly. It was designed to suit each individual, based on numerous dimensions, for example OS version, browser version, cookie/session, IP/geolocation, etc. Flash applications in pre-HTML5 had the same philosophy.
Another issue closely related to SEO is analytics. With traditional web pages, web admins usually track page views, from which they interpret data in terms of source of traffic, bounce rate, average time on page/site, page view flow, etc. With SPA, however, there are no other pages and thus no page view track. But, modern analytics engines have the ability to track clicks and other actions on every element, and also all JS events, which should cover all use cases.
SPA is absolutely the right choice for developers building web applications that demand high interaction between users and the system. If developers are struggling to overcome some of the drawbacks of SPA, they have brought their thinking of traditional multi-page application to SPA and shall not be happy.
SPA, however, is by no means suitable for content-heavy websites, such as e-newspapers or blogs. Of course, a comment widget can be added and should be asynchronously handled. SPA also brings up the discussions on client-side vs server-side rendering. At Smarp, we employ both SPA and MPA to different services. Smarp Share, a SaaS tool helping businesses spread content effectively to a relevant audience by utilizing employees' personal networks, is built with SPA design. In contrast, the content-heavy Smarp Academy, which is a social media learning platform for employees, is built with MPA design.