1/1/2026 at 7:49:49 PM
> huge accretions of complexity for very little payoffAm I in a minority finding SPAs significantly easier to write and maintain than server-rendered HTML and JS? Or is this point of view merely a reflection of where my experience lay in the 2000s (server-rendered) vs 2020s (SPAs)?
by normie3000
1/1/2026 at 8:09:04 PM
SSR HTML/JS sucks if:- there is repeated code among pages
- the JS isn't in Typescript
- the JS is still using callbacks
- it's using a JS UI framework (Kendo) that you don't like
- the CSS is a mess
All of which was more common closer to 2000 than 2020 because we didn't have things or didn't know better.
SPAs by default at least helped with repeated code and CSS since code organization and maintainability were one of its main selling points. These days most new projects will use Typescript out of the box too.
by hnthrow0287345
1/1/2026 at 8:29:26 PM
I think it's just what you are used to. I think a Spa is easier than server rendered html as well, although server rendering a spa brings its own complications. But the component model à la React is so crucial.by llmslave2
1/1/2026 at 8:13:58 PM
I'm with you brother.Trying to hold sufficient session state on the server and then doing your work afar is a ridiculously hard problem to keep up. The controller of that distributed system is very far from what it's trying to work. State keeping from afar is not pleasant. Especially when there are little pools of state that are essential on that client, when the illusion being worked to maintain keeps breaking down.
A thick client page, that has the agency there, that can operate & control the local experience, is imo just so clearly a simpler system to build and run. It also often has much better performance characteristics.
Representative state transfer allowing the page to become the operator is simpler. Let the client be it's own thing. Give it tools to get and work that state, to update the remote server.
Sounds scary, sounds complex, is mechanically much simpler.
by jauntywundrkind