Hacker News new | past | comments | ask | show | jobs | submit login

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.




This seems awfully more complex than maintaining state UI side.


Much simpler based on my experience with LiveView. It's stateful out of the box, no needs to do the manage part.


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.


So when you enter a character into a text field the affected part of the page is then reloaded with fresh HTML?


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.


How does this degrade when connectivity is poor?


In 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


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.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: