You probably don't need a single page app
plausible.io
plausible.io
The old old school mode of serving static HTML pages is totally fine. I have basically no issue with it. You can't do very much but if your site is a series of interlinked but self-contained documents then it's the gold standard. Once you start having a lot of dynamic content there's a lot of waste since each page is it's own little application.
The 'classic' model of multi-page web design which boils down to templating HTML pages is awful. Truly ungodly awful. I don't care how many layers of DSL you pile on top of it to make it feel less like you're building an application with C preprocessor macros it doesn't make it any better or less brittle.
The SPA model is "more correct" way to do dynamic content since we're back to serving static pages but still ends up terrible since now every single page has emulate browser semantics poorly and deal with the nightmare that is using the browser as a rendering target.
There's got to be some middle ground. I want the browser to be my application router. Give be a site-global place to stick my JS send me an event with what page I need to render.
The contention is that we cannot even agree on basic words. An SPA is anything but "static", it's as dynamic as a website can ever be with all the untrusted JavaScript code that my browser has to execute (hence why browsers are as complex as they are today). A server-side application serving static HTML and CSS ("static" as in "no JS") is much easier to trust.
Your usage of 'static' conflicts with the usage of 'static site generator' where fixed payloads are generated that can be uploaded to any web server. Such sites can have no JS, be full blown SPAs, or anywhere in between.
Some people use "static content" for this but often sites serving static content are still enhanced by JS in some form. Just that the main page content doesn't have any interactivity.
1. Psychological goals: it's more interesting to read "You probably don't need X" articles; they tend to have a bit of snark and humour and brevity to them which more straight-faced "Here's when to use X" don't. Bluntly, I'll read former even when I am nowhere near using X myself, as they may be fun and educational. I will not read the latter unless I'm closely involved with X, because they sound like instruction manual and world is full of those.
2. Target audience is implicitly different in the two titles - they are not interchangeable in my mind.
Assumption is that there is a far larger number of people who ARE using X but SHOULDN'T, and so the title/article "You probably don't need X" is written for them; than people who SHOULD be using X but AREN'T (for whom the latter title is more appropriate).
"Here is when to use x" targets people who don't use x, but should, typically not the audience.
"You probably need y" targets people who might consider y, again not the audience.
In all honesty, I've seen dozens if not hundreds of solo or small team startups/bootstrappers build a SPA they didn't need to and then fail, in part because they were moving to slowly.
The silly thing is, it’s very easy to not do that. It wouldn’t surprise me to learn that a lot of what people hate about SPAs is down to so many people doing a bloody awful job of building them.
If, on the other hand, you need a "site" (which will be relatively static), and you can handle a few extra processor cycles on your webserver, server-side rendering is probably fine. Still, I retain a distaste for it that I can't fully explain.