This sounded more like a anti-SPA post. Maybe the title should be "Reasons for not building a SPA".
Let's rebuild html rendering, navigation history, forms, etc, all with Javascript, because it's the hip thing to do.
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?
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.
Please don't dilude conversations like this, it doesn't do anyone any favors.
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.
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.
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.
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.
* That is the design pattern dictated by your large framework.
* Maintaining state is absurdly simple, but it requires original code if not using a big framework.
* The browser provides a simple standard API for interacting with HTML, but your framework provides abstractions you didn’t know you could live without.
That’s it. Developers twist themselves in knots trying to qualify their opinions as anything more valid than what sounds like incompetence, but with any level of informed discussion it’s clearly about competence (or insecurity).
This is my user experience with SPAs regarding navigation.
That doesn't mean good SPAs don't exist - many do!
And then people stopped using PHP.
Evidence?
In my experience, PHP seems to be more in use now than ever.
Conversely, I’m gonna need evidence that PHP is more popular than ever because that absolutely is an extraordinary claim.
it was kind of slow, and all the functions were inconsistent, and had a lot of foot-guns. It was easier to write more robust code and model-view-controller code in other languages. (not that it was impossible in php)
unfortunately it's the only actually viable language in the browser.
* Your web app requires heavily interactive bits, such as smart forms, smart tables, previews, content editing, etc. To deliver such functionality in a maintainable way, you use a framework. (As a side note, yes it is possible to deliver this functionality in vanilla JS, but to make it maintainable one must essentially build an ad hoc framework.) Because most frameworks push users towards a SPA, you end up following the path of least resistance and developing a SPA.
Posts like this frustrate me because you seem to be suggesting complexity in the web domain is largely incidental.
I form this opinion as a professional web developer with 20 years experience.
It’s such a shame that many of these tools are pushed as large SPA solutions when they can just as easily be included ad-hoc over a CDN when necessary.
* And I agree that it’s just madness to wire up your own components once the use case becomes anything more than the most trivial behaviors.
and then I'm still going to say "yeah, i'm roughly equally verbose and spaghetti-like in even the best most prescient framework from the gods themselves" and merely wish for the means of modularization: breaking my server- rendered page that my javascript "unfolds from" into further little bits that can each have their own smaller less-spaghetti like world without having to try to dynamically load and include javascript on the client. Break it up. Divide et impera...