Maybe (I would instinctively agree). But amount of code is not a good metric for almost anything.
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"
Viewing code as a liability does not make it worse, as not all code as the same level of liability associated with it. I'd much rather have double the lines of code if it yielded a code base that was more maintainable, easier to reason about, easier to debug, and had better separation of concerns.
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.
This pokes at one of my suspicions: Personally, I agree that SPAs are way more complicated and heavyweight than you need for most sites. And they do seem to require a lot of code up-front.
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.
Projects that start out as basic HTML/CSS (perhaps with server generation, like Rails) can run into major problems when they gradually need to start adding interactive features (which, in my experience, is almost certainly going to be the case with any company whose website is a significant part of their product and who have not yet found product-market fit).
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.
> But it's also true that I see a lot of dissatisfaction around the long-term maintainability of doing things in basic HTML/CSS
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)
> Personally, I agree that SPAs are way more complicated and heavyweight than you need for most sites.
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.
The experience is definitely easy, but it's hard to believe that it's simple. Oftentimes things that are very easy on the surface have a whole lot of complexity going on under the hood.
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.
How cloud providers make hosting simpler for SPA and not for server-side rendered apps? Agreed, for the front, you can use something like Netlify. But for the backend, the game has not changed. What do you use?
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"