7 ms·
That's how traditional SSR applications work. The new way is html over the wire e.g. Hotwire, Liveview, htmx. So instead of the page being reloaded, the sectio
by theonething 4y ago
That's how traditional SSR applications work.
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.
- bowsamic 4y agoNo 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
- theonething 4y agoWell, 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.
- andrewxdiamond 4y agoThis seems awfully more complex than maintaining state UI side.
- theonething 4y agoNot 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.
- bowsamic 4y agoSo when you enter a character into a text field the affected part of the page is then reloaded with fresh HTML?
- Existenceblinks 4y agoLiveview: 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.
- andrewxdiamond 4y agoHow does this degrade when connectivity is poor?
- granshaw 4y agoIn my experience, not well (we had an important early user have to use our web app from a trailer using the wifi from the main house) So might not be the best approach unless most of your users are at their desk
- Existenceblinks 4y agoMuch simpler based on my experience with LiveView. It's stateful out of the box, no needs to do the manage part.