Now I'm building a linear.app replacement with Claude and Codex working on Django + HTMx + Alpine.js and its going great. Feels a lot more 'snappy' than the default UIs they build with React and so far they've been able to fix every bug and implement some pretty complex drag-drop stuff and other UI niceness that seems pretty stable.
Still have to see if it collapses in a pile of slop at some point / size or if this is how to build software now.
Can't wait for all the profound and fulfilling work ahead of us in 2026!
Go team!
One never uses just one JS lib :) The JS ecosystem always comes with lost of tools, and libs, and bells, and whistles.
I like Elm for this reason. Less choices. Zero runtime errors (I know it is possible in contrived examples, but I've seen and many teams have said the promise holds true after many years of using in production).
HTMX achieves its composability by declining to have opinions about the hard parts. React's ecosystem exists because it abstracts client-side state synchronization, and that inherent complexity doesn't just disappear. When you still have to handle the impedance mismatch between "replace this HTML fragment" and "keep track of what the user is doing", you haven't escaped the complexity. You've just moved it to your server, and you've traded a proven, opinionated framework's solution for a bespoke one that you have to maintain yourself.
If anything, the DOM being a shared substrate means JS frameworks are closer to interoperable than native GUI toolkits ever were. At least you can mount a React component and a Vue component in the same document. They're incompatible with each other because they're each managing local state, event handling, and rendering in an integrated way. However, you can still communicate between them using DOM events. An HTMX date picker may compose better, but that's just because it punts the integration to you.
Ecosystems have their downsides too. Just a small example, no htmx users were impacted by the React Flight Protocol vulnerabilities. Many htmx users have no-build setups: no npm, no package.json, nothing. We don't have to worry about the security vulnerability treadmill and packages and tools arbitrarily breaking and no longer building after some time passes. We just drive the entire webapp from the backend, and it just works.
I have a blog post in the works for this feature, here's a small code sample I made to show the idea:
<div class="card"> ╾──────────────╮
<header class="card-header"> |
<a |
class="button is-link" |
title="Load links for #167" |
role="button" |
aria-expanded="false" |
href="/app/notes/167/links" |
hx-trigger="click once" |
hx-boost="true" |
hx-push-url="false" │
hx-target="closest .card" ╾─╯
╭───╼ hx-swap="beforeend show:none"
| ><b>±</b></a>
| <a
| class="card-header-title"
| href="/app/notes/167"
| hx-boost="true"
| hx-target="#note"
| hx-swap="outerHTML transition:true show:window:top"
| >#167 Velificatio</a>
| </header>
╰╼
</div>- htmx is more straightforward (because a lot of the magic basically happening in the backend) and helps a lot to keep some sanity.
- Alpine shines when you need more composition or reactivity in the frontend. But it gets verbose quickly. When you feel you are reimplementing the web, it means you went too far.
For pagination, page structure, big tables, confirmation after post etc. I usually go with htmx. Modals, complex form composition (especially when you need to populate dropdowns from differents APIs), fancy animations, I prefer Alpine. (I probably could do that with htmx and wrapping it in a backend - but often more flexible in the frontend directly.)
To me, the main reason why I use these libraries, is what I write today will still be valid in 5 years without having to re-write the whole thing, and it matters since I have to maintain most of what I write.
If you don't want to use Alpine for whatever reason, you can just write your own javascript, you can use hyperscript, you can use some other inline scripting library.
Mr. HTMX touches on it in one of the essays: https://htmx.org/essays/hypermedia-friendly-scripting/
> when I need to work with json - since I don't control all backend and json isn't really a first class citizen of htmx
yeah, if you can't make the backend return HTML, you're in a worse off place if you want to use htmx.
There's extensions [1][2] for receiving and rendering JSON responses with htmx (though I haven't used them), but I totally understand it starting to feel like a worse fit.
1 - https://github.com/bigskysoftware/htmx-extensions/blob/main/...
I think HTMX is really well designed for what it is, but I struggle to think of an occasion when it would be the best option. If you have any amount of interactivity, you'll get better DX with a full client side framework. If you don't have much interactivity, then you don't even need a JavaScript library in the first place. Just write a static website.
If you're not displaying derivations of server-side state in more than one place on the client, then you don't need HTMX.
Again, this is the XY problem. Your actual requirement isn't "display mutable derivations of the server-side state in more than one place on the client", it's "update two parts of the DOM in response to user action". You can usually accomplish this with HTMX just fine by either using out of band swaps or swapping out a mutual parent element, depending on your actual needs. You can think of this as state synchronization if you really want to, but it's meaningfully different and significantly easier. Your frontend state isn't a synchronized partial copy of the backend state requiring custom software to manage, it's a projection from that state with embedded possible transitions/mutations.
> If you're not displaying mutable derivations of server-side state in more than one place on the client, then you don't need HTMX.
Even if you think HTMX isn't a good solution and limiting ourselves to swapping out a single element, it very clearly enables a lot of behavior that just isn't possible with standard HTML hypermedia controls (links and forms). Things like active search, infinite scroll, etc. cannot be done with vanila HTML, because you can only trigger HTTP requests with a small subset of events, and if you do trigger one you must replace the entire page.
I'd also argue that if you look at the interactions on web apps, you'll find the number of cases where you would actually need an OOB swap is more limited than you might be thinking.
This isn't just a hypothetical. I have written apps both ways, including porting a few from a SPA framework to a hypermedia based solution. It allowed me to sidestep several major sources of complexity.
Endless scrolling (made popular by Facebook/react) used to be heavy on the browser and sometimes made mobile devices unresponsive. That is not an issue anymore.
Tbh, I can't name a single issue we have today that requires large client-side frameworks for a fix.
HTMX just means: just send incomplete HTML documents over the wire. (some that is done for a long time, but was always frowned upon by the API-first and SPA movements -- and for good reasons (ugly APIs and architecturally less-compatible with SPAs).
Note that HTMX is supposed to be Intercooler 2.0, which is itself using jQuery https://intercoolerjs.org/ .
many enterprise applications are "wide" complex (that is, lots of screens, but relatively simple individually) where the complexity can mainly live server side in the domain model, and hypermedia is great for these
hypermedia isn't always as good for "deep" complex apps, with complicated individual screens, because server round trips are often unacceptable from a latency perspective for them, here client-side scripting of some sort is a better solution. You can use islands for this situation to mix the two models.
Grain of salt too, I'm typically a "DevOps engineer", and I generally lean towards backend development. What I mean to say is that I don't know react and I don't want to.
My understanding of it is that HTMX is a library, whereas React is a framework. With a library, you need to figure out the structure yourself, and that sometimes makes things more difficult since it's another responsibility. This is likely where things fail for the large enterprise apps _not_ using a framework, since structuring the codebase for an enterprise application (and convincing your colleagues to like it) is genuinely difficult and there's no way around that.
> as some people have suggested - perhaps cynically - a simple lightweight replacement of jQuery?
I don't even see this as cynical, I think it's a relatively fair assessment. A key difference is that jQuery has it's own language to learn, whereas htmx is pretty much a few extra html tag attributes.
I'd recommend you just try HTMX out when you have an opportunity to write something small and full stack, you might like it a lot.
Maybe that’s the point? In the “it’s satire” vein, the “htmx.org” URL points to a… X Profile for @htmx_org where the display title is “CEO of National Champs (same thing)”, and has (from the logged out perspective) a lot of memes that are programmer centered around htmx.
In the “it’s a serious post” vein, unfortunately a non-trivial number of HN-linked posts contain verbiage like:
> I would like to express my gratitude for your ongoing support as we continue our journey of strategic execution and operational excellence. I remain steadfast in my commitment to delivering incremental yet impactful value to our stakeholders, optimizing synergies where possible, and increasing market share in a manner that will look excellent in future investor updates. > Can't wait for all the profound and fulfilling work ahead of us in 2026.
And those sentiments are not wholly and consistently criticized as the BS they are, so it’s plausible to believe this about a JavaScript library.
i blame the creator, who is not a serious person
=====
htmx CEO
At one point there was a hostile takeover attempt of the htmx CEO position and, in a desperate poison pill, I declared everyone CEO of htmx.
Turk created https://htmx.ceo if you want to register as a CEO.
If someone emails hr@bigsky.software asking if you are CEO of htmx, I will tell them yes.
You can put it on your LinkedIn, because it’s true.
You might be interested in our essays on hypermedia:
or our book (free to read online):
Also we are working on a version 4 for release later this year:
i think we've done a decent job of getting it back into the zeitgeist though, so hopefully increasingly easy for people to at least consider nowadays
https://htmx.org/essays/the-fetchening/
Basically the core API will remain nearly identical, but we're moving the internals to fetch() which will allow us to support streaming responses, take advantage of the async infrastructure in JS to simplify things, etc.
Hopefully most htmx users won't notice much different when they upgrade.
Yet the biggest benefit is for you; in 3 months or 3 years you'll return to this web site and make some changes, and you'll instantly know what's up. No super complex React / TypeScript / Node app that won't even build.
The amount of custom stuff I needed to add was minimal (just mostly ensuring that if network is gone, it falls back to native navigation to error out).
Examples: https://lucumr.pocoo.org/ and https://dark.ronacher.eu/
I also found Claude to be excellent at understanding HTMX so that definitely helps.
For many apps, especially CRUD-style or internal tools, it removes a lot of accidental complexity without giving up interactivity. The trade-off seems worth it unless you truly need a highly stateful client.
Please just try HTMX
colecut•1d ago
oneeyedpigeon•1d ago
rfmc•1d ago