Server side frameworks force you to keep most state in the URL (or localstorage). This is a limitation. But in my experience it’s not a bad one because only very best designers i worked with were deliberate about state so they could use this advantage.
More likely than not you get designs that create all kinds of messy app states around and users then can’t properly use bookmarks or back button. This in turn leads to hotfixes and more mess in frontend. Forcing designers to think about urls and their names is in most cases very good.
> Server side frameworks force you to keep most state in the URL (or localstorage). This is a limitation.
Rather than limitation, I think of it as a constraint. The best engineering takes place under constraints, because when you're unconstrained you have a high chance of repeating mistakes that have known solutions. In this case, you rightly point out that the UX of the browser has certain limitations and making all state URL-addressable is the interface to that UX.
this is the argument that resonates with me ... increasing complexity around event driven frameworks includes more cognitive load to reason about state information in two (or more) places whereas the web of olden times was conceived around stateless clients (plus some cookies)
as I say in the post, HTMX is not for you if you are building a web app that needs this ... but in 90% of cases web sites don't
More likely than not you get designs that create all kinds of messy app states around and users then can’t properly use bookmarks or back button. This in turn leads to hotfixes and more mess in frontend. Forcing designers to think about urls and their names is in most cases very good.