HTMX is not for highly interactive UIs where most user actions are local, it has its use case.
This takes me back to the top-of-chain comment I made: HTMX has its spot, but I see no world where HTMX needs another layer of JS on top of it. HTMX is not meant for highly-interactive domains, which is almost the exclusive use of JS. Why are we combining these? HTMX is the escape hatch from JS for people who want to do a bit better than true hypermedia but not write JS.
With `htmx` template literal tag recently added to PrimateJS, coupling of HTMX and PrimateJS looks much better in the code than previously. Meaning, single JS dev can do a lot even without knowing these two techs deeply, while leaving behind a code that is more likely to be maintainable. Both PrimateJS and HTMX aim to be simple to use and understand for someone being familiar with HTML and JS alone.
The quick start guide on primatejs.com is just an example of how to try PrimateJS quickly.
If React is what you're looking for feel free to try the PrimateJS React handler https://github.com/primatejs/primate-react.
If a project is appropriate to be built as a multi-page application (MPA), then HTMX can be added to it to give it some SPA like qualities (without having to resort to JS coding).
Moreover, you can implement HTMX along with support for graceful degradation, ensuring that the app continues to function even when JavaScript is disabled.