3 ms·

I'm not super-stoked about the idea of building SPAs on top of htmx, but what I have found works incredibly well is to build a traditional MPA (SSR etc), embed

I'm not super-stoked about the idea of building SPAs on top of htmx, but what I have found works incredibly well is to build a traditional MPA (SSR etc), embed islands of interactivity where needed, and where something fancier is really necessary, embed a React or Svelte app into just that one portion of a single page.

swyx 2y ago
yea im not even talking about SPAs in my post, just the complexity explosion that comes with updating state in more than 1 place / preserving ui state in the place that gets rerendered. it blows up in your face quickly if you have even any requirement volatility (https://stackoverflow.blog/2020/02/20/requirements-volatility-is-the-core-problem-of-software-engineering/ https://stackoverflow.blog/2020/02/20/requirements-volatilit...)
- jonathrg 2y ago
  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.
  - ctvo 2y ago
    > 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.
    - jonathrg 2y ago
      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!
      - maddalax 2y ago
        why websockets and not just SSE + XHR? Or even just XHR Edit: SSE*
        jonathrg 2y ago
        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/ 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.
        maddalax 2y ago
        Sorry yes I meant SSE, mistyped!
        jonathrg 2y ago
        > 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.
        maddalax 2y ago
        Mostly just thinking that XHR to mutate (form submissions, etc) and then SSE to send the updated DOM elements would be a good combo
        klibertp 2y ago
        > 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)#Implementations https://en.wikipedia.org/wiki/Comet_(programming)#Implementa...
    - dingnuts 2y ago
      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
- recursivedoubts 2y ago
  idk worked ok for these guys: https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/ htmx can work well for a reasonably large class of web applications. not all, and certainly not all UI patterns, but w/a bit of a mind shift to the hypermedia approach & a bit of accepting some limitations thereof you can simplify a lot of things pretty significantly. if you try to shoehorn it in to the SPA mindset, triggering server requests on every interaction, yeah, it's not gonna be great

swyx 2y ago

yea im not even talking about SPAs in my post, just the complexity explosion that comes with updating state in more than 1 place / preserving ui state in the place that gets rerendered. it blows up in your face quickly if you have even any requirement volatility (https://stackoverflow.blog/2020/02/20/requirements-volatility-is-the-core-problem-of-software-engineering/ https://stackoverflow.blog/2020/02/20/requirements-volatilit...)

jonathrg 2y ago
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.
- ctvo 2y ago
  > 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.
  - jonathrg 2y ago
    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!
    - maddalax 2y ago
      why websockets and not just SSE + XHR? Or even just XHR Edit: SSE*
      - jonathrg 2y ago
        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/ 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.
        maddalax 2y ago
        Sorry yes I meant SSE, mistyped!
        jonathrg 2y ago
        > 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.
        maddalax 2y ago
        Mostly just thinking that XHR to mutate (form submissions, etc) and then SSE to send the updated DOM elements would be a good combo
        klibertp 2y ago
        > 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)#Implementations https://en.wikipedia.org/wiki/Comet_(programming)#Implementa...
  - dingnuts 2y ago
    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
recursivedoubts 2y ago
idk worked ok for these guys: https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/ htmx can work well for a reasonably large class of web applications. not all, and certainly not all UI patterns, but w/a bit of a mind shift to the hypermedia approach & a bit of accepting some limitations thereof you can simplify a lot of things pretty significantly. if you try to shoehorn it in to the SPA mindset, triggering server requests on every interaction, yeah, it's not gonna be great