3 ms·

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

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 3y ago
That all sounds a lot more complicated than just continuing to use react
- recursivedoubts 3y 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 3y 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 3y 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 3y ago
    the difference is the wire format: htmx expects hypermedia (HTML) that's the core difference w/ other SPA approaches

robertoandred 3y ago

That all sounds a lot more complicated than just continuing to use react

recursivedoubts 3y 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 3y 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 3y 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 3y ago
  the difference is the wire format: htmx expects hypermedia (HTML) that's the core difference w/ other SPA approaches