At this point I don't even understand why everything has to be a SPA. It's complicated and inefficient and should probably be only used with highly interactive applications like some kind of Photoshop or Ableton live for the web, which means very few apps should use this paradigm. Granted, I'm not much of a frontend dev... but what I know is that if "instant search and other operations over 150,000 records" is a problem then it's probably best to re-think the paradigm.
With SPA, all your backend has to do is spit out data and sometimes validate it, leaving your front-end completely in charge of presentation and user interaction. You can even have completely separate teams working on it. It feels a lot less complicated than the alternative.
Yes Conway's Law:
https://en.wikipedia.org/wiki/Conway%27s_law
The law is based on the reasoning that in order for a product to function, the authors and designers of its component parts must communicate with each other in order to ensure compatibility between the components. Therefore, the technical structure of a system will reflect the social boundaries of the organizations that produced it, across which communication is more difficult. In colloquial terms, it means complex products end up "shaped like" the organizational structure they are designed in or designed for. The law is applied primarily in the field of software architecture, though Conway directed it more broadly and its assumptions and conclusions apply to most technical fields.
That "backend" vs. "frontend" split is entirely artificial. That code you would run server-side to convert your data into a fully-rendered page is still very much part of your "frontend" organizationally, even though it might be hosted on the server.
(Strictly speaking you can have a web service that's purely about spitting out raw data in a form that other organizations can use, but that's the kind of thing that Semantic Web and Linked Data standards are intended to address. Not something that your garden-variety website has to be concerned with.)
OTOH you now need an API and glue code in the frontend. I'm not saying it's not worth it but it's definitely more work.
That's a debate spanning multiple decades. Your last sentence is not true all the time.
SPAs are great for the hordes of B2B SaaS apps out there, which for the most part are just some fancy variants of a table. They're not a Photoshop, but they're still highly interactive.
I think the exact opposite is true, B2B SaaS apps don't need to be an SPA to deal with fancy variants of a table. You can create highly interactive UI with things like Rails and Hotwire, sprinkles of JS or even HTMX. SPA's are bloat and often driven by designers who focus on flashiness rather than good UX.
Even if you use Rails or HTMX to get it done, you're still building an SPA.
If you look at the documentation at nuejs.org/docs, you'll see how Nue is really more about apps that focus on content rather than single-page apps (SPAs). However, this release is all about SPAs.
Yes, sorry for venting on your thread. I do appreciate the idea of leveraging web standards though.
I recently thought about just using ASP.NET MVC with Razor pages for a quite simple app at work. But I'm already familiar with SPAs, so with that background I chose to "just use Vue as always (or Solid or Svelte, I like all three of them)" as SPAs have some advantages, e.g. separation of concerns, easier integration of libs like agGrid or eCharts.
Without that knowledge, I agree that good old SSR (MPA) is easier and more maintainable. And more robust.
Both way can work fine, enough great examples out there. The real problem is, imho, we shouldn't need a (graphical) UI at all. That's where all this discussion comes from. When the whole "frontend" disappears in a year or 10, it will make a lot more sense.
This happened to a team I know. They built a flashy SPA dashboard because it was easy to copy-paste from templates. It worked great—until a real-world requirement, like a data grid, came along.
There's a crossover with crossplatform apps (like React Native), which is a force multiplier for some applications / orgs / etc.
Not the discussion, but SPAs are fundamentally safer against XSS, in the sense that data and code have different paths.
IMO, most SPAs are bloated. MPAs are cleaner and more forgiving.
The only reason to still stick to an SPA instead of an MPA is that the app is so bloated you want the user to only have to load it once.
And people say "lazy loading!" but by the time you've implemented lazy loading in a SPA, you could have just used an MPA to keep things modular and memory efficient.
SPAs became popular at a time when companies thought everyone was going to move to progressive web apps. Then the bloated frameworks came along, PWA interest has faded, and here we are.
The above are all my opinions, apologize in advance if they come off as speaking objectively.