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.
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.
Please don't misuse words, especially in a negative context to mean "something I don't like", it cheapens the word in legitimate cases.
No comment on whether SPAs are worth anything though, I reserve my opinion.
you've never seen certain architectures that smell because they're not following an established pattern?
Not sure you could ever call them an anti-pattern.
Assuming you add video, 99% of the web is just text,images,links,forms, and video. None of these things even require Javascript.
Or is your opinion that it should only be possible to do those things in native, purpose-built apps? Because in that case, how do you justify using an operating system? Perhaps we should exclusively use purpose-built assembly code that you flash to some writable media every time you want to run a particular program!
Also, a SPA is not the only option with Javascript.
1) Load the page.
2) The page is now fully loaded and ready for reading without any need for further network requests.
For even more offline use, try printing it! HN threads work superbly when printed, again unlike most modern sites.
Or you could reimplement newsgroups (but with less interoperability) as an SPA, which in theory would work great (once you work out the kinks) but in practice would suffer from all kinds of little issues in the from-scratch reimplementation of everything. For example, printing would probably forever be a wishlist item in the backlog.
A lot of people think that moving to an SPA would mean killing both those aspects. But the truth is, you CAN have an SPA that is both lightweight and fast - the developer just needs to know what they're doing.
Let's rebuild html rendering, navigation history, forms, etc, all with Javascript, because it's the hip thing to do.