I agree that it becomes complex if you have state on the frontend. htmx scales better if you keep all or most of your state on the backend. 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.
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.
As someone else mentioned, SSE is a somewhat simpler protocol that achieves the same purpose. Same idea though.
Edit: SSE*
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.
Long polling.
Check out (history of) "Comet": https://en.wikipedia.org/wiki/Comet_(programming)#Implementa...
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...
Yes, that's basically the idea.
I hate it when a UI tells me I did an action when really there's an asynchronous background task happening that may fail