On a reasonably fast connection, I hit the increment button and it took almost two seconds for the counter to increment. Is it immediate for everyone?
As an aside, I hate websites/apps sending HTML fragments like it’s 2005 because it’s much harder to pull data or automate things that way. But that’s usually considered an upside for developers who want to combat scraping. In practice it’s hardly a road bump for devoted scrapers, and actually increases server load for the same amount of data pulled, but it’s still considered a win by many.
What you see as a "terrifying" disregard for "two decades of advancements", others see as a liberating departure from two decades of unnecessary bloat. It's healthy to have more than one strategy available for building web applications.
Is moving the bloat to a blackbox in the backend really a better approach? Why not just not create a bloated frontend?
And I have a strong suspicion for many the beloved hammer is big complex client-side JS framework.
Additionally, while not htmx, in the adjacent land of LiveView, client side scripting is a bitch. I built a complex application in LiveView two years ago and later regretted it. Hard to resolve client side state and server side state diverging with complex but local state changes, and complex local changes are made more difficult than good old imperative jQuery thanks to a managed DOM. It’s extremely tempting to render local state changes with an HTML patch from the server to avoid all the pain, but like I said, high latency users will hate my guts for it.
Worse though, it starts dropping repeated clicks. Triple click increments counter by 2. Unfortunately, this is unusable.
This is just one more layer on top, and one more possible point of failure/frustration, as illustrated by this parent comment.
Which doesn't matter for trivial counter examples but the same technique is something I've used (not with ludic, but with HTMX) to trigger actions in physical space.