Comment by PedroBatista
2 days ago
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)
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.
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
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.
https://alpine-ajax.js.org/comparisons/
2 replies →
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?
5 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.
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.
4 replies →
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.
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.
1 reply →
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.
> HTMX would work well with jQuery.
Note that HTMX is supposed to be Intercooler 2.0, which is itself using jQuery https://intercoolerjs.org/ .
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
Thanks; it felt a more Reddit-y vibe than an HN Discussion post vibe.
as the creator and CEO, I blame it on LLMs
Fascinating!
=====
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.