As CEO of Htmx, 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!
As CEO of htmx I agree with everything you said. The synergies we are developing within the web development ecosystem continue to make us a leader in the space.
What's holding me back from trying out HTMX is that people seem to be hitting roadblocks with it when it comes to larger or more complex codebases. Is HTMX suitable for larger enterprise applications? Or is it, as some people have suggested - perhaps cynically - a simple lightweight replacement of jQuery?
For a start, it doesn't have to be a replacement. You can progressively add it in. I work at a very very large organisation with a multi-million line codebase and we splash htmx here and there where it is useful (and where a full blown SPA would be too much to set up). We don't have to ditch any other FE tooling in favour of htmx - htmx "just works" nicely alongside everything else.
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.
I have seen people rewrite entire application from React to htmx.
It works. But the architecture required is a tad different. Also you need Alpine as a complementary library for the reactive parts. (I mean you could do a lot just with htmx but I find Alpine more convenient in many places 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)
The beauty of it is that you don't _need_ Alpine at all, Alpine just comes up because it's popular, it solves the problem of lightweight inline scripting, and it integrates relatively seamlessly with htmx.
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.
> 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.
If you’re using Alpine already, then is there a good reason to use HTMX over alpine Ajax? They both look quite similar to me, but I don’t do enough front end work to tell the difference.
Htmx offers more flexibility than Alpine Ajax. Here's an example: htmx allows using relative selectors, which allow you to target elements relative to the triggering element in the DOM tree. This gives us a lot of power for swapping in pieces of UI without having to make up ids for lots of elements.
I have a blog post in the works for this feature, here's a small code sample I made to show the idea:
I have tried to use exclusively each of the libraries to better understand their limit, overtime I got to the following observations:
- 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.
So, instead of using one JavaScript library with an entire ecosystem of tools that work together, you use two separate uncoordinated JavaScript libraries? Why do you think that's better?
Different libraries composing well together is the default assumption in most of software development. Only in Javascript have people given up on that and accepted that libraries don't work together unless they've been specifically designed, or at least given a compatibility layer, for the framework they're being used in.
Qt widgets don't work together with GTK widgets, and nobody considers this a crisis. I'm pretty sure you can't use Unreal engine stuff in Unity. GUIs require a lot of stuff to compose together seamlessly, and it's hard to do that in a universal way.
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.
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).
I mean, there's a reason people made client-side frameworks in the first place. Distributed state synchronization is really, really hard to do manually.
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.
The reasons however are not so valid anymore in 2026.
Plain HTML has lots of extra features that did not exist in 2010 (form-validation and input-types, canvas, fetch, history-API), and some shortcomings have disappeared (like 'Flash of Unstyled Content'.)
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.
For the vast majority of web apps (including the ones that are built with SPA frameworks now), "how do I do distributed state synchronization" is an example of the XY problem. Most of the time, you don't actually need to write an entire separate app that understands your domain and synchronizes state with the backend, you need something that allows your users to trigger network requests and for the HTML displayed to them to be updated based on the response. Hypermedia is fully capable of solving that problem, completely sidestepping the need to solve the sort of state synchronization problem you mention.
> If you display mutable derivations of the server-side state in more than one place on the client, you're synchronizing it.
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.
OOB swaps are exactly what I'm talking about. That's imperative state management that would be easier with a client side framework. You shouldn't have to manually write out every single part of the app that relies on a single state transition. Do you really think that's scalable? Why would you choose to do that instead of using a tool that completely negates that concern?
You have to manually write that out either way. In the SPA/reactive paradigm, you have to specify that multiple parts of the UI depend on the same part of the state, vs sending down those multiple parts of the UI from the backend.
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.
I use it in one place, where it makes sense: i want the server to template something that works interactively/asyncly. The rest of my current app is, thank God, oldskool SSR HTML request-response over an SQL db.
HTMX would work well with jQuery. But Alpine seems to be more popular in the HTMX crowd. I'd say Alpine is a good replacement for jQuery in my conceptual model.
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).
I've found that just using vanilla JavaScript for this handlers and simple state management also works fine. If you are using a template, each HTML page can have a little JS section at the bottom with glue logic, and it's super easy to read and maintain.
I think the reason htmx and alpine are both popular is that they both get added as html attributes. So you really feel like youre just writing things html a lot of the time.
I've shipped multiple projects running HTMX, and I generally like it.
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.
I can’t tell if calling themselves the CEO of Htmx(sic) is satire or meant to be taken seriously. Heck, I can’t tell if this entire post is satire or meant to be taken seriously.
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've used htmx on several projects in the last 3-4 years and it's a success story. The only issue I've had is when onboarding other developers who don't understand the htmx mindset or wanting to strive for simplicity.
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.
Thanks for being a part of this community. It means a lot that you guys try to connect with users. It gives even my skeptical grey beard a tingle and a reason to try it out.
I made a website in HTMX (https://raku.org) to celebrate that I can use my preferred language on the server side. It’s no frills, generally static and HTMX is just to goose up some of the UX dynamism. It was a very nice experience and I recommend https://htmx.org/examples for the kind of cool things you can do. otoh, I would not build Google Maps with this tool :-)
And most users will have no idea. They just know that it's a super clean, easy to read page that conveys the message you have about Raku.
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.
HTMX seems mature enough for prime time, but for some reason, not yet popular enough that a subset of HN users seem to discover it anew 1-2 times each year: https://hn.algolia.com/?q=htmx
I think it's less "discovered" and people finally try it out? I know at my job, it's basically mandated you're using React (and this has been my experience since ~2018 in a few different companies), so why would you spend your time with a tool you never get to use?
I just cant say enough how much I love HTMX. I got my feet wet doing hotwire/turbo in rails, and htmx is really just such a wonderful expansion of thise ideas. Making reactive app experiences on the web with a tiny js bundle and just writing html feels how web programming should be. I am writing a UI with Spring Boot + Thymleaf + HTMX and Alpine JS, and its the smoothest java based web dev experience ive had in so long. I can look at a page I write in HTMX, and I KNOW if I wrote that in react or angular or vue it would be 50x more complex.
I’ve had a similar experience. HTMX really shifts the complexity back to the server in a way that feels more honest and easier to reason about.
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.
I would probably not build an actual app with HTMX but I found it to be excellent for just making a completely static page feel more dynamic. I'm using it on my two blogs and it makes the whole experience feel much snappier and allows me to carry through an animation from page to page.
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).
I tried HTMx a while ago and felt like I hit a limit pretty quickly where things were getting buggy and it was hard to track down why.
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.
Sure. There's that. But it doesn't progressively enhance. It doesn't even fail gracefully. It's just... nothing without JS. That's bad accessibility. For for-profit and institutional use cases that's fine. But if you're a human person and want to make a website that all human persons around the world can read, it's a bad fit.
Thanks for pointing out a mitigation. I'm confused though. How does "htmx sends a request header HX-Request: true with every request." happen without javascript? And does this imply you need a backend server that understands whatever this header is for the graceful fallback? Ie, it wouldn't work with just nginx...
Can't wait for all the profound and fulfilling work ahead of us in 2026!
Go team!
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.
See https://htmx.org/essays/does-hypermedia-scale/
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/...
2 - https://github.com/mariusGundersen/htmx-json
https://alpine-ajax.js.org/comparisons/
I have a blog post in the works for this feature, here's a small code sample I made to show the idea:
- 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.
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.
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).
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.
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.
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.
[0] https://htmx.org/docs/#oob_swaps
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.
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/ .
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.
https://htmx.org/essays/lore/
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:
https://htmx.org/essays
or our book (free to read online):
https://hypermedia.systems
Also we are working on a version 4 for release later this year:
https://four.htmx.org
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.
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.
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.
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.
Please just try HTMX
https://news.ycombinator.com/item?id=46312973
If you stick to GET and POST requests, you can ensure your app works almost exactly the same with or without JavaScript.