It's because when you build a SPA you give up a bunch of stuff that comes with the traditional web page model, and it's stuff that most teams overlook until it's too late. They are usually fixated on a certain set of performance issues that drove them to do an SPA in the first place, their energy goes into that, and then they kind of look around at all the other stuff and go, oh, we don't have time for those things.

This is why I typically fight SPAs every step of the way with our clients, if any other architecture will work I see if there is a good case to be made for it, because I know that SPAs are usually going to end up shipping broken in some way.

What kind of stuff do you give up with an SPA?

You give up server redirects and cookie auth. (well you don't lose cookie auth, but you need extra steps for it to prevent CSRF)

You can just have the server return a json object instructing the frontend to navigate, accomplishing server redirects.

Javascript can do browser redirects, but those are not actual 301 HTTP redirects.

Yes, what I'm saying is that you can have the backend return e.g. "{ "response": 301, "redirectUrl": "https://example.com" }", and then have the frontend handle that properly, and you get the functional equivalent.

I'm aware that it is different under the hood.

This didn't come through pwas. We've had ajax for ages before they became a thing and mpa also had opaque state for modals/detail views etc.

Blaming SPAs for such things is like blaming the ocean for a hurricane... Sure, you'd have less hurricanes without the ocean, but it's ultimately not the reason for them

> fast and responsive

I'm sorry but I have to disagree. I've never seen a fast or responsive SPA, not to mention the absurd amounts of resources they require. A tab taking up 400 mb of memory is pure insanity and this is the de facto standard these days. Look at HN: this is the definition of fast and responsive. It will work equally well on my dual-xeon workstation and a first gen raspberry pi zero. This is fast and responsive. Most people who use a computer to navigate the internet would not care if the browser blinks when you navigate a page. Mobile users don't really use the web beyond social media and chats so it makes no difference to them either. SPAs solved a problem no one had by creating 1000 other problems. Just take us back to server side html rendering and I guarantee most ordinary people as well as most developers will love it.

> I've never seen a fast or responsive SPA

Here, let me blow your mind. It's in Czech, but you can click the orange buttons to try the activites: https://gramazing.com/features .

Made with NextJS (client side only), Django, hosted in Germany on a cheap VPS.

And you could do all that with a static generated site. Why it needs to be an SPA?

Yes, I could do it with server rendered site, it wouldn't be as fast though. Also SPAs were my bread and butter with my previous employer, and I have gotten to a point where I am much more comfy with NextJS+Django than SSR Django, Django+homebrew JS or something like HTMX (as much as I wanted to like that one).

Statically generated site is something completely different and I couldn't make Gramazing like that.

> SPAs solved a problem no one had

The problem was: can we make the same data APIs to serve the web and mobile apps?

Current gen frameworks can totally consume the api on server and spit out perfectly normal html to browser just like normal mpa. However this depends on whether you have a competent ops team that is capable to deploy something other than static html. And not having that is the reason you choose spa at first place in a lot of times.

That seems irrelevant to whether SPAs were solving a nonexistent problem when they were invented.

It solves the problem that your ops team sucks and can't deploy anything other than static html while you are required to make a site with proper custom url (and custom content base on url). And to me the quality of ops team is a REAL problem. If it isn't a problem for you then you are just too lucky (I'd envy you ;_;) or never doing any web development.

To be honest, server side rendering is always the king regard of performance. A properly optimized static html generator can make you see the page under 0.5s after you click the link even under most awful network. And it isn't even enough for most spa to download the javascript alone (it will at least need 3 rtt to see basic layouts, one time html, one time js, the js load the images and style)

What I'm saying is that problem might be solved (or solvable) now, e.g. with stuff like Phoenix or NextJS, but it wasn't solved when SPAs were invented.

SPA was never made to solve those problems in my opinion. They are basically unfortunate side effects that introduced when SPA was made to resolve it's original targets. (And without SPA, we would probably never know mess with routes is so damn problematic.)

I had always assumed the problem was "the page flashes for 0.3 seconds when we navigate from View #1 to View #2 as we reload the header and sidebar"

Why did we let them be able to do so?

Who is "we" and how could "we" stop them exactly?

"We" is Browser makers and users. We stop them by taking back control of what runs on our computer.

Because when implemented properly it is a better user experience.

if done properly, this allows the url to represent where you are in the app, and makes back/forward work - like in typical web pages, just without a reload.

Most often though, I see it done inconsistently, and it's a painful mess

Because some sites need to change those things. So they can't just deny it for everybody.