From an htmx perspective, you would probably calculate things like that on the server. So the row delete button might have an hx-get="<delete-confirm-url>" that returns an HTML snippet with your modal content ("Really delete this car?") and then the button in that modal would have hx-delete="<delete-url>".

Of course you can still add vanilla JS with htmx, and/or send the car.rides_delivered value from your model as part of the initial page load, etc. You don't have to do everything with the hx- attributes.

In my opinion htmx is excellent when you have a state that can be easily managed on the server, because it makes it simple to get an interactive SPA feel while still keeping state on the server. I think a lot of the htmx fan base would argue that most web apps don't need to manage their state client-side and therefore don't need all the overhead of React, etc. But of course htmx isn't a cure-all.

You can check out the writing on htmx.org if you're curious to hear more of the author's perspective and goals.

I would say, yes, in this case if you count your html for the button + the ajax request you would need to do to notify the server HTMX is shorter.

But, let's talk about the confirm. For a simple one, you would use hx-confirm and be done.

However, for a more complex confirm, you would make a delete request that would answer HTML.

The HTML would be showing the confirmation with the data calculated from the server (124 rides this year).

The response doesn't have to be a button, the server can answer a modal or a new subpage, which would contain a hx-delete with a "userconfirm=1" in qs and a cancel button to go back.

You don't have to limit yourself to replace the current element with the response, and the response is not limited to basic workflow.

Also HTMX is mostly about using hypermedia to communicate and favor the server to manage the state, but there is nothing saying you can't use JS.

You can even be naughty and have new HTML responses inject new JS in the page.

> This is approaching the code size of the vanilla js version.

Code size isn't everything. The htmx version is more restricted, consistent and declarative. Assuming you get familiar with htmx, if you come back to both code snippets in 6 months, which one will you able to figure out faster?

The HTMX-oriented response would be, if you anticipate needing to know how many rides a car has completed, why not calculate that on the server or in the database, as opposed to in real-time on the client (in which case, presumably, you need to deliver a LOT more data to the client, such as a full list of all rides so you can calculate those which this one car was involved in).

> I don't see which real world use cases are tackled by htmx

Because you are prioritizing state on the client. Free yourself of that, and the use cases for HTMX start expanding enormously.

Sure, but you've gotten rid of a shit-ton of complexity from your stack. No REST+JSON api/graphql. No frontend SPA. The templating system you use can call your db layer directly (or go through an intermediary layer if that's your preference). You solve the "single language" problem, with the backend being favored (rather than the "use npm on the backend because the browser speaks js/ts" approach of the last 10 years). Performance is kept reasonable because you're swapping out elements mainly rather than rerendering the whole page (i.e. it's not a return to servlets/cgi).