https://security.googleblog.com/2025/10/https-by-default.htm...
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.
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.
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.
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...
I'd love to hear more about that.
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 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.
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.
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.
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.
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.
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.
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.
Any big reason to use HTMX instead? Is Turbo not really discussed much because of it's association to RoR?
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.
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
https://justfuckingusereact.com
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.
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.
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 some kind of 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.
React is easy for small websites so why would I use a separate framework when I can use one framework for everything?
Objection. Your React is ultimately turning into HTML so you DO have to learn HTML + CSS. You just 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 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.
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?
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.
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.
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 article doesn't define any target audience in specific, so there you go.
Why not "just use HTML"?
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]
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?
<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.
> 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.
Your browser will still run js. See sibling thread.
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.
htmx is lower level and focuses in n generalizing the idea of hypermedia controls
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
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.
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.
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
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid...
No bundler required, no compilation step.
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.
When is this not the case?
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.
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.
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).
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, convert the JSON to HTML and then display it to the user
In my experience it added a lot of extra "mental overhead" that it was just annoying to me, whereas with 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.
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.
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'm saying their perspective doesn't shine through the crap and I'm sick of reading mediocre infodumps from LLMs.
And every months a few of those modules try to exfiltrate your credentials…
That'll be item #848 in my 847 line package.json.
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?
> 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.
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 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.
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.
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.
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.
Oh now now, even senior devs do this too :)
TeodorDyakov•1h ago