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 t...
For further actions, you may consider blocking this person and/or reporting abuse
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
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
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.
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.
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.
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?
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!