https://farmrio.deco.site/ is one of the largest clothing retailers in Brazil and all the frontend interactions use HTMX, alongside a partial rendering strategy we developed.
More info at https://deco.cx/en/blog/htmx-first-class-support
However I think it's a powerful solution to updating the DOM when state changes on the backend and a roundtrip is required anyway. For that matter the examples on the official project site are better to understand proper use cases for HTMX [0].
Personally I use Active Search and Edit/Delete Row a lot. While Active Search does not change state in the backend, I found it's still a valid use case for HTMX when searching large data sets, since the backend is (in my case) just way faster to search through a large data set.
It all comes down to your ability as a developer to find the proper solution to the problem at hand. A counter does not need HTMX.
If you’re using an HTTP request to update a counter, it would be to update the persistent server-side state of that counter (which you’d also do if you’re using React and a JSON API).
No one is advocating for using HTMX for purely client-side state. They’ve been very consistent about this, recommending Alpine, vanilla JS, Stimulus, Vue, and so forth when you need pure client-side state.
For example a like counter wouldn’t be much good if nobody else can see your like.
You're artificially making your FCP also be your TTI, which means page navigation, when everything should be cached and fast, feels slow. That's not something e.g. Lighthouse tells you.
I recommend showing the page right away, even if there's going to be jank. Jank/Cumulative layout shifts can be fixed later.