They touch on it at the end but I think it is under-appreciated ... the big benefit of a SPA is continuity of client side state. I don't actually care whether it's one page or ten but it does simplify things enormously that I can maintain a single model object and not have to persist it in and out of local storage or even worse have all the complex UI state replicated on the server side to maintain continuity, just because the user clicked a button or something. Especially with reactive frameworks where updating the model automatically triggers re-rendering of the UI everywhere it needs to, a whole piece of complexity in your architecture just goes away.
I actually see having to manage client side state as one of SPAs' greatest downsides. You're literally doubling the complexity of your application. Now you have to maintain state on both the server and the client and it becomes a great effort to make sure they don't get out of sync.
The way I see it, the state of an application resides in the server, more specifically, the database. Let's keep it there.
If your UI is rendered on the server, then your UI state remains on the server. It just ferries that state to the client. There's no synchronization involved because it's synchronized by default.
The new way is html over the wire e.g. Hotwire, Liveview, htmx. So instead of the page being reloaded, the section of the UI that needs to updated is rendered on the server and sent over via websocket.
Not in my experience. I've worked on several react apps. Currently doing a Hotwire project and it's just so much simpler to keep all state on the server side.
Liveview: it sends event to server and the server handle the event, then send "diff" to client (and automatically patch the dom) .. all of these via websocket, it's fast.
No they don’t, they use web forms, which are a local UI state that gets bundled up and sent when the user presses a submit button. They do not refresh on every single UI change
Well, ok, if you're thinking of UI state in that way, you're right. I was thinking of UI state in terms of how it's stored and manipulated in client-side JS.
To your original question, my proposal is that html over the wire provides a good solution without the need for state to reside and change in client JS.
But the application is embedded in a browser. Are you saying it's fine to bin all that UI state the moment the user performs a totally normal interaction with their browser? Accidentally hitting back or refresh in a complex SPA and losing the state of the application is one of the most frustrating experiences on the web, right behind trying to hit back or refresh intentionally and being blocked because the SPA overrides those functions.
No? I simply clarified which state op was referring to. The state of the browser is separate to what's being discussed. SPA's can be good at some state and not others.
