The great thing about HTMX is it fits really nicely with templated server-rendered frameworks like Django.
You can have a page with a list of items. The page is one template, and it includes a sub-template which is just the <li> items. Then you have a separate view for "get list fragment" which just returns the updated/sorted/filtered <li>, rendered with that same sub-template. If you toggle the ordering, or filter the list, HTMX will automatically call the fragment renderer and replace just the <li> items, without reloading the page.
This approach solves the common interactivity use-cases requiring JS in a server-rendered app, without having to write any JS, and without having to build a REST API. Instead you just render HTML, which your framework is excellent at.
But you can already do that. I was doing it in the 90s, Ruby on Rails supports it, etc. Just send the HTML if you want to and call `el.innerHTML = response.body`.
The false dichotomy here is that it's either htmx or React. Why not... neither?
but it does support history, collecting parameters from the DOM, an extensive event model and extension model, targeting other elements, listening for events in sophisticated ways, coordinating multiple elements that are making requests, etc.
so there's some additional stuff in there that makes building a proper hypermedia-driven application easier
I ask similar questions about React ecosystem for years and the most frequent answer is “you’ll know when you need it”. Made few dashboards, smartphone-servers control panel with live streams, svg-heavy fully interactive cashflow graph builder for inhouse accounting, a bunch of typical “react” sites (literally because “frontend dev is slow and we need something right now, they’ll catch up later”, how does that sound) and still waiting for that enlightenment to come.
People throw bs under their feet and then learn how to avoid stepping into it too much. It’s insane. I think that htmx, despite clearly being a breath of fresh air for them, is in the same category: it does all you that could just_do already, but looks nice.
You can have a page with a list of items. The page is one template, and it includes a sub-template which is just the <li> items. Then you have a separate view for "get list fragment" which just returns the updated/sorted/filtered <li>, rendered with that same sub-template. If you toggle the ordering, or filter the list, HTMX will automatically call the fragment renderer and replace just the <li> items, without reloading the page.
See this example: https://github.com/adamchainz/django-htmx/blob/8054f049f53f0...
This approach solves the common interactivity use-cases requiring JS in a server-rendered app, without having to write any JS, and without having to build a REST API. Instead you just render HTML, which your framework is excellent at.