Am 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)?
- 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.
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.
I mean, soft-navigations need to be enabled and are experimental: https://developer.chrome.com/docs/web-platform/soft-navigati...
I guess that media website could represent a big part of the load where you go for a single view of an article but they would have like you to use them as an app. Opposite to multipage web apps.
tatersolid•1mo ago
dang•1mo ago