Hacker News new | ask | show | jobs
by s6af7ygt 616 days ago
The example on the blog post is one of those that makes me severely question HTMX and the stuff that we're doing. Doing HTTP requests to increase a counter, or affecting any local-only state change at all, seems so wild to me.
3 comments

It makes me question what we are doing too. I'm using HTMX extensively at work, but I never use it to only update local state. A few lines of Javscript on the client will do that.

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.

[0] https://htmx.org/examples/

“Counter app” is basically “hello world”, not how best practice is conveyed.

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.

What’s the use case for a counter that doesn’t update the backend?

For example a like counter wouldn’t be much good if nobody else can see your like.