4 ms·

How does all the "executed once on the first request" and video keeps running work in htmx? Is it an SPA, from the browser's perspective, just an SPA that follo

by usrusr 2y ago

How does all the "executed once on the first request" and video keeps running work in htmx? Is it an SPA, from the browser's perspective, just an SPA that follows the MPA model, in its interactions with the server, basically applying a diff to the SPA state? Not saying that's a bad thing, just trying to understand. Could be an awesome migration path to get some SPA benefits into an existing MPA.

recursivedoubts 2y ago
in plain htmx, you can target an area that doesn't disrupt a playing video (e.g. the comments box appending to the comments) or you can use a morphing algorithm that disrupts the DOM less. i have my own morphing algorithm (and a corresponding htmx plugin that allows you to use it) called idiomorph: https://github.com/bigskysoftware/idiomorph/ https://github.com/bigskysoftware/idiomorph/ i've also been working with the chrome team to get a feature added they are calling "atomic moves": https://github.com/whatwg/dom/issues/1255 https://github.com/whatwg/dom/issues/1255 this would allow us to move elements around in the DOM without losing things like play state or focus or whatever very excited for this last idea, I think it will be a huge boon for the web in general, not just for htmx
- robertoandred 2y ago
  That all sounds a lot more complicated than just continuing to use react
  - recursivedoubts 2y ago
    sure, it depends the first option isn’t bad once you get the htmx mental model, but preserving video elements is on the edge of what htmx is a good fit for otoh, when it’s a good fit you can simplify your app a lot: https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/
  - yawaramin 2y ago
    They are complicated in different ways. With htmx, you plan and prepare partial page updates yourself and htmx swaps them in for you. With React, you get to maintain the entire npm toolchain that your app depends on, including fun things like 'React 19 will no longer patch the fetch() function, so you have to handle double-fetch manually'.
  - usrusr 2y ago
    Yeah, it doesn't really read like it matches much with the claim of the article that htmx is the rebirth of the MPA. But then on the other hand, the picture that builds in my mind turns more and more into "SPA, but everything is declarative" (except for extensions to the declarative toolkit that are easy to keep separated from domain code), and that could really be quite awesome. More so when you come from an MPA background anyways. (or when your codebase comes from an MPA background!)
    - recursivedoubts 2y ago
      the difference is the wire format: htmx expects hypermedia (HTML) that's the core difference w/ other SPA approaches

by usrusr 2y ago

recursivedoubts 2y ago

in plain htmx, you can target an area that doesn't disrupt a playing video (e.g. the comments box appending to the comments) or you can use a morphing algorithm that disrupts the DOM less. i have my own morphing algorithm (and a corresponding htmx plugin that allows you to use it) called idiomorph: https://github.com/bigskysoftware/idiomorph/ https://github.com/bigskysoftware/idiomorph/ i've also been working with the chrome team to get a feature added they are calling "atomic moves": https://github.com/whatwg/dom/issues/1255 https://github.com/whatwg/dom/issues/1255 this would allow us to move elements around in the DOM without losing things like play state or focus or whatever very excited for this last idea, I think it will be a huge boon for the web in general, not just for htmx

robertoandred 2y ago
That all sounds a lot more complicated than just continuing to use react
- recursivedoubts 2y ago
  sure, it depends the first option isn’t bad once you get the htmx mental model, but preserving video elements is on the edge of what htmx is a good fit for otoh, when it’s a good fit you can simplify your app a lot: https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/
- yawaramin 2y ago
  They are complicated in different ways. With htmx, you plan and prepare partial page updates yourself and htmx swaps them in for you. With React, you get to maintain the entire npm toolchain that your app depends on, including fun things like 'React 19 will no longer patch the fetch() function, so you have to handle double-fetch manually'.
- usrusr 2y ago
  Yeah, it doesn't really read like it matches much with the claim of the article that htmx is the rebirth of the MPA. But then on the other hand, the picture that builds in my mind turns more and more into "SPA, but everything is declarative" (except for extensions to the declarative toolkit that are easy to keep separated from domain code), and that could really be quite awesome. More so when you come from an MPA background anyways. (or when your codebase comes from an MPA background!)
  - recursivedoubts 2y ago
    the difference is the wire format: htmx expects hypermedia (HTML) that's the core difference w/ other SPA approaches