I have several problems with htmx, and none of them are love of React or the thousands of NPM modules that make up most modern frontends today. I'm also not a fan of JavaScript itself, and I don't write Node backends unless I can't avoid it.<p>The main problem I have with htmx is it requires my backend and frontend to be uncomfortably coupled. I write most of my backends in Go these days, but I've written a lot of Java and PHP in the past. I particularly hate PHP and the model of mixing backend logic and presentation markup. I'm not a fiend when it comes to separation of concerns; I try to keep relevant things together. With that said, constantly bundling markup with actions is annoying. For example, POSTing a comment would require the backend to send back the new comment's HTML, then possibly perform some action like bumping off comments that are too far down.<p>The other big problem I have with htmx is that it has no good solution for managing state and staying consistent with the backend. I used to work on a site written in PHP that, while not using htmx, used generally the same system of returning HTML from ajax calls. I was working on implementing comment replies, which required not only appending a new comment, but changing some of the markup on the original comment to indicate that it had replies and a button to collapse those replies. The solution I chose for this was to make those changes to the original comment dynamically with raw JS, then append the HTML for the new comment returned by the server. This worked fine, but it was annoying because I had to replicate rendering logic in both JS and PHP. This kind of thing can easily become death by a thousand papercuts as your site grows and you have more and more duplicated rendering code. This problem does not exist in the Vue/React/etc. world.<p>There is value in keeping all your rendering in one place, even if that place is the server and access to it requires enduring network latency. I understand why someone who uses a language other than JS for backend would enjoy htmx, but I think it's going to bite its users in the ass one day or another when their application becomes too big and rendering logic becomes hard to maintain.<p>I would say my favorite alternative to htmx for people who want statically rendered pages but don't want to go without niceties like components, JS type checking, reactivity and other things that speed up frontend development and make it more scalable is Inertia.js. It allows you to use a JS frontend framework like Vue or Svelte and the backend of your choice without having to write an API or (god forbid) GraphQL. <a href="https://inertiajs.com/" rel="nofollow">https://inertiajs.com/</a><p>I've also found that petite-vue is great for adding progressive enhancement to otherwise static sites without using a bloated framework. I've used it in several contract projects and it works like a charm. <a href="https://github.com/vuejs/petite-vue">https://github.com/vuejs/petite-vue</a>