Totally depends on your latency to the server and server response time. Please don’t throw away two decades of client side advancements and do this for state changes that should be entirely local, people with higher latency will hate your guts. Use alpine or something like that if you don’t want to go full react/vue/svelte/solid/etc. It’s utterly terrifying that I now see this pattern evangelized every day.
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.
I've been following projects like Hotwire and HTMX for awhile now, and I haven't seen anyone argue that scraping is a major reason to adopt this approach. I also don't see a lot of opposition to the idea of incorporating something like alpine to add some UI niceness.
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.
Using htmx allows you to completely skip a layer of JSON serialization and parsing. It eliminates the complexity of maintaining a second, frontend application, as well as all of its build tools and dependencies. It even opens up the freedom to work exclusively in your preferred language. All of these are examples of removing elements, not just hiding them somewhere else.
It does not, and I was specifically talking about local state changes. I’ve seen it misused a fair bit, and these trivial examples that tend to be local in real applications don’t help guiding developers who are not keenly aware of the existence of poor connections.
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.
It is honestly a bit too limited example. One way to handle it is for example to appropriately "lock" transaction on HTMX side, which is not done here.
Same. I know this is unfair but it made me subconsciously write off the framework. OP, this is purely marketing feedback but try to make the button fast. Love the direction you're taking, good luck!
That's not really unfair. This trend about moving frontend things to be processed in the server is "coincidentally" what the big cloud providers need to keep hitting their quarterly goals.
Because you're incrementing server side data, not local.
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.
