alt Hacker NewsPlease just try HTMX
Comments
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.
> 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.
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.
I did. I found it to have quite a few problems with bugs, docs, and web page lifecycle.
I switched to Hotwire/Stimulus and found it to be a significantly better implementation of the same core concepts. I'd highly recommend checking them out.
> Or are you building another dashboard, another admin panel, another e-commerce site, another blog, another SaaS app that's fundamentally just forms and tables and lists?
Install an open source admin panel and call it a day.
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...
For those wanting different colored pills, there are
https://justfuckingusereact.com
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.
> You do need a search box that shows results as you type. You do need interactivity.
You can use JavaScript for it.
I've been trying lately ruby templates with some occasional JS for this and it works great.
Or implement a straight forward web component.
I love HTMX. It felt like a rebirth of PJAX. Server side template rendering is simply the best.
Too bad that the world insists on going nuts with JS everything.
Oh as a plus, AI agents are a lot more productive when dealing with server side logic.
> Junior devs losing their minds over why useEffect runs twice
Oh now now, even senior devs do this too :)
Can highly recommend HTMX with Astro[1] for pages that are mostly static.
[1]: https://astro.build/
SimpleUI helps address the endpoint issue by autogenerating routes for HTMX. It's like a simulation of the frontend running on the backend.
This guy lives in extremes! His option 1 is pure HTML the only other option 2 is React! But it seems he never heard about VanillaJS to drive a button click.
i tried it, its great if you want a jquery replacement, but if you are AT ALL used to react svelte etc you are going to be SORELY disappointed at how much ui manipulation and state management coordination you are going to need to reinvent from scratch. not worth it
What are some large websites using HTMX? I'd like to check them out.
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.
This is a retarded advice. Author clearly never tried to develop any serious web development.
> the build time is over 30 seconds!
that's silly. 30 seconds building time is nothing compare to the accumulated time you wait for micro changes to your frontend.
for typical web development using react/vue/svelte you have hot code reloading, which can reload the current website < 1 seconds after you hit [Save] on your favorite editor.
for htmx to update, you have to wait for your whole server to reload (which can be way slower even you use interpreted languages like ruby or python, due to complexity of the framework you use).
not to mention it does not keep any state of the current website, make debugging way more troublesome compare to a js mature framework.
only people who never have to improve their website incrementally think htmx is a viable option. or insane people.
obviously, for some small websites with minimal interactions or no need to change the content very often, then htmx can be good, but for that case, vanilla js also works, and they do not need 14kb of excess baggage.
No. Why the hell would I use Angular 1.x style directives in 2026? For the simple contact form and todo apps, why would I even use client side scripting? Go away.
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.
Are there any server-side frameworks that look like HTMX in the browser but allow writing functional-style code for managing all that HTML mutating itself?
I would recommend https://data-star.dev instead.
> 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 would say please just try Web Components.
They are standard, they work, they're great.
I don't get why people don't just use vue... with no build step, just including it.
Latest iOS Safari: the viewport jumps around on all those demos. Really hurts your case.
Mitrhil.js is 8.8 kB gzipped.
And you can just return JSON from your API.
And you can add JSX later if you want.
Has anyone tried using HTMX + some realtime query layer like Convex?
> The whole library is ~14kb gzipped
That'll be item #848 in my 847 line package.json.
Do not use HTMX for anything other than very simple CRUD apps. The vast majority of the time you'll be wishing you had client side two way data binding and state management. If you want "simple and not React", just use Alpine.js. It has way better ergonomics and features than HTMX and can do essentially everything HTMX can do.
> If you hate it, you've lost a weekend. But you won't hate it. You'll wonder why you ever thought web development had to be so fucking complicated.
This part is said really well, and applies to anything. "It's just a single weekend" is a cure to the whole "wasting time" argument/excuse that I guess a decent amount of people have - at least I know I do.
Really well written article, having both when to use and when not to use, is a nicely balanced view.
Just use the CHAMP stack. Like it's 2005 again.
CSS, HTML, Apache, MySQL and PHP.
There is inherent risk of such low level frameworks over React, that is they allow you to easily blow your foot off, by injecting raw unsanitized HTML back for dynamic execution. A thing that would not work in React apps by default. Even on those demos, you can XSS yourself with the simplest payload, confirming my point.
htmx led to spaghetti code for me. react is too much to learn. using vuejs these days.
What you need is more f-bombs in your article.
> 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?
Was hoping for a sandbox so I could actually try it!
No huge JS frameworks, no build steps, no state hell
> Honor obliges me to admit this is not literally true. bettermotherfuckingwebsite.com is a fucking pedagogical masterpiece and reshaped how I built my own site. But let's not spoil the bit...
> Inspired by (and in joyful dialogue with) motherfuckingwebsite.com, justfuckingusehtml.com, bettermotherfuckingwebsite.com, and justfuckingusereact.com. Extremism in defense of developer experience is no vice! This site made by me. Does this all sound a bit like shallow slop? Yup, please help make it better.
I agree with you, and wrote a similar one for Markdown that you might enjoy. Same overall naming scheme. (Note: open the comments before you judge the use of a Web Component for rendering purposes.)
To be honest, none of these new-ish frameworks are good because there’s not enough data to train LLMs. React/NextJS is great because I can 80% get there with LLMs.
You don't need React or HTMX; just put onclick= on your element and make your call with vanilla javascript. Use these frameworks if you want, as they're both neat, but frankly I think people forget that there are other options
14kb gzipped file? sorry no.
> Most teams don't fail because they picked the wrong framework. They fail because they picked too much framework. HTMX is a bet on simplicity, and simplicity tends to win over time.
I've built enough stuff in my time to know this is hyperbole at best and an outright lie at worst. I've never seen a team fail due to complexity. Team fails because the thing they built was wrong.
You should spend 99% of your time paranoid that the thing you're building is useful enough to justify its existence. Whatever tool you use along the way makes up the last 1%
This fucker didn't even bother showing us some real POST requests. And he actually wrote JavaScript to make those work.
Why would you mock it on the client-side if HTMX makes it so simple??
> "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.
No
But how to actually manage non trivial state? URLs get big pretty fast
Call me grumpy but 20 years ago we were making fun of smarty - a template engine made in a template engine - and now everything looks like a solution looking for a problem.