I think those are all good points, but do cringe a little at the idea that "to add your own JavaScript you'll want React". Seems like a lot to bring in if you're really just wanting to add some JavaScript.
Ha, fair point. I don't mean so much that for any JS you'd want to bring in React, but more that something like that will likely be needed to manage a codebase of any scale.
My context here is a mostly server-side application using HTMX, where I wanted to add a few small bits of additional client-side code. I tried to do it without any libraries but rapidly realised that Jquery would simplify things a lot, and managed to do ok with that, but was still fighting HTMX throughout, and I ended up with a lot of poorly managed local state quite quickly. It doesn't take much complexity to need some better form of state management, and something like React provides some direction there, but of course there are other options, my point was only really to say that HTMX will not do any of this for you, and may get in the way depending on what you need to do.
Yeah, it is insane how complex and wonky attempting to manage state becomes without a coherent model.
I kind of see HTMX as discouraging the traditional SPA-ish state management approach though. Or, it could be that the idea just gives me peace of mind. But, the idea being that you manage state less on the client because you're updating the UI with DOM content generated on the server versus rendering from local state on the client.
In practice, of course, avoiding client-state can be tough, especially as you go from sprinkling in limited dynamic interaction to a full-on SPA experience. I'm a little different though, in that I'm not sure SPAs were ever a good idea—at least without shifting completely away from building directly on Web idioms like DOM, HTML and CSS.
Yeah this is exactly it, HTMX does discourage this. And this is why my conclusion from my experience was that you either need to only use HTMX, or to do frontend "properly" with some sort of state management, because being somewhere in the middle is a pretty bad experience.
React can be added by rendering into a dom node that's not necessarily the root of your app.
Yes, it can be used to render the entire UI app with rich state management across all pages, routing, etc.
However it can just as simply be used to render 1 complex part of an app that has an isolated but possibly complex state. In this scenario I think sprinkling react is reasonable.
I'm admittedly out of touch with current React best practices, but "sprinkling react" isn't a phrase I'd have expected to hear based on my last contact with it. Sprinkling JavaScript or Alpine.js or HTMX, yes. But React seems to come with baggage, no?
Yeah, it seems to me if you're not buying into the entire app being based on React, including JSX with Router/Layout/etc. there's not much point to even using it library.
At that point, you can just write your own Javascript functions / classes for rendering, and handle your own state management
HTMX lends itself more to "sprinkling". Its basically just a very compact version of fetch(), combined with trigger logic (e.g. setTimeout(), onclick, etc.
My context here is a mostly server-side application using HTMX, where I wanted to add a few small bits of additional client-side code. I tried to do it without any libraries but rapidly realised that Jquery would simplify things a lot, and managed to do ok with that, but was still fighting HTMX throughout, and I ended up with a lot of poorly managed local state quite quickly. It doesn't take much complexity to need some better form of state management, and something like React provides some direction there, but of course there are other options, my point was only really to say that HTMX will not do any of this for you, and may get in the way depending on what you need to do.