> I've found that using the websockets extension really helps with automatically keeping the frontend in sync.

I choked reading this imagining people thinking they're doing something simple (as in not complex) by introducing websockets so they can keep state in their Go backend and sync it with their front-end, ya know, to keep track of the # of TODOs checked.

But it is simple :) The underlying technology might be more complex, but the library is solid, it's trivial to update any part of the page once you have the libraries set up, and you don't need to write any javascript. Works for me!

> But it is simple :)

I think you may mean easy. It may be _easy_, but it's not simple. There are so many more moving pieces, failure modes, operational issues now to consider. Websocket connections aren't free.

I guess I just have to disagree. My experience is that it is robust, and removes an entire category of problems that appear when your state is spread across the back- and frontend.

As someone else mentioned, SSE is a somewhat simpler protocol that achieves the same purpose. Same idea though.

why websockets and not just SSE + XHR? Or even just XHR

Edit: SSE*

It is SSR, in the sense that the server sends HTML over the websocket. HTMX swaps out content based on the element id. Doc: https://v1.htmx.org/extensions/web-sockets/

If you mean SSE, then yes that would work just as well (unless you need the bidirectionality for the client to modify some aspect of the connection after the page has loaded). There is an htmx-sse extension too.

I'm not sure how XHR alone would let you automatically get backend state changes reflected to the frontend. You can poll one or more endpoint, but that's more complicated to get right and less efficient.

> I'm not sure how XHR alone would let you automatically get backend state changes reflected to the frontend.

Long polling.

Check out (history of) "Comet": https://en.wikipedia.org/wiki/Comet_(programming)#Implementa...

SSR is effectively long polling with a standardised format and is browser native.

Also writing a client ontop of an existing HTML client is very very easy so even when not on web it's east to implement...

Mostly just thinking that XHR to mutate (form submissions, etc) and then SSE to send the updated DOM elements would be a good combo

Sorry yes I meant SSE, mistyped!

> Mostly just thinking that XHR to mutate (form submissions, etc) and then SSE to send the updated DOM elements would be a good combo

Yes, that's basically the idea.

there's nothing to sync, the state is only in the backend. if you tell the user that the TODO is checked and you're only keeping track of it in the frontend and you don't sync it to the server and it's lost in the meantime, your UI lied to the user when they checked it and it showed as checked. With state on the backend, the user doesn't see that their data is saved until, you know, it actually is. And if all the state is rendered from the backend it can't get out of sync with the display

I hate it when a UI tells me I did an action when really there's an asynchronous background task happening that may fail