SPAs Were a Mistake

2. Hard to believe that is true in the general case.

Typical scenario for SPA is to use some sort of REST API, these API:s are usually designed for general usage, not specific usage, i.e. designed to be reused between components and views thus they basically return everything of a specific model regardless if data is needed or not.

Therefore the controller queries the database with the equivalent of SELECT * on a table (or perhaps multiple tables with joins) and then exposes every field.

And in many cases one request is not enough because the common generic design of REST APIs, thus a few request more are fired that results in multiple SELECT * against the database, and eventually the equivalent of SQL JOIN is performed in JavaScript.

Already SPA solution has an increased cost by asking for data that is currently not needed, not only in the traffic between the database and the backend but also in the traffic between the backend and the frontend.

And because we want to be good REST citizens we sprinkle the JSON payload with timestamps, resource urls and pagination information and what not and in majority of cases never to be used.

Comparing that to SSR where you can fetch what you need from the database with custom SQL query (I hope you do, otherwise the SQL leprechaun will make a visit).

Just imaging how much data there is on the web that is requested and then just discarded, not even looked at.

It is possible to design custom REST endpoints for each component, but then of course what is the point of a SPA then? If you are already writing a custom REST endpoint just return HTML instead of JSON and then swap in the new and swap out the old for your component (one-liner), the end result is the same.

SQL -> (Array of) object(s) -> JSON -> Javascript (Array of) object(s) -> HTML

can therefore be shortened to

SQL -> (Array of) object(s) -> HTML

3. That doesn't make any sense, number of languages are still the same regardless.

Don't don't do what I would do. The mistake is forgetting first principles. You don't do something good by focusing on what not to do (like don't be evil). Focus on what to do: KISS, YAGNI, etc.. even DRY is a far lower priority. Software, especially frontend and web are rampant with problems from operating as an echo chamber. Just consider what Ryan did with Deno and had to say criticizing his first project. Yet folks are still wildly supportive of the older technical decisions and go to great lengths to preserve those same mistakes.

Everytime I see one of these binary "XYZ is good/bad" posts I come away thinking that either I don't know what I'm doing, or the author doesn't.

Having built relatively simple Django web applications, and having built and managed building complex SPAs with Angular/React and GraphQL backends, I have a hard time thinking of when I would ever willingly grab for serving up dynamic HTML ever again.

The mixing of concerns with something like Django vs just having a native JS application loaded and running in the browser pulling in data as needed once loaded is a world of difference.

Using straw man examples of people using a technology badly to claim the technology itself is a mistake is silly.

There's literal annals of examples of poor memory management in compiled software causing massive issues. Is allowing memory management to be handled directly by software engineers a mistake? In some cases, yes, people would be better off with garbage collection. But you'd have a revolt in embedded systems development if that was taken away.

SPAs create more surface area for inexperienced or poor developers to screw up the UX. But a talented team developing SPAs (which really is a misnomer as you're rarely not chunking and lazy loading things behind the scenes) will ALWAYS result in a better UX for users than dealing with the browsers loading individual pages, and very likely more manageable development too.

That said, as I've spent more time in development I've noticed there's a noticeable shortage of talented teams out there.

A lot of the arguments against SPAs in TFA center on broken U/X. This is only incidentally related to SPA architecture, and has much more to do with the current SPA ecosystem. IMO it’s more just a lack of standardization and the broken U/X is just an emergent property of the vacuum. MPAs are great because the technology is old and navigation between pages has first class support in all browsers, not because of some intrinsic advantage of the way application state is managed.

If it's an "application" there are no "pages" as that's an old (very old) and deprecated construct. Now if it's a "web site" with a collection of "web pages" - that's another matter. I've been building commercial SPAs now for over 20 years and I can say with much authority that users prefer "applications" over "web sites" for complex business management tasks.

I've also built some pretty huge static web sites (longwoodgardens.org for example) and it an absolute joy to do those as well. I would never recommend to such a client that they build an SPA.

So I'll state this opposing view - that "web sites" were a mistake when used for complex business applications.