You don't need a SPA for that. And page load/render times are much shorter when html is delivered straight to browser fr most applications
> Better emulate the feel of mobile applications,
That's pretty weak defense.
> Once the browser downloads and caches the bundle on initial load, the user can revisit the page
Giving we're now in the world of Continuous Deployment, I doubt the cache lasts long.
All 3 of those reasons sound very reaching to me.
And here's the kicker - doing a SPA well enough to be seamless and performant is hard enough that most sites suck if they're delivering a SPA.
Also, if, for example, you do your payments or other sensitive pages in a SPA, you're still running 3rd party scripts on those pages for no reason. Let me know when unloading scripts(&their in mem code) is doable.
Are you legitimately worried about unloading third party libraries into memory on the browser??
or else gaining the ability to freeze their code and all derived/generated code from accessing the dom/network/etc.
Please don't dilude conversations like this, it doesn't do anyone any favors.
1) Prevent reloading of the page every time the user clicks a link, reducing the overhead of fetching common content between pages multiple times (headers, menus, etc) and providing a more seamless experience to the user.
2) Better emulate the feel of mobile applications, for users who spend most of their time on their phones and don't often or have never interacted with a computer. Yes, those exist.
3) Improved network performance (by sacrificing initial load time). Once the browser downloads and caches the bundle on initial load, the user can revisit the page on regardless of their connection stability or speed.
This isn't to say SPAs are a perfect choice in all cases (they also have just as clear drawbacks), but saying "it's what everyone does" is the only reason they exist is downright false.