Recently a friend of mine told me that when he first heard of HTMX, he thought it was a joke, and he wasn't being sarcastic.
He's a cracked dev that ships things that make actual money. He suggested that anyone building a serious system cannot use HTMX, maintainability being the large culprit (no components?).
I haven't looked into HTMX at all, so my question is, has anyone build a serious application with HTMX?
How would you handle a complex system with multiple components in HTMX?
Top comments (20)
HTMX is fine. The problem is internet hype; just because one technology is popular doesn't make it the right choice in every scenario. I have used both React and HTMX in production, and both are fine.
The thing with HTMX, it works well with traditional backends like Django or even Golang (And not forgetting legacy apps). All you're doing is making a network call and fetching a template from the server, really. HTMX is not ideal for complex UIs, but if you using MVC, maintainability is not a problem.
It's easier, in some instances, because a Django developer, for example, can continue working with Django templates, which they prefer, they don't have to setup the whole typescript toolchain and maintain a SPA app in next.js or just React.
For enterprise or CRM type applications that are mostly forms and don't require complex UI's, HTMX is just fine. You can always bring in a library like AlpineJS where it lacks.
Here's some example use cases: htmx.org/examples/
Sounds like you're saying HTMX is fine but should be used only when it makes sense, like with Django on the backend and if using MVC. Makes me think it's not yet ready for wide scale use, would that be fair to say? Also I appreciate the link to the examples!
Yeah, that's correct. It's basically based on the experience of the developer, the size of the team, and how much time you have. There's no one-size-fits-all.
HTMX works well for small teams, usually as mentioned with traditional backends. If you want to build something like Figma, React / Angular / Vue would be better because of the complexity of the UI. (Although Figma uses webassembly).
For a website like dev.to, you can easily build this with HTMX.
The benefit of HTMX, it's just HTML with some attributes, so it's much easier to implement in just about any project. With most JS / TS stacks, there's state, build tools, and various other components to worry about.
Don't think that this qualifies as a complex app, but still the concepts are there.
I think that the straight forward approach of HTMX what derives from it makes a lot of sense -
dev.to/mbarzeev/ive-built-the-todo...
Thanks for sharing, will check it out
Lookup some of the amazing stories on Youtube of companies that have moved to HTMX.
It takes the UI crazyness for me out of the picture.
I built an app with multiple nested components in htmx and it works beautifully. I wrote about the technique here: github.com/yawaramin/dream-html/tr...
Nice. Do you think it's more maintainable than a react app?
I believe so. At the very least, htmx is a single dependency with no transitive deps, no required build system, and almost all the logic is moving to the backend server. If the app uses controls that are on the simpler side and does not need to be highly interactive, htmx works fine.
Been there, always funny how a new thing can sound odd till you see it in action. Curious if someone’s got a story using it at scale.
Same
Sorry to inject this here, but I passed on HTMX early because it looked like it couldn’t scale — too “simple.” Too many voices saying it’s not for “real” projects (despite me actually having built things to test if something is worth building faster then in any other stack by using go+templ...).
So I moved on to React. Because? Well... that's what everyone uses. The “safe” bet for a real product.
Fast forward: I’m now neck-deep in a monorepo with Go backends, TS frontends, and duplicated types everywhere. Lerna, Yarn, tsup, tsc, tsconfigs in triplicate… and all I really needed was an admin panel.
So yeah, maybe HTMX is a joke — but honestly? It’s not the funny one.
TLDR; If you could go back and do it again, would you use HTMX?
yes, I'm quite sure, I would use it (for the admin panel).
it would have given me a predictable workflow, especially since my backend is not node/nextjs.
and the technical limitations in my case would not really apply here. the codebase would be more manageable for me, since i could skip the replication of types, hooks, and caching strategies in the admin-ui.
Also: if i had picked that path, it might have also made it less tempting to build the user-facing UI in react instead of a native app, for example.
not a joke
docs.google.com/presentation/d/1jW...
The perf numbers are amazing but I'm still interested about maintainability, got anything to share there?
I've seen some cool HTMX demos, but I also wonder how people keep things manageable as projects grow. How do you keep track of state or avoid chaos if you have a big team working on it?
Exactly! That's what I want to know too
Ok, it's gonna be quite controversial:
You can totally build a complex system in HTMX. I'm confident in this statement because HTMX brings nothing new and a lot of apps have been build using similar tech. Rails did this for ages (and still do with Hotwire — just in a much more sophisticated way).
I would not choose HTMX for anything complex frontend-wise or serving thousands RPM because of the same reason: it's there for ages and the transition to SPAs and frontend frameworks happened for a good reason — poor functional scalability.
I'm actually in the process of doing an overview of which turns the industry has taken during the last 20 years here and here
Thanks for your insight and tying that in with the historical context of Rails. If you had to use HTMX, what would you use it for?