Hey, I created htmx and while I appreciate the publicity, I’m not a huge fan of these types of hyperbolic articles. There are lots of different ways to build web apps with their own strengths and weaknesses. I try to assess htmx’s strengths and weaknesses here:
https://htmx.org/essays/when-to-use-hypermedia/
Also, please try unpoly:
It’s another excellent hypermedia oriented library
Edit: the article is actually not nearly as unreasonable as I thought based on the just-f*king-use template. Still prefer a chill vibe for htmx though.
If you are comfortable building web apps like the early adopters did in 1999 that later got mainstreamed with Ruby-on-Rails and related frameworks, HTMX adds a wonderful bit of extra interactivity with great ease.
Want to make a dropdown that updates a enumerated field on a record? Easy.
Want to make a modal dialog when users create a new content item? Easy.
Want a search box with autocomplete? Easy.
As I see it the basic problem of RIA front ends is that a piece of data changed and you have to update the front end accordingly. The complexity of this problem ranges from:
(1) One piece of information is updated on the page (Easy)
(2) Multiple pieces of information are updated but it's a static situation where the back end knows what has to be updated (Easy, HTMX can update more than one element at a time)
(3) Multiple pieces of information but it's dynamic (think of a productivity or decision support application which has lots of panes which may or may not be visible, property sheets, etc -- hard)
You do need some adaptations on the back end to really enjoy HTMX, particularly you have to have some answer to the problem that a partial might be drawn as part of a full page or drawn individually [1] and while you're there you might as well have something that makes it easy to update N partials together.
[1] ... I guess you could have HTMX suck them all down when the page loads but I'd be worried about speed and people seeing incomplete states
Damn, Unpoly looks great! Never tried HTMX but have been a fan of it, it solves a UX problem that frameworks like Django and Rails suffer from, without needing to bring in something heavy like React.
I'm currently working on a side project in Rails using Stimulus but sometimes I wonder if Stimulus is overkill with all of the controllers and stuff as well. Do you have an opinion on when you should reach for something like Inertia or Stimulus over htmx?
HTMX Sucks
Everything in that resonated with me.
so true
How does Unpoly and htmx differ?
unpoly is a more complete framework with concepts like layers and best in class progressive enhancement
htmx is lower level and focuses on generalizing the idea of hypermedia controls
LLMs know nothing about Unpoly, and quite a bit about htmx. This requires you to actually learn Unpoly, because, well, even pointing your LLM-of-choice at the Unpoly docs (which are quite okay!) makes it regress-to-the-ugly-Javascript-workarounds-mean pretty much on try #1.
I'm not yet sure whether this is a good thing or not -- I'll let you know once my latest iteration of my web framework is finally working as I envisioned, he-said sort-of-jokingly, which should be Soon Now.
But yeah, either alternative still beats React by a country mile, since everything related to that descends into madness right away.
I don’t think there is anything in unpoly that a good llm couldn’t figure out with a look over the docs pretty quickly. It’s pretty simple and has some great functionality, especially if you are shooting for progressive enhancement.
Well, I actually use Unpoly, and I can assure you that LLMs don't get it, no matter how many pointers to the (excellent!) docs one includes.
Like, even just now, Claude Code with Opus 4-dot-latest, is absolutely convinced you need a bunch of fragile cascading Javascript listeners to dismiss a lower-level menu in case a dialog is opened, while the Unpoly docs, correctly and clearly, point out that 'shatter' exists for just that purpose.
And this is one of the use cases that I continue to highlight as the achilles heel of LLMs. I'm not holding it wrong: they're not reading it right.
fwiw I'm the CEO of htmx, and I am a huge fan of these types of hyperbolic articles.
I haven't really tried htmx yet, but I used to love intercooler, and your essays are always a fun read. When I saw the title I thought it was some kind of joke from you, because it's like the opposite of your normal style.
I didn't find it too hyperbolic, I think they were very clear on where htmx can help, eg. the section "you're not building Google docs".
Agree updated my comment
I'm curious if the author of the article is an HN reader, and if yes, how this comment is received.
I am tired of people using the smallest "Hello World" example to demonstrate how something is better than React -- "See, you don't need all these things to get a website up and running!"
Of course it will work. I can vibe code the most terrible web framework you have seen within 20 minutes and claim it is better than React, but what does it prove?
> You write zero JavaScript > The whole library is ~14kb gzipped
Oh sure, if there is nothing else in your UI, and if your Python/Go/whatever backend server has 0 dependency, which almost never happens.
To put a bit more colour on this, I think the fear of most devs with an ultra-simple framework like this is that eventually you hit a wall where you need it to do something it doesn't natively do, and because the only thing you know is these magical declarative hx-whatever attributes, there's no way forward.
I appreciate the basic demos, but I think what would really sell me is showing the extensibility story. Show me what it looks like when I need it to do something a bit beyond what it has in the box. Where do I add the JavaScript for that? Is it raw, inline, or are we back to packages and bundling and a build step? Am I building application JS, or some kind of extension or plugin to htmx itself? How chained am I going to be to its specific paradigms and opinions?
The page says htmx isn't for writing a true SPA like Google Docs, but where's the line? Show me an app that has pushed up against the limits of this system, and what happens in that scenario.
(Disclaimer: I haven't actually run into a case where I had to move from HTMX to a SPA framework, even partially, so this is largely an educated guess)
I think this scenario would either be very apparent early on in the project, or wouldn't actually be that challenging. There are a couple ways you could run into the limits of HTMX:
1. You require purely client side interactivity. The right (IMO) way to use HTMX is as a replacement for sending JSON over the wire and rendering it into HTML on the client, so if your app has features that _wouldn't_ be done that way, you should reach for something else. Fortunately there's lots of solutions to this problem. You can use built in browser features to achieve a lot of the basics now (e.g. the <details> tag means you don't really need custom scripts if you just want an accordion), write simple vanila scripts, or adopt light weight libraries like alpinejs or the creator of HTMX's (only slightly deranged) hyperscript.
2. Maybe your purely client side interactivity needs are complex enough that you do need a SPA framework. At that point you can adopt the islands architecture and create interactive components in your fraemwork of choice, but continue to use hypermedia to communicate with the backend.
3. If you can't easily separate client side state (handled with javascript, potentially with the aid of frameworks) from server state (handled on the server and sent to the client via hypermedia), you can again adopt the islands architecture and have your islands manage their own network requests to the backend.
4. If the above applies to all of your app, then hypermedia/HTMX is a bad fit. But this should generally be pretty obvious early on, because it's about the basic, fundamental nature of the app. You probably know you're building google docs when you start build google docs, not mid-way through.
This is where I think Astro shines, with its "islands of interactivity" approach. Keep things as simple as reasonably possible, and provide an idiomatic, first-class mechanism for supporting more complexity where appropriate.
I overlooked Astro for a long time, I didn't really get it, and my journey back to it went something like this:
- 1 Getting burned out by Nextjs slowness in a complex production project that shouldn't be that complex or slow on the dev side, (this was 2022 approx)
- 2 Taking a break from React
- 3 Moving back to classic server side rendering with python and Go and dealing now with template engines. Hyped with HTMX and loving it, but my conclusion after so many years of react was that template partials don't feel right to me and templates engines are somewhat not maintained and evolved as used to be. I found my self not feeling naturally inclined to reach for the htmx way and just let the coding agent do it the way they wanted AND stating to notice again the burn out.
- 4 Looking with some envy to co-workers using shadcn how fast they are getting things done and how good they look.
- 5 Wondering would be a way to use JSX with HTMX server side, I miss components, I don't want partial templates.
And then I found Astro, ahhh now I get it, Astro prioritizes generation over run time, and that unlocks a lot of gradual complexity where you can choose how to mix things ( islands ) you get something way more interesting than a template engine, and it uses JSX so you can benefit from React ecosystem.
This where I am now, but yet I have to complete a side project with it to know if I fully get it and love it.
So far seems to me is the answer I was looking for.
What I don’t get is why I’d use it if I can’t write a reasonable complex SPA with it.
React is easy for small websites so why would I use a separate framework when I can use one framework for everything?
I recently tried a hello-world in react. It made ten network requests on page load and probably had a sizable first download. That’s why web pages are so slow today.
Hello world in react is just a few lines of code that mounts a react component to a dom element. There should be zero network requests beyond the initial download of html and js.
You’re either doing something wrong or not actually doing a hello world.
I don’t know but vite was involved, looks like it was setting up live updates. This is part of the problem, you can’t just include a script apparently.
In fairness, the article has a section titled “The Numbers” which links to this: https://htmx.org/essays/a-real-world-react-to-htmx-port/
Different teams/projects have different needs and require different solutions. While it's good it worked in their favor, I am quite confident that someone else can tell a completely different story. In fact, there are some comments in this very HN discussion that detail their negative experience with htmx. I would not use one or the other to "convince" anybody to go with either solution like what this article attempts to do.
Right, it's also bothered me that the Vue docs spend so much time showing how it's a "progressive" framework. "Just use it for one component!" And show examples of how it can be lazy loaded in for your special complex spot that needs vue.
Like c'mon, if I'm using Vue, I'm using Vue. Same for React. Strap me into the native state management solution for your framework, your router, your preconfigured bundler. I'm not here to mess about or I'd have just stuck with vanilla.
Not having to deal with npm and a build step can remove a huge barrier to adoption for a large number of potential adopters, or people that just want some lightweight interactivity in an app.
Yep, can confirm. I first used Vue in 2016 to write some simple calculators for my group's use in Eve Online. Without its "progressive" affordances, I don't think I would have gotten anything off the ground. I had no idea how to set up a build pipeline at that point, and I think Vue was new enough that there weren't many vue-specific tutorials so I'd have been learning from React tutorials and trying to figure out what to change with zero JS background.
That's what got me into Vue and I still use build less Vue all the time for tiny little sites that aren't worth setting up a whole CI process for. It's really lovely that it's an option.
Just like how easy jQuery was to get started with back in the day, but a whole framework
I did.
My startup did.
And now we’re going to rip it all out and move to a React front-end.
HTMX makes response handling much more complex. Every endpoint returns 3–5 different HTML fragments. Frontend and backend must agree on every scenario — success, validation errors, system errors, partial updates, full reloads.
And HTMX is still a fairly obscure library. The documentation and examples are lacking, there isn’t a real set of established best practices at scale, and not for nothing, LLMs aren’t great at it.
React is mature, used at scale, provides separation of concerns, and is great for agentic AI coding. HTMX has its place for simple projects, but for anything non-trivial, it’s a no for me.
I found the book (hyper media systems) to be better at explaining full integration than the library site, which gives nuts and bolts and big picture, but not much intermediate info.
> Every endpoint returns 3–5 different HTML fragments. Frontend and backend must agree on every scenario — success, validation errors, system errors, partial updates, full reloads.
And why would that differ from React?
When I was building a website with React, I needed to model a "apply coupon" endpoint with different states (coupon applied, coupon does not exist, coupon exists but has reached its max usage limit) and it was so annoying because you needed to
1. The backend route that returns JSON with a different model depending on the coupon state
2. The JSON models for each response type
3. And then on the frontend you need to load the data, parse the JSON, figure out which "response state" it is (http status code? having a "type" field on the JSON?) convert the JSON to HTML and then display it to the user
In my experience it added a lot of extra "mental overhead". It is something that should be extremely simple that ends up being unnecessarily complex, especially when you need to do that for any new feature you want to add.
When using htmx, a simple implementation of that would be
1. A backend route that returns HTML depending on the coupon state
2. Some htmx attributes (hx-post, hx-swap) on the frontend to make the magic happen
Don't get me wrong, there are places that you wouldn't want to use htmx (heavily interactive components) but that's why htmx recommends the "islands of interactivity" pattern. This way you can make the boring things that would add unnecessary complexity when using React with htmx, and then you can spend the unused "mental overhead" with the interactive components. (which, IMO, makes it a more enjoyable experience)
At the end of the day it is just choices: Some people may prefer the React approach, some people may prefer the htmx approach. All of them have their own upsides and downsides and there isn't a real answer to which is better.
But for my use case, htmx (truth to be told: I use my own custom library that's heavily inspired by htmx on my website, but everything that I did could be done with htmx + some htmx extensions) worked wonderfully for me, and I don't plan on "ripping it all out" anytime soon.
Just to be completely clear... you do not need React just so you can turn JSON into HTML. HTMX can 100% can do that.
You're argument is fine assuming you wish to become another react frontend in a sea of react frontends.
But the documentation example is a terrible argument, the benefit of HTMX is it is easy to understand what is actually happening. There is no magic, you don't need to dive through millions of lines of code to figure out what this is doing like react. It's very basic javascript. Just read the library, frankly you don't even need any documentation. Just take 15 mins and read the entire library.
> Frontend and backend must agree on every scenario
When is this not the case?
When an API returns JSON, your JS framework can decide what to do with it. If its returning HTML that's intended to go in a particular place on a page, the front-end has far less flexibility and pretty much has to put it in a specific place. Hence why they said endpoints can return 3-5 different versions of HTML.
> When an API returns JSON, your JS framework can decide what to do with it.
The JS framework is the frontend, so you're still coordinating.
> If its returning HTML that's intended to go in a particular place on a page, the front-end has far less flexibility and pretty much has to put it in a specific place.
Well yes, because presumably that's what the app is supposed to do. If it's not supposed to put it in that place, why would that be the specified target?
If this kind of static assignment of targets is not flexible enough for some reason, then use OOB updates which lets you replace fragments by id attribute. That lets you decouple some of these kinds of decisions.
Although "endpoints can return 3-5 different versions of HTML" is also a bit of a red flag that you're not using htmx correctly, generally endpoints should be returning 1, maybe 2 fragments in unusual cases.
In any case, you might find DataStar more to your liking, it's partway between React and htmx.
It's terrible, why would I want my endpoints to return random HTML fragments? I realize thats how you did it in the JQuery times, but I was never in those - at that time we simply had template engines in the backend so this HTML slop wouldn't contaminate everywhere..
Most of the frontend stuff I do is for internal pages on embedded devices, and I'm very happy with a structure where I have the frontend being a full React fancy component lib SPA that is eventually just compiled down to a zip bundle of files that the backend needs to know nothing about and can serve as dumb files. The backend is a JSON API of sorts that I would need to build anyway for other use cases.
The HTML fragments aren't random.
> It's terrible, why would I want my endpoints to return random HTML fragments?
What would you return instead? It's easy to generate HTML, because that's what your server is already generating (and that's about all it should generate).
HTML is the last thing I would ever want to generate on my embedded device, it's a terribly verbose string-based mess invariably coupled with stylistic choices. Which is why my servers don't generate any of that, they serve static files - and any interactive information in something that looks a lot more like an interface definition.
Okay, so what do you your servers actually serve stuff to?
I kind of don't get why if you want to display something in a web browser you'd generate anything other than HTML.
The thing is React is usually fine, and even if you don't have to build _this_ thing in React due to simplicity, why bother learning two paradigms when you can just use the heavier one for everything and most likely never encounter any real practical showstopping issue?
> why bother learning two paradigms
Objection. Your React is ultimately turning into HTML so you DO have to learn HTML + CSS. You just have an abstraction over it.
That's like saying my C# is getting turned into CLR bytecode, so I do have to learn CLR bytecode because I have an abstraction over it.
Yet I know roughly what it is, but I couldn't begin to actually write the stuff myself.
Good abstractions mean you don't have to worry about the layer below.
Now of course it's not really the case that React holds up to being a good abstraction, especially when it comes to CSS and styling, but I don't think it's a forgone conclusion that abstractions force you to learn the level below.
Otherwise we'd all spend half our time learning assembly.
I do have sympathy though for a developer who just wants to focus on the higher level paradigm and let the library maintainers worry about the innards.
> That's like saying my C# is getting turned into CLR bytecode, so I do have to learn CLR bytecode because I have an abstraction over it.
For a good part of your career this is true, but eventually you will need to justify your senior salary by being able to debug react via looking at library code itself, or understanding the event bubbling under the hood, or figure out why the output css isn't working.
Saw a video, wish I could remember who, someone developing a game in c-something. There was some bug they couldn't figure out so they jumped into I guess the assembly for that block of higher abstracted code, and was able to find some kind of memory issue. Vague, sorry, but point is I remember being really impressed, thinking oh shit yeah if I really want to be an expert in my field I better be able to really understand my stack all the way to the bones.
> That's like saying my C# is getting turned into CLR bytecode, so I do have to learn CLR bytecode because I have an abstraction over it.
That's not a valid analogy, 99.99% of C# developers never see or touch CLR bytecode, where every React developer is still working with HTML+CSS.
That's possibly true, but I wonder why react as an abstraction fails to deliver that kind of independence.
In theory, react developers ought to be able to code against the react API in typescript, without seeing the "raw" HTML+JS that gets delivered to the browser.
So what's failing those developers? Is it the tooling, the abstraction itself, or something else?
Off the top of my head, C# is both the language & the runtime. React only throws things over the fence to browsers.
Probably helps a lot to keep abstractions from leaking.
That just makes HTML/CSS part of the React paradigm though. You can still use all those features in a React app, after all. The 'new paradigm' to learn with HTMX is how it does reactivity/interactivity.
The reality of React is that you have to keep re-learning and un-learning stuff if you want to keep up with React's ecosystem, because the surface area of the libraries is so large. (see "JavaScript fatigue")
Whereas with HTMX you learn a very, very basic concept in 15mins, and you're good to go for the next decade(s), and it will be more than enough for 80% of your projects.
Same as with vim and Emacs vs. proprietary IDEs and text editors.
I agree that people often do this but I don't think you _have_ to. You could have freely ignored SSR, RSC, etc. and kept on making boring old React SPAs. The churn is largely opt-in.
My current app is a boring SPA. SSR, RSC wouldn’t make sense for it. My previous app was a video player with UI drawn in React: couldn’t SSR that.
> you can just use the heavier one for everything
Because people don't like using heavyweight solutions needlessly. That's the logic that begat C++ and Ada and Multics and ASN.1 and CORBA. All of which were good solutions useful for "everything" in their domain. But people hate them, mostly.
Historically big "everything" solutuions end up losing in the market to lighter weight paradigms with more agility and flexibility. Almost every time. React[1] was such a solution once!
[1] Which really is a shorthand for "modern node-based web development with tens of thousands of npm dependencies and thirteen separately-documented API and deployment environemnts to learn".
The thing is most of us have jobs where we can't unilaterally switch to the 'cooler' solution, and I value my own context-switching overhead much more than I value a slightly smaller bundle or dep tree. I'll much sooner optimize the former than the latter and so the general purpose solution that will solve both my own projects and the work ones typically wins.
> most of us have jobs where we can't unilaterally switch to the 'cooler' solution
Which is exactly why the uncool solutions persist in the market. They're useful and practical! If they weren't they never would have been successful at all. I'm just saying that that this is fundamentally the logic of the frumpy old curmudgeon, and the kids will always have something better to offer along with their confusing new ideas.
And to be clear, I'm also just saying that as someone looking in from the outside (I do firmware!) the front end webdev developer onboarding story has long since jumped the complexity shark and things are quite frankly an impenetrable disaster ripe for disruption.
Not HTMX but Alpine.js has been a complete revelation to me. What clicked for me was that you're enhancing server-rendered HTML, not replacing it. Need a dropdown menu? Add x-data="{ open: false }" and you're done. Want to show/hide elements? x-show does exactly what you expect etc.
No bundler required, no compilation step.
I worked on a large commercial AlpineJS app and grew to really, really hate it. It's great for smallish projects where the limits of the tool are known, but it is in no way a drop-in replacement for something like React (and I am no fan of React). People like to throw around how easy it is to do basic things, but building a real app using Alpine is an absolute nightmare.
Alpine data objects can grow to be quite large, so you wind up inlining hundreds of lines of JS as strings within your HTML template, which often limits your editor's ability to do JS checks without additional config.
State management in Alpine is implicit and nested and not a serious solution for building commercial apps IMO.
And don't even get me started on unsafe-eval.
If it's your hobby app and you are the developer and the product owner, go for Alpine. If you're working at a company that is asking you to build a competitive web product in 2025, use a more robust tool. Hotwire and Stimulus has scaled much better from an organization standpoint in my experience.
Have you tried the CSP build of AlpineJS? It takes the code out of the template into a proper JS file, no unsafe-eval. Isn't state management mostly handled on the backend when you use AlpineJS?
Alpine even has a plugin to perform the same function as Htmx if you need it
> But sometimes—and here's where it gets uncomfortable—you actually do need a button that updates part of a page without reloading the whole damn thing. You do need a search box that shows results as you type. You do need interactivity.
You can do this with plain old Javascript. Make a request, swap out the [inner | outer]HTML with the result. If you want a nice visual transition, wrap the swap in a startViewTransition(). Obviously, you need to be extra careful if you're using user-submitted HTML. Otherwise, it's fairly straight forward.
Man I did try htmx, and I was hopeful, right until I saw how it polluted my codebase. I can't say I have the answers, but writing a pure Go app, I'm currently using one giant css file, custom styling and inline html.
And now I'm at the breaking point. So I'm planning to move to tailwind and Go templates, but honestly, i was hopeful for htmx, so I need to properly see the usecase. Which i don't know is this. It reminds me of Angular a lot...
This is the thing. Htmx is great if you only consider the frontend. But it does require fixing up the backed to match. A framework like that needs to integrate the front & back ends fairly tightly to have good UX. You may be interested in Datastar which does this better IMHO
Thanks I'll look into it, but on first glance I feel like I just got space blasted by the website! What happened to simple websites eh
Lol, it's ... a feature ... I think
Well I guess part of the problem is I feel like I'm looking at the website with a magnifying glass...
Turbo with a small sprinkling of stimulus may be closer to what you are hoping for - turbo especially is a lot more opinionated than htmx.
> it polluted my codebase
HTMX is less noisy if you integrate it into your backend framework.
A contact of mine build a python/flask app. To simplify coding, he wrote a file to extend the flask framework to support the HTMX patterns he needed with just a single line of boilerplate. Took him about a day, his team is happy with the results.
It's not less noisy, you just move the noise to the backend
> polluted my codebase
I'd love to hear more about that.
Well listen, we have two modes of operation. It's either html/js/css in the classic sense, or Go templating with some tailwind and JQuery (or whatever the kids are calling it these days). In the case of react, something totally different. But essentially when you try to go that middle path with something that defines its own syntax, it starts to bleed into everything. It's not self contained. I'd argue maybe tailwind is like that as well, so you want to put it in templates or something. But if your htmx code lives in your actual code the way it does with Go a lot of the times because they promote building these partial functions, it looks horrible, very hard to reason or manage. I'm not talking one or two snippets, I'm talking when you have a full blown web app.
The reality is it's going to suit some people and some languages really well and others not so well. I think I like html/css/js and using AI to generate that. But I also like Go templates and trying to isolate that in a programmatic way. I find htmx in principle, a good idea, but when I actually tried to use it, fundamentally the wrong tool for me.
HTMX is a great choice for an app that only needs forms, validation and partial template rendering, though CSS view transitions are making partials less relevant for server side web applications.
For things with heavy interaction (drag and drop, chat etc.), I find the code to make it work with HTMX is just too clumsy to work with as a mental model.
The proselyting over frameworks is the worst bit of the web ecosystem.
If your solution is actually good, it will get adopted eventually...
Forget React, there's still stuff written in jQuery and JSP.
Why the rush to convert everything - you're not a missionary on a mission, just build your stuff in stuff you like?
The attack on npm is ridiculous, when (apart from introducing a permanent vulnerability in the form of a runtime dependency on a third party site), you still need npm for htmx.
> If your solution is actually good, it will get adopted eventually...
This has never been more incorrect. The entire world of software is people using garbage solutions because the CTO is convinced Oracle/Microsoft/what ever new random software is the best thing since sliced bread. In no fashion has the best software solution ever been a factor.
You definitely don't need npm for htmx, it's one file with no dependencies.
For all of the esoteric talk about hypermedia and things like this, this is the greatest advantage of HTMX, why I use and, and also why GP is dead wrong.
> If your solution is actually good, it will get adopted eventually...
I wish this were true.
Unfortunately, often the things that get adopted are the things hyped up the most, not the ones which are technically superior.
Popularity, marketing budgets and inertia often dictate what's popular.
As with all biases, we need to actively and deliberately work against these forces, if we value craftsmanship and professionalism.
Nextjs, great example of this. I've yet to find an actually valid use case to choose it outside of "our incestor's relationship got us unlimited vercel credits for like three years."
What I don’t like with HTMX and the like is that you basically don’t get any help in the backend. It also introduces implicit coupling between the frontend and backend which is very much the worst kind of coupling you can have. While this is fine for small to medium projects it is terrible in the long run.
To be honest this might be a skill issue or something I haven’t understood properly with these frameworks.
> That's HTMX. I didn't write JavaScript to make those work. I wrote HTML attributes.
Well you didn’t write standard HTML attributes, you wrote custom attributes that are picked up by a JS framework, so potentially the worst of both worlds depending on your problem space.
Having tried HTMX a few times, the problem is firmly in creating a backend that feeds it properly. It’s a disjointed experience for anything more complicated than updating content.
HTMX sounds like it works best when you are fetching data from endpoints that would serve HTML already, like <frame>-based sidebar navigation.
Ultimately the complexity does have to live somewhere.
The idea that HTMX removes all the complexity is false. However it does remove some of it, and moves the rest onto the backend.
I find the backend easier to work with, so that's a win for me.
And a batteries included framework (like Laravel or Django) makes HTMX even more appealing. They already have everything you need! :)
I like HTMX, I use it on my blog. But I will say, in the niche where I need some dynamic DOM changes without needing a full-blown SPA, raw JavaScript with some basic utilities like jQuery is not so bad.
The issue with htmx is that it is fairly prescriptive of how one should go about building dynamic interactions, and it becomes complex quickly if the dynamic interaction is more than trivial. I don't disagree with its philosophy at all (as I say, I use it for my own site) but it becomes an issue when my product owner tells me that I need to do some funny dynamic thing because it will make the business or clients happy (for some reason), and then it becomes a mission to wrangle it with htmx attributes. And I have to follow that, because as much as it pains me to say it, making stuff pretty and dynamic on the UI is an easy way to score points. It is one of those areas of enterprise software development which seems like a huge upgrade to non-technical people whilst not requiring too much effort.
The one thing raw JavaScript is quite well suited for is hacking together some DOM manipulation. I dislike JavaScript in every other domain except this - its in this arena where its leniency is very useful.
> After the user downloads 2MB of JavaScript, waits for it to parse, waits for it to execute, waits for it to hydrate, waits for it to fetch data, waits for it to render... yes, then subsequent navigations feel snappy. Congratulations.
In my experience, a lot of SPAs transfer more data than the front-end actually needs. One team I worked on was sending 4MB over the wire to render 14kb of actual HTML. (No, there wasn't some processing happening on the front-end that needed the extra data.) And that was using graphql, some dev just plunked all the fields in the graphql query instead of the ones actually needed. I've seen that pattern a lot, although in some cases it's been to my benefit, like finding more details on a tracking website than the UI presented.
even for "downloads 2MB of JavaScript", it is often simply because the site is badly written (e.g. not careful about managing dependency), not necessarily because "JAVASCRIPT BAD".
Just look at the source code of amazon.com. It's a mess. But I bet it is more of an organizational problem than a tech stack problem, for a website worked on by literally hundreds of teams (if not more) where everyone crams their little feature in the website home page
I've had good success with Turbo (previously Turbolinks). The newer versions (ie. Turbo) really fixed up the shortcomings of the older versions (ie. Turbolinks) and I enjoy using it.
Any big reason to use HTMX instead? Is Turbo not really discussed much because of it's association to RoR?
This incredibly simple text-based website doesn't work without enabling JavaScript and allowing XHR in uMatrix.
Why not "just use HTML"?
It also doesn't appear to have an HTTPS certificate.
I haven't used htmx, but I've given turbo a fair shake. I've only worked on server side rendered apps for my whole career, and they are generally they way to go. But just like react, or anything else, you throw enough engineers at it and it becomes a mess. But also you'll only find a handful of engineers who understand it compared to react, so that makes it worse. I think the bottom line is creating web UI is just as unsolved today as it was 20+ years ago, and nobody can make any headway - it suggests the fundamentals are totally wrong - after all - this isn't what http and html were even built for.
Given sufficient time and money (20+ years, and billions (trillions?) of dollars - which is what we've thrown at web apps) you could build GUI apps using the IRC protocol, but it will never work well.
LLM generated code probably tips the scales toward using react though. You can have the bots churn through all that boiler plate, it won't be any worse than what human react devs write, and keep the bots away from your mission critical code because it isn't all munged together like in a SSR app.
This evangelism around HTMX is bit misplaced.
First - simple use cases sure great. But imagine you have to update some element out of the from tree. Now you need to have OOB swaps and your HTML must contain that fragment.
Not just that your server template code now has to determine if it is HTMX request and only render OOB fragments if so.
Even at decent size app, soon it turns super brittle.
Yet to talk about complicated interfaces. Let's not go complicated just think of variants in an E-commerce admin panel.
3 variants with 5 values each these are 125 SKU rows that must be collapsed group wise.
htmx can do it but it's going to be very very difficult and brittle.
So it is surely very useful but it is NOT the only tool for all use cases.
<button hx-post="/clicked" hx-swap="outerHTML">
No, I'll keep using hiccup and similar things that are just data and nothing more, no syntax, just functions and built-in data structures, then give me HTML as a string which consumers can do whatever with, and we're golden.
how do you feel about this mixing of control logic and display information:
<a href=“/clicked”>click me</a>I keep seeing articles religiously pushing htmx, what I'm not seeing are sophisticated examples or apps written with it, just more basic example and interaction examples.
I personally prefer UIs with great encapsulation/composition, which used to be Vue, but with AI starting to write more of my UIs now I've switched to React/Next.js for new non-progressive UIs.
Datastar has been garnering my attention https://data-star.dev/
I would even say that even "just html" is enough for most website/app. We've been using "just html" at my company ( rosaly.com) for 5 years, we've raised 10 million, have hundreds of customer, and nobody ever complained. And the Android/Ios applications are 234 lines of React-Native which is just embedding a webview , a bit of error screen when there's no internet connection , and intercom library for notification.
My main use of HTMX is to hack the Django Admin here and there. It works great for that. I’ve tried to use it in a moderately complex app and it became such a mess so quickly. I’m sticking with React for frontend stuff for now. Works well enough and I’m used to it now.
The big problem I have with HTMX is the same one I have with React server components and similar concepts; I really like being able to just serve static files. Plus the clear separation of server and client really makes reasoning about a lot of different problem cases a lot easier, that's not something to dismiss lightly. (It's a bit of a 'ship your org chart' case, though)
I don't get why people don't just use vue... with no build step, just including it.
I'm a big fan of it for building micro websites with LLMs, since it can keep pretty much the entire thing in context (even including the docs) it seems to perform pretty well.
To prove the point, author mentions company that went from React to Htmx and saw positive change in relevant metrics. When you do that, it usually means your app has matured in a sense and you can be sure that htmx will be sufficient to handle all the functionality
I'm however more curious about going the other way, i.e. you start a project with Htmx which happily grows but after a while, a large feature is requested which inevitably changes the direction of the app into React use-case territory. I can't think of concrete example but you now have to work around it with htmx or commit to rewriting to React (or alternative). Wonder what are thoughts of people who had to deal with this
So we are almost back to using XSLT (and this is a good thing)
No, and it wouldn’t be, respectively.
(Also, I don’t think we can go back to XSLT in the same sense that I can’t go back to the moon.)
Does XSLT support making HTTP requests to load new content into an existing page?
Sorry, I'm struggling to see the comparison
For those who build in Ruby on Rails, does htmx have an advantage over Turbo/Stimulus? For me, the sense that it doesn't is why I've been avoiding it. Prefer to stick with vanilla stack unless there's a very compelling reason not to.
As the op may read along the other comments, we are tired trying the new shiny thing. Now it is AI's turn to get tired or never.
Dx resources must aim AI's attention having enormous technical documentation and be AI efficient in order to become mainstream.
I believe no other shiniest thing will ever make cognitive nest in humans. We are overloaded.
> Any HTML element can make an HTTP request
> The server just returns HTML (not JSON, actual HTML)
I like to separate presentation HTML from the data (returned from HTTP request). Some like to make backends that do nothing but serve the (singular) frontend, even running templates to make the HTML they return for easy consumption. That's not where I draw the line.
Please install a TLS certificate to the site so people can view the content.
The link doesn't point to an HTTPS server.
Exactly - it's on a short leash towards being blocked by browsers.
https://security.googleblog.com/2025/10/https-by-default.htm...
There is a cert, it's just not signed by a CA.
That's in some sense even worse than plain HTTP, because it gives you a false sense of security.
The author seems to have some beef with angular, which I have found lighter and more pleasant to use compared to react.
Same here. Modern angular is pretty nice to work with.
Yes It has a "learning curve" but so does everything (even React).
Also Angular is now about twenty thousand times simpler than it was in the past as you can use Signals for reactivity, and basically ignore Observables for 95% of things.
Angular also removes the a lot of the negatives outlined in the page - no npm, no node_modules, no ecosystem fatigue, no debates on state management etc etc. Everything you need is included in one dependency you can load from a CDN.
I never liked that in react you are mangling the presentation and business logic in one tsx file (separation of concerns? React ignores that lesson for some reason). Htmx feels even worse in this way because now you also have html snippets and templates in your backend code too! Nightmare! Angular let's you leave the templates as standalone files and not mushed into your typescript like react (although you can inline them into the typescript if you want to, but obviously no one does that for anything apart from the most trivial of components)
I liked the idea that htmx is good for those middle of the road cases where you're not doing anything fancy but I didn't end up using it very often though because if I'm not doing something fancy then I'm not going to ask my user to leave their terminal anyhow.
The framework has been built into the browser for a while now.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid...
SimpleUI helps address the endpoint issue by autogenerating routes for HTMX. It's like a simulation of the frontend running on the backend.
I'm a big fan of returning html instead of json when possible and I've been htmx curious for a bit.
With all the examples people keep using, I assumed it would be way smaller. 16kb minified is a lot.
Looking at the docs just now the core api seems reasonable, but it a lot larger than I'd assumed.
Look into DataStar and Alpine Ajax then, they're much smaller and more targeted.
For those wanting different colored pills, there are
https://justfuckingusereact.com
Ofc if you really want to lose bloat, there's always Htmz
What are some large websites using HTMX? I'd like to check them out.
> Junior devs losing their minds over why useEffect runs twice
Oh now now, even senior devs do this too :)
Sorry, but it's a no from me.
htmx is a great idea, but it's not necessary anymore. We're very close to invokers being baseline (and even that is just an extension of the "composedPath includes -> invoke" pattern), and that will take care of plenty of what htmx was designed to do. Between features like that, and web components, I'm very happy to stick with "plain HTML" (no frameworks; my web components do not draw from a core module or anything).
Also, just a suggestion because it's not technically wrong:
The example of sometimes needing an auto-completing search box is probably not the best one to use. I'm sure it's meant to say "you want the results to be queried from a server/database on every input", which you would certainly need javascript for. But the specific example of just having a search box autocomplete can actually be fulfilled with a datalist element. It won't dynamically re-query results, but it will filter based on input. So it's a muddy example, at best, and that's probably not great for the point trying to be made.
> We're very close to invokers being baseline, and that will take care of plenty of what htmx was designed to do.
From what I've seen, invokers without extra code are designed for client side interactivity (e.g. showing a modal), which is orthogonal to the (correct, IMO) use case of HTMX. You shouldn't use HTMX to turn every custom user interaction into a network round trip, you should use it instead of fetching JSON. If a user interaction wouldn't trigger a network request if you built your app with react/vue/svelte/{insert_framework_of_choice}, then it shouldn't trigger one if you build it with HTMX either.
You can add custom commands with invokes and custom JS, but at that point you're basically re-implementing HTMX yourself, and I'm not sure what the advantage of that would be over hx-trigger="command" (especially when you also consider using fixi if you don't need all the features of HTMX). There's also the triptych proposals [2] from one of the HTMX maintainers which would add some of HTMX's behaviors to HTML, but those are a long way from being baseline, and may get there.
> You can add custom commands with invokes and custom JS, but at that point you're basically re-implementing HTMX yourself[...]
Exactly. So why use a library? If it's that simple, the suggestion is akin to using a library for a toggle, when a checkbox would do. Yes, there are reasons to do it, but no, it's not what I'm going to do most of the time.
ETA: sorry; I should have mentioned, I'm ignoring server stuff because it's not my use case. I don't hydrate code on a server and send it down to people. I just write HTML or let javascript compose it in the browser. Since I don't use frameworks, that's the way I've developed to be efficient. Since I can't speak to how useful htmx is for server-rendered stuff, I'm staying out of it. Just talking about what htmx can do for me, which is very little.
> We're very close to invokers being baseline
Well why not have the benefits of invokers, but today - with HTMX?
HTMX could eventually switch its implementation to use invokers under the hood in the future, and you'd have the convenience of using declarative behaviors on your buttons, today.
> autocomplete can actually be fulfilled with a datalist element
I wish that the spec would cover more use cases, but last time I tried to use it, I couldn't, because it has really bad UX, and is inconsistent across browsers.
Also, like you mentioned, it only works for small data sets that you can deliver with the initial HTML, not large amounts of data which reside on the server.
You could argue that these are use cases where you wouldn't require an auto-complete in the first place, because the data set is too small.
> Well why not have the benefits of invokers, but today - with HTMX?
Because I already have the benefit of invokers, today, using the composedPath method. And a map to some functions is usually less, in my experience, than 14kb of js.
The standard invoker commands deal with the display of already loaded page content in the DOM.
HTMX deals with loading content into the DOM, not managing display of the DOM.
They serve two different roles and together should handle the majority of javascript framework use cases.
Web Components does cover some of the same use case as HTMX, but is intended for when a server is returning data rather than HTML. It is both more powerful and more complex.
> the specific example of just having a search box autocomplete can actually be fulfilled with a datalist element. It won't dynamically re-query results, but it will filter based on input. So it's a muddy example, at best, and that's probably not great for the point trying to be made.
A prefilled list is never an acceptable solution for a search box. A search box is meant to capture arbitrary input. A filterable datalist is not a search box.
> A prefilled list is never an acceptable solution for a search box.
Yes it is. When the query is more expensive than the entire dataset included in some other query, a static list built from previously queried content is the more performant search, even if you want to classify it as a filter. I, as a user, am still searching through this list of unknown nodes even if you, the program, are just filtering what your nodes are for me. All searches are filters; hard lines for best practices only matter insofar as they engage with their practical application.
> The ecosystem is why your node_modules folder is 2GB. The
And every months a few of those modules try to exfiltrate your credentials…
> "I'm not a fucking saint"
You're not a fucking person, this is LLM output.
It starts with the overdone sweary thing then mentions it's overdone and says it's not gonna do it, and it's almost enough to make me think the article is going to offer someone's point of view. But once again the LLM has erased any point of view the author may have had going in (or prevented them from developing it) and replaced it with a mediocre infodump.
I think this is the 5th slop I've seen atop HN in 24 hours.
> This site made by me, with tongue firmly in cheek.
Well, the LLM ruined it, and you didn't even tell us it participated.
I appreciate the discussion that this post sparked. But it is so lame that something like this is LLM generated. It's a perfect setup for some fun creative writing, what is the need to pour slop all over it??
Also the lack of comments calling out the obvious AI style is confusing to me. HN usually jumps on this stuff. Are we just getting tired of calling it out? Or have we just accepted that we're going to read slop sometimes? Or I guess the opportunity to talk about HTMX was probably more important than the post content
My theory is that a lot of people skim articles and then go to comments, or even just skip to comments once there are a few, and that these are "good enough" when skimming to produce a jumping off point for some commentary.
But now that it's very easy to produce articles that pass that test but don't have much value beyond that, we're seeing a lot of low quality stuff make it.
I don't think this is straight LLM, it's probably an homage to a line of websites like https://thebestmotherfucking.website
For sure the author had an idea and went to the LLM to produce the post. And I'm aware of those prior sites (some of which are linked at the bottom.)
I mean nothing is straight LLM, you must prompt them and people are putting their ideas in and linking to other sources and getting stuff like this out. And hopefully editing or iterating, but not enough it would seem most of the time.
I'm saying their perspective doesn't shine through the crap and I'm sick of reading mediocre infodumps from LLMs.
> The whole library is ~14kb gzipped
That'll be item #848 in my 847 line package.json.
> When you click it, HTMX POSTs to /clicked, and whatever HTML the server returns replaces the button. No fetch(). No setState(). No npm install. No fucking webpack config.
Can someone explain something to me?
To my view, the single best idea React has is that it forces you to encapsulate the full set of states in your component - not anywhere else. For instance, if you have a "Comment" button that becomes "Submitted" after you click it, you must include that state inside the comment component. You can't hide it somewhere else (i.e., in the input field after you press cmd-enter). This is a huge thing for managing complexity - if you spread state updates to a number of different places, it becomes significantly harder to reason about how the button works.
Replacing the button with whatever the server responds with may sound simple, but it really makes it hard to answer the question of "what are all the states this button could be in". I mean, what if the server returns another button... which hits another API... etc?
The weird thing is that HTMX talks about Locality of Behavior (yay!), but doesn't seem to practice it at all?
BTW, one other thing:
> The ecosystem is why your node_modules folder is 2GB. The ecosystem is why there are 14 ways to style a component and they all have tradeoffs. The ecosystem is why "which state management library" is somehow still a debate.
> HTMX's ecosystem is: your server-side language of choice. That's it. That's the ecosystem.
Really? Python is my ecosystem. You know that people add stuff to their node_modules because they need it, right? It's not like we do it for fun. Where am I going to find a date-time picker in Python? Am I going to build it from scratch? Where is an autocomplete component in Python? Or mentions?
To your last point: If you're making an HTMX app, you're probably using built-in browser inputs instead of custom JS-based ones like react-select. If you NEED react-select, you probably should just use react. But if your site is mostly just displaying data with html and updating that data with forms, htmx will work great with much less complexity and effort.
I've only toyed around with htmx, but it really is refreshing. Of course you can't do everything that you can do with a fully-fledged client side framework. But once you try it out, you realize that more of the web is just markup + forms than you realized. I wouldn't build a live chat app with htmx, but I would totally build a reporting dashboard.
The author has never heard of jQuery
please just try TLS
If you never seen HTMX it is a small js library that lets you swap some part of your dom with the responses from your webserver.
This means that in theory you (as a dev) don't need (to write any) js, nor do your users need to download a full page (for any interaction) like it's 1999. Your webserver replies with fully server-renderd HTML but just for the dom node (say a div) that you want to replace.
It's fun for very simple things, even great for extremely simple interactions modes. For interactive products, anything beyond simple CRUDs, it's madness.
Whenever you want to sprinkle a tiny bit of interactivity you'll have to choose between the path of least resistance (a small hack on HTMX) or a proper way. State management gets out of control real fast, it's the opposite of UI=f(state).
I've seen it go bad, then worse with alpine-js, and then completely ripped in favor of something where people can let the browser do browser things.
[edit for clarity]
> it is a small js library ... This means that in theory you don't need js
I assume I'm not the only person left a little puzzled.
Do you mean "don't need JS" as in like, a full-fledged JS framework?
Sorry I know other people have responded already, but it means you don't have to write any client side javascript at all. You can just skip along with a server that returns html. Just throw the script tag in there, and you're done.
The magic of this is that it's pretty easy to make SPA-like webapps with no javascript or complex client side framework. You can write your server in python, rust, clojure, whatever. If you don't need a lot of state management, it's really simple and awesome.
See the quickstart from htmx.org
<script src="https://cdn.jsdelivr.net/npm/htmx.org@2.0.8/dist/htmx.min.js"></script>
<!-- have a button POST a click via AJAX -->
<button hx-post="/clicked" hx-swap="outerHTML">
Click Me
</button>
As a dev you get to write HTML, and need to learn about some new tag attributes.
Your browser is still running js.
They mean that you don't need to write JS, you can just add a script tag to your page
> If you never seen HTMX it is a small js library that lets you swap some part of your dom with the responses from your webserver.
> This means that in theory you don't need js, nor do your users need to download a full page like it's 1999. Your webserver replies with fully server-renderd HTML but just for the dom node (say a div) that you want to replace.
You got this backwards. With HTMX you need js. But just to swap a div, you can use link target + iframe, like it's 1999.
You [as a dev] don't need [to write] js.
Your browser will still run js. See sibling thread.
..and be unemployed.
The article doesn't define any target audience in specific, so there you go.
I don't think learning a new tool will cause you to be unemployed.
yeah, I'll try htmx if he will maintain the resulting pile of goo lol
what is the use case. I did not read the page. Can you tell me where stars live?