I am interested in learning about how something is being used and in what context, instead of what it has to offer. Can anyone tell me if they are using HTMX in a proven environment, like a user-facing environment?
I think adopting HTMX as a framework would be difficult to switch from a React, Vue, etc. environment. I think using it inside internal tooling or a hobby project will not be able to justify its merit.
I understand that it is just a simple framework and it addresses an industry-related issue, but migration is a lot of effort. Does HTMX really provide enough value to justify the engineering investment required?
I used htmx to build a now in production multi-step payment form that's currently in use by several hundred thousand people per month. It's been great, but not perfect and I would say a less well trodden path to get the edge cases right. I would absolutely say it's been a simpler overall solution for us as a small team than a full js client side framework would have been. Things that were hard to get right were setting up loading indicators, error display, keeping step/form state on browser history back/forward, tab sleep restoration after htmx navigation(especially tricky), and injection of third party form elements that had to be injected/remove and re-injected on back/forward between steps. I would be surprised if these sorts of edge cases weren't already handled by a popular js-frameworks but can't say for sure. The site load is very fast and we haven't even rolled out client side js validation on forms the server validation responds so fast. We are planning to use more htmx across other apps at present, so overall positive hypermedia for the win.
This means, that almost all uses of react and friends are wrong, a waste, or an unnecessary complication.
So, if you are serving HTML, then htmx.
When you reach for react? If you are making an app of the kind that you should have use a non-web thing (because is now necessary to bend with major complicated hacks HTML to make a clone of Photoshop).
(and in short amounts like creating complex widgets like maps, selects, etc).
---
I work for eCommerce, and there is terrible to use React: It is too easy to make "hacker-friendly" websites when using it: INSTEAD, you MUST validate, format, process, render, and display all on the server side.
For me, I retain all the logic on Rust, display HTML, and just put some extra interactivity with htmx, that because at the server-side is the same as without, means I CAN'T INTRODUCE A SECUIRITY BUG.
Curious what part of React you think makes it "hacker friendly". React can be done very simply, and I see no part of it that makes it any friendlier to "hackers" than HTMX.
We use htmx (mostly via our django-livecomponents) on our production website, for several public facing features. We've initially replaced numerous small things that were built with Alpine before, and once we've gained confidence we rewrote our whole messaging app from reason/react app.
Fun thing, customers find the new version (htmx/django-livecomponents) to be more responsive than the old version (react+REST). New version is less lines of code and easier to hack on die to fewer context switching.
This feels like the wrong way to look at things. It's not that it's "difficult" to switch from React/Vue to htmx - it's that it's easier to build with htmx in the first place. I wouldn't throw out completed code, but I'd seriously consider using it next time you start something new.
The general philosophy is that "React etc are great for some things, but they are being used way outside of their sweet spots". There will always be a gray area - and your existing habits and skills are also a factor but for some of us - the "SPA framework" approach always smelt fishy for typical web builds.
I'm using HTMX with Django for totem.org[0]. My over all experience is good.
I'd say the main thing I like is testing. With a JS framework I have to have tests spread over both JS and Python, with HTMX I can mostly just focus on Python tests and assume the HTMX is going to work correctly. There's a good, stable testing story for Django, so I know the tests I write won't have to be rewritten all the time when dependencies change. I just don't write many JS tests because stuff changes so fast.
The main downside I have with it though, is I just can't seem to remember how to use it. Every time I need HTMX I have to look at code I've written or go to the docs. There's just too many options with names that are confusing (hx-select, hx-swap, hx-swap-oob, hx-target?).
Aside from that, it's also a pretty large dependency. I'm also using Solidjs to mount web components (which is a pattern I love) and HTMX is a majority of the JS bundle. That was surprising to me. Maybe version 2 will be smaller?
> The main downside I have with it though, is I just can't seem to remember how to use it
I've noticed the more I use HTMX, the more I tend to end up needing to use the JS API too.
For example, if I have an HTML table with inline editing, and I need there to be validation on what people are entering. So, I have HTMX firing when people save their changes via a button, then I need to use the JS API for conditional logic e.g., if valid, then update table. If invalid, then display some kind of message or whatever.
HTMX has been working great for my needs, but the more I tend to get into the weeds of the JS API, I cannot help but sometimes question whether I am truly gaining that much more over using plain AJAX requests. However, HTMX is definitely more concise, so that's a nice benefit I suppose over a unmaintainable slew of AJAX requests.
> The main downside I have with it though, is I just can't seem to remember how to use it. Every time I need HTMX I have to look at code I've written or go to the docs. There's just too many options with names that are confusing (hx-swap, hx-swap-oob, hx-target?).
Perhaps this could be smoothed over with snippets or an autocomplete extension for whichever text editor is being used?
It depends on your options for managing state. If you can build a largely stateless UI, that can update from the server via a form submission or query parameters, then it’s a big win, both in terms of your code complexity and the complexity of the team you need to build it. You can still have lots of widgets on your page and even fancy CSS transitions to make it feel like an SPA if you really want. But if you’re making something very highly interactive or canvas based, with complex stateful UI components and gestures, then you probably have nothing to gain.
Anywhere I could conceivably get away with HTMX over React I would (and tbh I’d launch with no JavaScript at all before that). But if you’ve got a massive React codebase then you’re already in quite deep, both codebase and team structure.
All that said, some really high level apps are moving to WASM anyway, so I don’t know that an investment in React is safe for the long term.
The problem was that on the whole people didn't use jQuery to "load html snippets" and the architecture of jQuery tended to push people towards client-side spaghetti.
htmx encourages you to put most of the logic on the server and to keep the client lean and clean.
Yes, it's an implementation of the radical idea that we should deliver HTML (rather than a giant blob of JS) to clients purpose-built for rendering HTML.
But without jquery, everything defined in html attributes, and hence the server responses can further define behaviour in their html attributes. Declarative, not procedural, if you want.
I’ve been using HTMX on a greenfield project (not reimplementing something) and I’ve found it easy to work with and effective. Nothing magical, but simpler. Less effort, not more.
After being reminded of the importance of supporting low-spec clients[1] I’ve been testing without the HTMX library loading as well, and mostly that works like it should. I say mostly because I didn’t get the markup right everywhere yet.
I can see why some wouldn’t like it. But, it’s not a good/bad or works/doesn’t thing - it’s just different.
I help maintain a user-facing ASP.NET project running .NET Framework 4.5 that uses jQuery 1.0 for most of the UI. We launched our first new feature using HTMX back in November and it worked out pretty well for us and we plan to continue using it moving forward.
I also work on a React site and I wouldn't want to move away from it unless someone dared to utter the word rewrite.
The premise of migrating away from an SPA framework might make it seem weird, but I don't think that's the common adoption path.
There are a lot of server side templated web facing applications out there, and htmx provides a simple and gradual UX improvement with very litte investment.
It depends on what you deem "internal tooling" but a lot of b2b software isn't built to be flashy.
One benefit I found to it is that it allows developers to keep the business logic entirely on the backed side, without having to duplicate any effort on the frontend side.
I don't know if HTMX is an alternative to React/Vue/etc, it always struck me as an alternative to a purely HTML site, which I think 95% of web apps should be. I don't know what we get from avoiding full page loads that we don't then lose when we make sites janky and taking ages to load.
Well there has been this push forever to eliminate desktop apps in favor of just web apps. Now, imagine we do this crazy thing that most businesses are convinced they need to do and we do what you’re saying, which is make all web apps do page reloads. All of sudden (maybe not so suddenly) computing in 2026 is much more frustrating than it was in 1996 (86?).
For now I’ve decided to sit on React/Nextjs and actually focus on solving problems rather than playing the framework/UI library game that leads me nowhere.
So, I absolutely love htmx, and this new version offers some incremental improvements that make things even better (unless you were using WebSockets or server-sent events, I guess, but the plug-in model doesn't look too bad?).
Unlike all-or-nothing approaches like React, htmx allows you to add just the right amount of partial updates to your web app, using just the technologies that were already there to begin with. I realize that this approach doesn't appeal to everyone, but being able to map simple requests to simple responses was an absolute life-saver for my projects many times over.
I'm just glad I was able to submit my patch before 2.0 released: "Add config option to ignore nested oob-swaps instead of processing them (#1235)"
Setting this config makes it easier to use 'template fragments' with oob-swaps, since you can set the hx-swap-oob=true attribute on the element and reuse it to render a whole page or just a fragment of the template. Very nice to use with Go template blocks for example.
There's a lot to like about htmx, but one thing that does not sit well with me is its opinionated design decision that it will only render content if its sent with a 200 OK (tech TL;DR: shouldSwap defaults to false for non-200 response codes).
Most sane services will only return a 200 OK if, well, things went OK. Most sensibly designed services will return 400 range if an error has occurred that has been handled gracefully.
I am aware that you can kludge a hack in the form of a JS snippet to force htmx to render content on !=200, but it shouldn't be that way IMHO.
> Most sane services will only return a 200 OK if, well, things went OK. Most sensibly designed services will return 400 range if an error has occurred that has been handled gracefully.
Yes, but you are not designing your MVC controller as a REST service, and are not trying HTMX to your REST API directly. This makes sense if you think of it from this perspective, like the classic MVC view-rendering controller behind your HTMX page.
All response codes should really be able to contain content that doesn't look terrible. A 404 can be a nicely formatted "not found" page that's consistently styled and looks like the rest of the app, for example.
Yeah, it caught me by surprise first time I used htmx. I spent forever trying to troubleshoot why it wouldn't render the error message, then I discovered it was the old "feature not a bug".
Does general usage of HTMX require `unsafe-eval` in your Content Security Policy (CSP) to allow JavaScript eval? Or there's workarounds that still keep things simple?
> Some htmx applications make use of inline scripting—the hx-on attribute is a generalized attribute listener that can evaluate arbitrary scripts (although it can be disabled if you don’t need it). Sometimes inline scripts are appropriate to preserve locality of behavior on a application that is sufficiently secured against XSS, sometimes inline scripts aren’t necessary and you can adopt a stricter CSP. It all depends on your application’s security profile—it’s on to you to be aware of the options available to you and able to perform that analysis.
Is hx-on required often? How clunky does it get to avoid hx-on everywhere?
How much of a performance gain does htmx grant compared to other front-end frameworks? A talk from 2022 implies a significant benefit relative to React but in front-end development years that's an era ago: https://docs.google.com/presentation/d/1jW7vTiHFzA71m2EoCywj...
I'm not someone who usually gets excited by new major releases of frameworks/libraries but this one feels different. I got my start with CRUD PHP websites with jQuery. I've been using HTMX for the last year and it fills me with nostalgia while also allowing me to move faster when building UIs.
Readit News
I think adopting HTMX as a framework would be difficult to switch from a React, Vue, etc. environment. I think using it inside internal tooling or a hobby project will not be able to justify its merit.
I understand that it is just a simple framework and it addresses an industry-related issue, but migration is a lot of effort. Does HTMX really provide enough value to justify the engineering investment required?
This means, that almost all uses of react and friends are wrong, a waste, or an unnecessary complication.
So, if you are serving HTML, then htmx.
When you reach for react? If you are making an app of the kind that you should have use a non-web thing (because is now necessary to bend with major complicated hacks HTML to make a clone of Photoshop).
(and in short amounts like creating complex widgets like maps, selects, etc).
---
I work for eCommerce, and there is terrible to use React: It is too easy to make "hacker-friendly" websites when using it: INSTEAD, you MUST validate, format, process, render, and display all on the server side.
For me, I retain all the logic on Rust, display HTML, and just put some extra interactivity with htmx, that because at the server-side is the same as without, means I CAN'T INTRODUCE A SECUIRITY BUG.
Seems that HTMX requires unsafe-eval?
https://github.com/bigskysoftware/htmx/issues/2260
Fun thing, customers find the new version (htmx/django-livecomponents) to be more responsive than the old version (react+REST). New version is less lines of code and easier to hack on die to fewer context switching.
Give htmx a try, it's worth a shot!
Sounds cool. This one?
https://github.com/om-proptech/livecomponents
The general philosophy is that "React etc are great for some things, but they are being used way outside of their sweet spots". There will always be a gray area - and your existing habits and skills are also a factor but for some of us - the "SPA framework" approach always smelt fishy for typical web builds.
I'd say the main thing I like is testing. With a JS framework I have to have tests spread over both JS and Python, with HTMX I can mostly just focus on Python tests and assume the HTMX is going to work correctly. There's a good, stable testing story for Django, so I know the tests I write won't have to be rewritten all the time when dependencies change. I just don't write many JS tests because stuff changes so fast.
The main downside I have with it though, is I just can't seem to remember how to use it. Every time I need HTMX I have to look at code I've written or go to the docs. There's just too many options with names that are confusing (hx-select, hx-swap, hx-swap-oob, hx-target?).
Aside from that, it's also a pretty large dependency. I'm also using Solidjs to mount web components (which is a pattern I love) and HTMX is a majority of the JS bundle. That was surprising to me. Maybe version 2 will be smaller?
[0]: https://github.com/totem-technologies/totem-server
I've noticed the more I use HTMX, the more I tend to end up needing to use the JS API too.
For example, if I have an HTML table with inline editing, and I need there to be validation on what people are entering. So, I have HTMX firing when people save their changes via a button, then I need to use the JS API for conditional logic e.g., if valid, then update table. If invalid, then display some kind of message or whatever.
HTMX has been working great for my needs, but the more I tend to get into the weeds of the JS API, I cannot help but sometimes question whether I am truly gaining that much more over using plain AJAX requests. However, HTMX is definitely more concise, so that's a nice benefit I suppose over a unmaintainable slew of AJAX requests.
Perhaps this could be smoothed over with snippets or an autocomplete extension for whichever text editor is being used?
Anywhere I could conceivably get away with HTMX over React I would (and tbh I’d launch with no JavaScript at all before that). But if you’ve got a massive React codebase then you’re already in quite deep, both codebase and team structure.
All that said, some really high level apps are moving to WASM anyway, so I don’t know that an investment in React is safe for the long term.
htmx encourages you to put most of the logic on the server and to keep the client lean and clean.
See also https://hotwired.dev/
After being reminded of the importance of supporting low-spec clients[1] I’ve been testing without the HTMX library loading as well, and mostly that works like it should. I say mostly because I didn’t get the markup right everywhere yet.
I can see why some wouldn’t like it. But, it’s not a good/bad or works/doesn’t thing - it’s just different.
[1] https://danluu.com/slow-device/
Edit: typo, HTML -> HTMX
I also work on a React site and I wouldn't want to move away from it unless someone dared to utter the word rewrite.
There are a lot of server side templated web facing applications out there, and htmx provides a simple and gradual UX improvement with very litte investment.
It depends on what you deem "internal tooling" but a lot of b2b software isn't built to be flashy.
—> https://zakuchess.com/
One benefit I found to it is that it allows developers to keep the business logic entirely on the backed side, without having to duplicate any effort on the frontend side.
I totally get your sentiment.
Disclosure: I built it (without HTMX).
Unlike all-or-nothing approaches like React, htmx allows you to add just the right amount of partial updates to your web app, using just the technologies that were already there to begin with. I realize that this approach doesn't appeal to everyone, but being able to map simple requests to simple responses was an absolute life-saver for my projects many times over.
Migrating to a truly-truly minimalist approach (see: https://www.stefanjudis.com/notes/htmz-a-176-bytes-htmx-alte...) is still on my to-do list, but for now, I'm quite happy with the htmx status quo.
Setting this config makes it easier to use 'template fragments' with oob-swaps, since you can set the hx-swap-oob=true attribute on the element and reuse it to render a whole page or just a fragment of the template. Very nice to use with Go template blocks for example.
https://htmx.org/essays/template-fragments/
Most sane services will only return a 200 OK if, well, things went OK. Most sensibly designed services will return 400 range if an error has occurred that has been handled gracefully.
I am aware that you can kludge a hack in the form of a JS snippet to force htmx to render content on !=200, but it shouldn't be that way IMHO.
Yes, but you are not designing your MVC controller as a REST service, and are not trying HTMX to your REST API directly. This makes sense if you think of it from this perspective, like the classic MVC view-rendering controller behind your HTMX page.
https://v2-0v2-0.htmx.org/docs/#configuring-response-handlin...
A few people on the core team agree that htmx should always swap. It was perhaps a bad decision on my part, but it is fixable w/ a bit of config.
https://htmx.org/extensions/response-targets
I don’t know what kludge you’re referring to, it requires you to add basically two attributes to your HTML, it’s really no hardship at all.
And why should I need to load an extension to handle a 400-series ? That's just nuts.
The kludge is loading the following JS snippet on your page:
Yeah, it caught me by surprise first time I used htmx. I spent forever trying to troubleshoot why it wouldn't render the error message, then I discovered it was the old "feature not a bug".
https://htmx.org/essays/web-security-basics-with-htmx/#bonus...
> Some htmx applications make use of inline scripting—the hx-on attribute is a generalized attribute listener that can evaluate arbitrary scripts (although it can be disabled if you don’t need it). Sometimes inline scripts are appropriate to preserve locality of behavior on a application that is sufficiently secured against XSS, sometimes inline scripts aren’t necessary and you can adopt a stricter CSP. It all depends on your application’s security profile—it’s on to you to be aware of the options available to you and able to perform that analysis.
Is hx-on required often? How clunky does it get to avoid hx-on everywhere?