What about amount of features? Time to ship? Time between releases? Number of bugs? User satisfaction? Development costs? ROI? Ease of hiring? Scalability? Reliability?

Not particularly saying an SPA is better at the criteria above (not saying it isn't either), but these criteria are way more important than "amount of code"

First off, there's the reductio ad absurdum in the room: perl. Using perl, I could rip off some amazing things in amazingly little code. (Forth, too, come to think of it.) I think, though, that most of us who initially fell in love with it eventually came to learn that denser code is not necessarily better code. Nowadays I'll gladly take the same thing written in 5X as much Python code.

Second, sometimes more code provides useful things, like bulkheads and seams that allow for easier modification in the future. Over in OO-land, I find that writing SOLID code often increases line counts considerably, but I still strongly prefer my code to be SOLID.

Long story short, I find that code volume can be a proxy for code quality, but it's a very imperfect one.

I really like those analogies, I'll reuse them!

But it's also true that I see a lot of dissatisfaction around the long-term maintainability of doing things in basic HTML/CSS. And I'm not aware of any compelling options that give you better better modularity, but aren't some super heavy-handed SPA-centric framework like React.

It's really easy to use jQuery or some small purpose-built JavaScript library to add simple interactive features like a datepicker or accordion menu. But then you start building your own interactive features, with no framework or architecture in place to manage the ever-increasing amount of client state that is changing in a user session.

At some point (and I would argue it's pretty early on), it becomes far simpler to have a client-side UI framework/library/architecture in place, even if it is initially too heavy for your current needs. Your website is probably not going to need less interactivity as your product and business progresses.

this. I've been front-end for the last several years, and I always tell my managers that front end doesn't need to write for scalability or extensibility (though those are both GOOD!), it needs to first prioritize _replaceability_. Because the "asks" will change dramatically in just a few years, even if the tech doesn't change (and the tech does also change - stupidly fast).

In fact, most backend systems I've seen that are a mess actually work great...if you use them as originally intended. But the current asks are different than those. Software both requires assumptions and doesn't handle changes in assumption well.

Anyone arguing from a point of code purity without acknowledging these facts doesn't persuade me of much. Sadly, this means that in the regular churn we don't get to pull in all the truly valuable points that are left aside with the other items. (See how much of the industry, myself included, is re-learning lessons learned by the early programming pioneers)

This hasn't been my experience at all. SPAs are so simple for me to spin up these days with all the tooling to cover the boilerplate for you, e.g. create-react-app or Vue CLI. With the advent of cloud providers, hosting is insanely simple too. You can get a working SPA out in a day complete with a frontend, backend API, and a database.

In the case of SPA frameworks, I've not spent much time with them (I'm the back end guy on my team), but the most striking things I see whenever I get involved in a project that uses them, and when I've taken the time to learn them, is that there are just so many moving parts. And a whole lot of stuff about the internal logic of whatever SPA framework you're using, and possibly how specifically you're using it, that a newcomer has to know before they can really work efficiently. They're so complicated that I sometimes see people having to do some really elaborate things to get them to play nicely with other stuff they want to do. Using D3 in the same site comes to mind there.

Edit for downvoters: Ok, technically, YouTube is a SPA. What I meant, in the context of this discussion, is that YouTube uses a technique similar to what GitHub does, where the server returns fragments of HTML.