We created a generation of developers that AIM to over-engineer requirements... and we also came up with extremely pervasive frameworks to go with it... My firm cannot hire people with no React experience... people REALLY only know how to build cruft these days...

I have no React, Vue, or Angular experience. My websites were built with Livewire, some HTMX (basically Hotwire in the Rails world, server rendered HTML partials; or maybe Blazor SSR in the .NET world). I use Tailwind and a Laravel backend, but have some experience with C#.

If you think that’s interesting, send me your firm’s URL, I’ll consider applying. (Edit: or really anyone reading this who is interested - government of a foreign nation outside the US is not viable, unfortunately.)

my firm is government, so do not expect too much... email to {trafalgar battle british general's last name]@rails.cl

As a Rails developer with no desire to work in a React codebase, I'm not qualified for about 50-60% of the Rails jobs postings. My lastest full time was at Shopify where I said over an over that I was Ruby only and not interested in a React position only to be told a few months in I needed to know React to get promoted. It is exhausting.

I have given up on doing frontend work for the time being, because of this crap. I used to do full stack with modern JS, TS, CSS, HTML and whatnot, but then someone made it all go to shit by advertising for NextJS and React, while there was zero interactivity on the whole platform, except for a couple of checkboxes. A few years later, there still isn't much. Some page transitions for when things happen in the backend. I told them in the beginning, that there is not much interactive stuff, but they all got flashed by some one minute low effort Material Design shit, and the idea of the whole thing being "modern" and hiring more React devs. So I stepped away from that while frontend part and let them dig their own hole.

Moving a navigation/menu from one app to another takes 3 people 2-3 weeks by now. Changing the "router" to update the TS version is just as time consuming. Things that would have taken 1 day max. take now 2-3 weeks. That is 1/14th of the productivity and people get paid for that, more than I did. Oh and did I mention the menu responsiveness was broken for months at a certain viewport width? I did report it, but apparently it was so hard to fix, that it could not be done in a quiet hour, so it took months laying around in the queue of things to fix.

Might be a bit of a selection bias though. I certainly remember a lot of crappy MPAs before SPAs got big. The crappines just moved to SPAs as they became mainstream. Overall I agree that MPAs are better default, though, good SPAs are hard to build.

Part of the complaints about MPAs originally was that navigating all the different pages was slow, because loading new pages was slow. But plenty of today's SPAs deliver content even slower and the user is staring at a spinner for lengthy stretches. The key is quick, efficient server responses, whether using SPA or MPA approaches.

Yeah. In theory SPAs should be faster, but in practice rendering/sending the whole template is not as bad. And as you mention, both can be slow, due to the non-cached API/DB call, so...

Even in theory, producing json is just typically slower than producing HTML.

It seems unintuitive, but traversing an object tree using reflection to generate json is just slower than using an HTML template, which is probably a rope data structure.

Rendering the template or JSON response is the last and probably often the least computationally expensive step though.

I guess the rendering itself is pretty much the same for both SPAs and MPAs, since in the end it can be pretty much the same markup, but the SPA is also at a disadvantage here because it has to combine template/components + JSON to generate the HTML :/

That reminds me of when I first benchmarked a Rails app and noticed that JSON rendering was significantly slower than the remote database call. No lie, jbuilder was taking about 80% of the request time for about 90% of all endpoints.

Oh, totally. I myself have written on how GitHub manages to make client side navigation 2x slower than full page reload: https://yoyo-code.com/why-is-github-ui-getting-so-much-slowe...

great article!

Issues with old school websites before SPAs were usually "kinda clunky/hard to navigate/find stuff" and "ugly/inconsistent UI."

Issues with SPAs are "core features straight up don't work " and "page is now just an endless spinner."

I know which I prefer.