If you display derivations of server-side state in more than one place on the client, you're synchronizing it.
If you're not displaying derivations of server-side state in more than one place on the client, then you don't need HTMX.
If you're not displaying derivations of server-side state in more than one place on the client, then you don't need HTMX.
Again, this is the XY problem. Your actual requirement isn't "display mutable derivations of the server-side state in more than one place on the client", it's "update two parts of the DOM in response to user action". You can usually accomplish this with HTMX just fine by either using out of band swaps or swapping out a mutual parent element, depending on your actual needs. You can think of this as state synchronization if you really want to, but it's meaningfully different and significantly easier. Your frontend state isn't a synchronized partial copy of the backend state requiring custom software to manage, it's a projection from that state with embedded possible transitions/mutations.
> If you're not displaying mutable derivations of server-side state in more than one place on the client, then you don't need HTMX.
Even if you think HTMX isn't a good solution and limiting ourselves to swapping out a single element, it very clearly enables a lot of behavior that just isn't possible with standard HTML hypermedia controls (links and forms). Things like active search, infinite scroll, etc. cannot be done with vanila HTML, because you can only trigger HTTP requests with a small subset of events, and if you do trigger one you must replace the entire page.
I'd also argue that if you look at the interactions on web apps, you'll find the number of cases where you would actually need an OOB swap is more limited than you might be thinking.
This isn't just a hypothetical. I have written apps both ways, including porting a few from a SPA framework to a hypermedia based solution. It allowed me to sidestep several major sources of complexity.