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/

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'.

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!)

the difference is the wire format: htmx expects hypermedia (HTML)

that's the core difference w/ other SPA approaches