> huge accretions of complexity for very little payoff
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)?
- 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.
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.
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.
You can edit the title via the 'edit' link for a couple hours. After that it's best to email hn@ycombinator.com, because @dang doesn't work reliably (I happened to see it this time but don't always).
> huge accretions of complexity for very little payoff
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)?
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.
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.
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.
@dang how do I change “Spas” in the title back to “SPAs” as was originally submitted? It’s a misleading title after the automatic transformation.
You can edit the title via the 'edit' link for a couple hours. After that it's best to email hn@ycombinator.com, because @dang doesn't work reliably (I happened to see it this time but don't always).