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)
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.
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 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.
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.
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!
Go team!
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.
depends where the complexity is
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/
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)
10 replies →
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.
7 replies →
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).
4 replies →
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.
htmx has a pretty silly vibe:
https://htmx.org/essays/lore/
i blame the creator, who is not a serious person
3 replies →
Hello all again, not sure why htmx is on HN right now, but happy to answer questions.
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'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.
definitely a different approach & mindset, with its own tradeoffs & feel
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
3 replies →
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.
hell yes
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?
Perhaps people seeing the "Please just try HTMX" post a couple of weeks ago: https://news.ycombinator.com/item?id=46312973
Unfortunately using React will always be more attractive if you want be paid to work to someone.
If I had a nickel for every time Htmx popped up on HN…
from your fingers to God's ear...
you would have over $25k according to another thread here
Seems bumped it ~1e3 times up. 570 threads = 570 nickels ~= $29. Even if consider mentioning comments alongside threads it's ~= 8k nickels = $400.
1 reply →
and another one for Rust, or React, or...
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.
A Hacker News search for "htmx" returns 5,194,298 results
Did you actually used the double quotes to search? Because that narrows down to 570 on my end. The search is including HTML on the result count.
That's gone up by 9,561 results since your comment!
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).
Examples: https://lucumr.pocoo.org/ and https://dark.ronacher.eu/
I also found Claude to be excellent at understanding HTMX so that definitely helps.
Eternal HTMX September.
My main headache is how LLMs are having a hard time with using HtmX as v1, v2, and v4 alpha are all different enough to make debugging hard.
One could of course write and debug the code themselves
I have nothing but good things to say about htmx, both at work and on several personal projects. It really does boost productivity!
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.
What does "linear" mean in this context?
linear.app - popular kanban / pm software [edited original to be less ambiguous]
1 reply →
Related just a few weeks ago:
Please just try HTMX
https://news.ycombinator.com/item?id=46312973
Htmx is not for HTML. Htmx is for javascript. Htmx without javascript is nothing.
...htmx is javascript that allows you to use less javascript.
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.
3 replies →
It's for HTML in sense that your interaction with htmx is through HTML attributes. It's JS-powered but that is of no concern to your usage.