Of course SSR is simpler- request in, send / receive from a database, markup out. It isnt anything to do with SSR- your domain is simpler.
This echos my thinking whenever these framework/SSR/JavaScript debates come up. It's like everyone is talking past each other because there is no clarity around the complexity of what's being built.
So you're saying the domain is simpler while still satisfying the client's requirements? I think that's exactly the OP's point.
> My conclusion is that SPAs definitely have their place - but that place is in the minority, mostly for web apps with complex UI/UX.
Therefore, it follows that OP finds SSR is simpler, but only because OP only uses SSR for simple problems.
Users do not care about "immense developer productivity"
But a full page reload also clears out memory "leaks", old state accidentally kept around in caches, clinging to DOM nodes discarded long ago, but themselves still referenced by an old copy of a data structure, etc. If you go for a SPA, or even something in between, suddenly being careful about your data structures becomes a major concern to long-term app use, carrying a whole new category of debugging.
Implementing a form that autosubmits and updates an element takes very little js.
I have done a few projects using Knockout and Angular, and I've used Svelte a little too. My conclusion is that SPAs definitely have their place - but that place is in the minority, mostly for web apps with complex UI/UX.
In SSR (Server-Side Rendered) projects (typically ASP.NET Core for me nowadays, but I've used others too), things are just so much simpler, with fewer moving parts. A sprinkling of JavaScript is all that's needed, and even then a lot is reusable between projects. And now IE has finally died, jQuery is no longer needed, and browser support for ES6 is good, even writing JavaScript is less miserable than it used to be.