SPAs are here due to organisational, not technical reasons.
For large organisations it's easier to manage a team of workers with narrow specialisations than a single, but almost equally productive developer like here.
It's particularly visible in banking applications, where modules are almost completely independent and built by non-overlapping teams, so they take forever to load due to the limitation on concurrent requests in browsers.
I've been evaluating some self-hosted/open source company management systems this weekend.
Most of them are classic multi-page PHP apps. It's terrible. I can't stand how it always reloads each time I click on something. I remember it didn't bother me much in the past when everything was like that, but today we have much better options.
I went for a SaaS built as a SPA. When I click on something, for example to create a new entity, I get a modal/side-panel immediately. When I want details, I get them much quicker and can return back to the listing immediately.
> It's particularly visible in banking applications, where modules are almost completely independent and built by non-overlapping teams, so they take forever to load due to the limitation on concurrent requests in browsers.
They just can't code SPAs well. It's perfectly possible to have both quick loading times and very separate modules.
> I can't stand how it always reloads each time I click on something.
And yet here you are, using HackerNews just about every day, which works exactly the same way. No SPA. No 'forever loading', just a classic, fast SSR webapp that treats individual pieces of content as documents, just like how the web was designed to work.
This is a forum, not a management system where I need to open dozens of listings and hundreds of different detail pages and make modifications there.
It also doesn't bother me much on here because HN is much faster than these systems - no wonder, since it's just a forum. But try updating the details of 50 employees, each separated into 5 subpages, when you need to wait 750ms to have each page load. And you need to load that page multiple times - first to get into the detail, then to put it into "edit" mode, then to save it - and then you can switch to a different subpage of the detail.
Amdhal's Law would suggest that much of the 750ms latency is likely attributed to I/O operations (mainly DB ops) and not CPU. Also, without knowing anything about your setup: upgrading to PHP 8 and/or enabling opcode cache may help. All that said, my original quibble was with development time, not run time overheads.
Beauty of that though is that you can CMD+click on each one and open all 50 into separate tabs, then work on each one whilst the others load in the background. Want to cross-reference? Easy, just shift a tab to a new window. All likely not possible in an SPA, either because links don’t work like links, or because it’ll muck up state.
There's no AJAX call in a SPA if all I did was close a detail side-pane to get back to the listing. The AJAX call goes on in background if I saved a modification and I can continue to use the app as it runs. And when I open a detail, at least I'm not watching the whole damn app reload and reconstruct itself from scratch for the 1000th time, and need to download just the data and not the whole bloated HTML mess.
To play Devil's advocate, while I agree with you, in reality it happened multiple times (last one, 2 minutes ago while writing a comment in other HN entry) where I am writing the response but then would like to have a peek at the chain of comments I'm responding to.
Using the phone that's very annoying. I have to long press on the entry's link on the header, open in a new tab, recheck the message trail, and go back to the first tab to end writing.
So simoly as that, I could think of lots of times where a SPA-style dropdown editor box inserted in the conversation view, would be more useful than the current HN's reply page.
If the reply page contained the whole discussion, though, the problem would be equally solved too. So I'm not saying that an SPA would be 100% better, just mentioning an example that occurred to me.
Agreed on all points, it's just that a large part of why they got a foothold is that you can fire one of your three frontend developers on a moment's notice, whereas a single so-called web developer doing their work and more will have leverage.
They're visibly snappier than server-rendered frontends, or even frontends with JS sprinkled on top when done correctly, but large organisations generally don't do them correctly.
You really don't need an spa for this. You can do the same ux with Turbo from Hotwire (and before it Turbolinks) and traditional server side rendering.
There's a massive difference in how I use a forum and how I use a company management system. MPA is fine for a forum, not for a company management system. This is the web indeed, and the company management app is just using the web browser as an app platform. No reason to conflate the two.
For large organisations it's easier to manage a team of workers with narrow specialisations than a single, but almost equally productive developer like here.
It's particularly visible in banking applications, where modules are almost completely independent and built by non-overlapping teams, so they take forever to load due to the limitation on concurrent requests in browsers.