I’ve just completed a port from HTMX to Hotwire (Stimulus, Turbo). HTMX is a great idea, but in my experience it’s a poor execution.
It’s really quite buggy, in my experience it plays poorly with fundamental web and browser features (relative links are broken in at least 2 ways, I fixed a third way). One of the events just stopped working at all in the most recent release. The docs are lacking. And where it promises to let you write less JS, if you ever do need to write some JS you’re on your own in structuring that, and you’ll be fighting against HTMX (who gets to update the DOM, maintaining event handlers, etc).
As a (brief) contributor to HTMX, I also feel like these issues were all inevitable. It’s a single 5k line file with 190 top level functions in it meaning it’s pretty impenetrable to get up to speed on. When proposing a bug fix the maintainers weren’t sure if it would have other consequences. Tests didn’t cover the functionality. I’ve been mostly a backend engineer in my career, and I empathise with not wanting the complexity of a modern frontend, but that doesn’t mean we can’t have some basic organisation of the code to make it approachable and more obvious whether changes will work or not.
After porting to Turbo and Stimulus I have a more reliable code base, I have significantly less JavaScript, and I have a JS code base that much easier to reason about. I really wanted to like HTMX but the execution is not there. A focus on stability is a great fit for the project, but it’s most certainly not there yet and has quite a way to go in my experience.
I would love to know in what other two ways relative links are broken, and which event stopped working, so we can get those fixed. With respect to the fix you PRed (thank you, by the way), we did get that merged very quickly, and would love to do the same for whatever is broken here, even (especially) if you are no longer interested in doing the fix yourself. [0]
As for the DX of making changes to htmx: absolutely true! The single file is a DX we've chosen, and it has both costs and benefits, which we've written about in "Why htmx doesn't have a build step". [1]
Hi Alex, thanks for the reply and for your work on HTMX. I love the idea and think there's a strong need for something like HTMX, and if HTMX can live up to those promises then great. For me it doesn't, currently, but it sounds like it does for others.
The relative link bugs are [0] and [1], and I fixed [2]. My fix was merged quickly, but the other two bugs of what appears to be similar significance, have been open for well over a year each. My issue however is less about these specific issues, and more the general lack of support for hypermedia, which speaks to a general state of HTMX not living up to its promises.
As for the DX, I think not having a build step, and code structure, are somewhat orthogonal. I agree with much of that essay, but most of it is about issues with complex build systems and the use of Typescript. It's not about having 190 top-level functions, which, with all due respect, I think indicates a lack of architecture. Again, the issue is less about the specifics, and more about the fact that HTMX is not living up to its promise of simplicity because of how impenetrable the codebase is in this regard.
As mentioned, so far I have found Stimulus and Turbo to be better implementations of what HTMX appears to promise to be. More activity in this space from anyone and everyone is great here though!
It was `htmx:load`. On 1.x this fired on first page load, which I used to do a bunch of setup of the other little bits of JS I needed, and which would cause that JS to re-setup whenever the page changed.
On 2.x this never fired as far as I could tell. Maybe I got something else wrong, but only downgrading to 1.x seemed to fix it immediately, I didn't investigate further.
I did wonder if there were breaking changes in 2.x, but as far as I could tell from the release notes and documentation there were not.
I have had a great experience with Astro and HTMX. When the first time I tried, I didn't think much about HTMX and thought it was an Astro thing, about a year or over. But this time, I had a great experience and I understand the power of htmx and native web only JS, no framework when building simple sites is much refreshing.
I wanted to use Hotwire but it felt like it was made for Rails as backend? This probably needs to be fixed because if the DX is as good as you say then its disservice to be tied to Rails.
Which leads to the appeal of HTMX. It promises no other dependence. It just does exactly what it advertised. I'm not sure whether your issues were due to implementation or specific known bugs in HTMX not covered.
I am curious to know more about Hotwire, I'm just worried about state management and this is greatly overlooked when it comes to adding application logic beyond just hydration of specific components on page.
So far I have not seen anything that competes with Sveltekit.
Hotwire is designed for good integration with Rails, but Rails is not required. In a similar way, HTMX works better with various server-side libraries, but none are required.
Personally I'm using Hotwire (was using HTMX) with a Swift backend with no issues.
Just a note to other readers, Turbo doesn't require Stimulus... I use Turbo mainly with AlpineJS and it works just as well since Turbo is the just tag driven side of things.
I do. I've always felt that I'm doing something wrong when I do this, but I much prefer not having to switch files all the time and navigate folders etc. looking for things. With everything in one file, I can just use regular within-file search (and M-x occur in emacs which is a bit like clickable (and editable) grep). If I need "focus", I just use narrowing in Emacs (shows only the highlighted part of the buffer, with handy shortcuts for narrowing to current function/class). If I need to see something side-by-side, just split or clone the buffer. I loathe working on those java etc. projects where you have a zillion classes each in their own file, many with maybe a handful of members each; whenever I switch files I feel like I'm losing context.
I prefer this style. I primarily use Emacs as someone else mentioned. I feel like it's sort of similar to editor tabs vs buffers. Like, once you have a good way of switching between buffers, separate editor tabs seem like a superfluous UI element. In a similar way, if you have powerful ways of navigating to the function definition you want, then everything being in the same file doesn't seem to matter.
Also, having all the code in a single file helps expression exposition of the code. You can sort of captivate the reader of your code, and present the code in the order of your choosing.
If you look at the end-user API documentation[1] it's pretty good.
But the htmx.js file itself seems to struggle from a certain type of internal naming scheme that will take a while to get up to speed with and doesn't really lend itself to being easy to context switch in & out of it, where you might simply forget that things exist and end up re-writing or inlining these fragments.
This naturally stems from a very organic development process, where something starts out as a quick prototype, then the functions get too big so you split fragments out into things like `shouldProcessHxOn` and `processHXOnRoot` which absolutely make sense at the time where you're avoiding duplication, and trying to turn it into something 'more proper' with 'better abstractions' would actually cause the code to balloon in size and make it much bigger and much more like object spaghetti.
On the whole though, a large amount of the file is type documentation, e.g. `/* @param {Node} start */` which is more a failing of JavaScript itself than anything else, and honestly a 5k self-contained file with good public documentation of what's user-facing vs internal is pretty easy to grok if it's something you work with frequently.
If you were to rewrite this in a saner language like Python with a more functional style, you could probably condense it down to 1000 lines or less.
Full stack polyglot dev here, the relentless pressure to use Sveltekit that has utterly destroyed plain Svelte docs, IMO, coupled with the koolaid kult around v5 is why i finally ditched svelte.
I have backend solutions and existing databases and existing backends. I would never consider a Js backend in a production app to begin with, despite the benefits an isomorphic approach offers.
I dislike when physical actual boundaries in code execution contexts are obfuscated, for one...
But not everyone is building SPAs, and my dev server is my actual backend, thanks
> ...you can use as much or as little of it as you like... Stability as a Feature... No New Features as a Feature...
This is the way.
Having lived the alternative, I won't consider building anything significant on top of an abstraction that doesn't credibly promise these.
When the abstraction you've built on changes or fails, the thing you built breaks. When you choose an unstable abstraction, you're creating future bugs you'll have to spend future time on to resolve (and if it wraps the lower layer rather than sitting beside it, you have fewer options to fix them).
These aren't concerns for things that will be short-lived, or are small enough to replace if needed. But I've seen plenty of small and temporary things turn into large and permanent things when they end up being useful.
But the node ecosystem includes essentially everything that touches on javascript, both the bad and the good.
I don't think there are very many ecosystems that are guaranteed to have only good stuff. Regardless of ecosystem, the developer has to examine what is available and make wise choices.
>But I've seen plenty of small and temporary things turn into large and permanent things when they end up being useful.
My experience is that probably more than 9/10 temp projects end up forever projects. My goal is never to work anywhere again that insists on just get it done quick and dirty "its temporary" ever again.
I don't remember where I stole it from but at work any time we're discussing something temporary I like to drop in a "remember there's nothing more permanent than a temporary fix" and it usually gives us at least a few more minutes of considering things carefully before pulling the trigger. Makes me feel better anyway.
I've created a Django application using HTMX. Usually I'd jump to React or Vue. It was a great exercise and I can see where HTMX would be a great fit.
1. If you consider yourself a "backend developer" only and want to write the minimum amount of JS/TS.
2. If your application is simple. Yes you can do more complicated interactivity with oob swaps, but you end up with more complexity than you chose HTMX for.
For my next projects, I will still use Django but with React/Vue for pieces that need interactivity. As an example in my HTMX app, I wanted to add a profile image uploader. Lots of great frontend libraries exist to resize / modify your image before even uploading it to your server.
Finally, HTMX is just not testable the same way modern frontend libraries are. I've managed to write some decent tests using beautifulsoup, but it's night and day compared to vitest or jest.
This was my exact experience - loved it as a backend developer wanting to build simple frontends with minimal JavaScript (and I still recommend it for many use cases) but when I then tried HTMX to build a more complex application I found that the complexity that would normally be handled by a JavaScript framework ultimately grew and shifted to the HTML and, surprisingly, the backend as well.
For example, error handling in complex forms. When you have React handling errors you simply return a 400 JSON response with fields and reasons, or some other error message, and React decides what to do depending on the context, which it knows. When this responsibility is moved to the backend you now need to track the request location, state etc. and find the right fragment, which very quickly turned the code into a mess.
I think the choice of backend is also important. I suspect that Java (Spring Boot) made using HTMX much less pleasant than it would have been with something else, especially when it comes to templates and routing. Using Java for HTML templates (Thymeleaf or any of the other popular libraries) is something I will never do again.
Edit:
The analogy with jQuery is interesting. I feel the same way about HTMX now as I did about jQuery ten years ago. I used to plug jQuery into every project even if it was just to select elements or whatever, but whenever I used jQuery entirely over the frameworks that were popular at the time (Ember, Angular) I ended up with way messier code.
> When this responsibility is moved to the backend you now need to track the request location, state etc. and find the right fragment,
Maybe not? I'm just returning a 422 JSON response with fields and reasons and I have a tiny bit of JavaScript in the frontend that just plugs them in to the form with the built-in Constraint Validation API.
> I suspect that Java (Spring Boot) made using HTMX much less pleasant than it would have been with something else, especially when it comes to templates and routing.
IMHO one of the biggest advantages of using HTMX is not having to maintain three layers of test suites (backend, frontend, end-to-end). You just need to test that your endpoints return the right HTML piece. You don't need unit testing the frontend since you don't have that much logic there. Just rely on end-to-end tests as a complementary tool to check small pieces of logic on the HTMX code.
I’m not sure I’d agree. The HX attributes encode a lot of functionality and you want to check that they do the right thing together. You can test you get the right attributes in a response, but that’s only a proxy for the application doing the right thing, so you most likely still need the end to end tests.
The problem is that end to end tests are the hardest kind to write. At least if you have a frontend code base you can have some tests there and get some confidence about things working at a lower level.
> You just need to test that your endpoints return the right HTML piece. You don't need unit testing the frontend since you don't have that much logic there.
Only using the standard Django test client? I don't find this myself when I've had to work with HTMX code e.g. if you're using HTMX for your sign up form, it can be completely broken on the happy path and on form errors if the HTMX attributes are wrong, and the standard Django test client won't let you know, so you lose a lot of confidence when making refactors/changes.
That honestly sounds like a downside. Having to verify HTML as an output (in comparison to e.g. JSON) is brittle since it will often change just for presentation reasons. Having a clear and somewhat stable API (which is a boon for testing) is IMHO a strong reason for the SPA model.
> 1. If you consider yourself a "backend developer" only and want to write the minimum amount of JS/TS.
This is a great point and should be underscored more. I think generally the HTMX vs React/Vue/Svelte argument gets undercut when people don't express their innate bias on which part of the stack they want to give more control to. HTMX is great if you're pro-expanding the server; JS Frameworks if you're trying to expand it from the application layer.
With the BeautifulSoup tests I can run 1000s of tests in seconds. Cypress/Playwright are wonderful for e2e tests, but not comparable to simple unit tests you'd have in React/Vue. I find that the BeautifulSoup tests are a decent middle ground.
They're both fantastic expansions of what server-side rendering can do. They can't really do work as nice as what React can, but you can get perhaps 85% of React for 5-10% of the development time. And a big increase in usability of your app.
As I dont do frontend work, how do you "test" anything without an insane amount of browsers/hardware realistically ?
If I was to write tests, it'd be basically http get/post/put/delete requests and measuring the responses are what I expect.. how can HTMX be any different here ?
How do you "test" a button works without a browser engine ? Every browser engine ?
but they're about as reliable as you can expect: it's difficult to keep up the pace with the big three (or two) on standards compliance, and they usually don't even try.
So the only reliable solution is a headless Chromium, Firefox, and/or WebKit-based noname browser like the sibling says.
Anyone got a good feel for the htmx accessibility story at the moment?
I'm interested in using it more, but I want to be 100% confident that I understand how to get htmx sites to work well with screen readers. I worry about things like fetching new data into a page not altering the screen reader user in the same way as refreshing a page completely would.
I'm not interested in whether or not htmx uses the correct ARIA attributes - I want to be confident that those ARIA attributes (or similar) do the right thing.
My ideal is still to use JavaScript libraries where the documentation not only describes how they work with screen readers, but is accompanied by video evidence showing the experience a screen reader user gets for different problems solved by that library.
This is one reason I created https://alpine-ajax.js.org.
A few years ago there were a lot of examples in the HTMX documentation that discouraged accessibility and progressive enhancement. Stuff like like clickable <div>s, ignored keyboard focus, lack of screen reader announcements.
There’s been some improvement latel, but I still think the library has a lot of foot guns for new web developers.
Handling ARIA attributes is out of scope for HTMX. It is your responsibility to include ARIA attributes on the HTML you return and swap/transclude.
As for handling dynamic content for screen readers, focus management is already a thing, and is in the scope of browser standards and the HTML your backend returns. As before, it's your responsibility to manage this. HTMX will neither help you nor get in your way.
HTMX merely extends hypertext functionality to its (mostly) natural conclusion. It is not a component library, or a framework for building components, or a site building framework, or...
You can use other tools to enhance and audit accessibility, but their use is orthogonal to HTMX. I think web developers in general are very used to frameworks abstracting a ton of complexity, but HTMX is not a framework so much as a standardized set of tools for specific low level problems, it is not a one stop shop.
In that case it would be great if the HTMX documentation included worked examples and guidance for how to do this.
Leaving accessibility up to the end developer feels like a genuine missed opportunity for me here. One of the great things about NOT using a JavaScript library is that you can rely on the browser's default accessibility features for forms and links. Those benefits are the thing I care most about when considering HTMX or jQuery or React or Vue or similar.
tl;dr htmx is better than a lot of alternatives, but Simon is right, it can improve this story and it has a responsibility to do so.
As a framing device: any interactivity that is not described with HTML is interactivity that someone is responsible for making accessible (which you correctly pointed out). Unlike JS frameworks, htmx encourages the developer to solve problems with HTML first, so the inaccessible surface area that the developer has to worry about is going to be much smaller on htmx-based applications than it is with JS-based applications. That's a pretty strict win from where a lot of the industry is right now.
That having been said, I agree with you (and disagree with a lot of our defenders in the comments) that thinking about this is in-scope for htmx. In fact, I'm a firm believer that libraries are exactly where responsibility for implementing ARIA attributes live. The average web developer should not have to think about this at all—they should be able to use declarative abstractions and trust that they are annotated correctly for screen readers. This is the only system that scales, and htmx should adhere to it as much as possible.
Ideally, htmx would just add the polite notification attribute to the elements it processes, and give an easy way to customize that. I think it's basically possible to do this in a backwards-compatible way (first as an extension) that aligns with the maintenance strategy outlined in this essay. And I do think we can improve the documentation as well.
I would argue that frontend libraries like htmx and React are not the place to build in ARIA attributes patterns/behaviours. In fact, none of the Big Ones do anything specifically w.r.t. announcing changes. See https://news.ycombinator.com/item?id=42625070
What would be the appropriate place, imho, would be component frameworks that are built on top of htmx. FastHTML is an example; they already have htmx integration and they talk about server-side components. If we look at a popular one in React, this is what they do: https://blog.logrocket.com/aria-live-regions-for-javascript-...
Thinking about it in terms of dream-html[1], it might look like:
let announce msg =
p [
class_ "announcement";
Hx.swap_oob "innerHTML:.announcement";
Aria.live `polite;
] [txt "%s" msg]
(* POST /purchase *)
let purchase request =
let thank_you_fragment = ... in
Dream_html.respond (
(* Join fragments together *)
null [
thank_you_fragment;
announce "Your purchase has been successful!";
]
)
I'm thrilled to hear you're thinking about this. I really like the philosophy of the project, very happy to hear that reducing accessibility friction is a value you care about too.
Yeah, any website that uses JavaScript to load page elements needs to solve this. My hope is that a library like HTMX can help reduce the friction in implementing the best possible patterns for doing so.
I understand screenreaders have a set of standards, aria tags etc - but are the next generation of AI screenreaders (I’m sure some already use AI?) going to replace the need for these tags, and just read a page as a human would?
I’m very grateful for how htmx by focussing on a very specific part of “interactive JavaScript on the page” was able to shift a whole bunch of similar JavaScript actions into an elegant abstraction that rested so neatly on all the existing work that had/has gone into developing html. And even for having the clarity to name it as such.
In a way it’s a bit of a lesson in managing complexity, rather than seek to be “the next JavaScript framework to replace all the others with its theory of the universe”, it instead carved off a smaller slice and said these Thich are related, we’re just for dealing with these thing, nothing more.
In one swoop a whole raft of manual developer programming workload was packed up with a new easier to understand abstraction.
Kudos to the team, I’m grateful for the considered way you’ve developed this tool for the rest of us.
how do you feel about its adoption in things like https://fastht.ml/ ? i was open to the idea at first esp with jeremy howard's endorsement, but once you start updating multiple things on a page at once i felt like i was fighting htmx rather than it helping me. components are a really neat paradigm and just bc react is currently in a complexity upswing doesnt mean we want to throw the baby out with bathwater
I am still trying to get HTMX adopted in a ~ 800 employee software development company. And while we do not yet have a project using HTMX in production, I like to use it a lot in thought experiments with mentees: Could you do it with HTMX / Fragments? If yes, how would you design it? Do we REALLY need an SPA?
I do think "use HTMX" is a tough sell for a 800 employee company, just because it doesn't really solve issues on it's own. (Imagining the pitch is "add HTMX to an existing project") Going all-in on hypermedia definitely means the service that serves your application needs to be more than just a JSON parrot. Templating HTML and sending the right chunks back is hard to do if those services aren't built around being hypermedia services.
I really like turbo-rails [0] (the ruby gem that Rails 7+ bundles in for turbo support, meaning helpers that make turbo frames/responses a native "thing" rails understands) because it's a complete solution. There's at least some obvious structure to build off of, and I'm not stuck trying to build up my own framework on the BE for my newly simpler FE.
django-htmx [1] also fits in this case too. I feel like any honest pitch of HTMX should involve some BE solution as well.
I dont intend it to be an all-in, but I do believe it could do the job in 50% or more cases just as well as any SPA framework. A lot we do is "just crudl" with some sprinkles on top.
A large chunk of our business comes from Spring Boot, so we are experimenting with JTE - looks decent so far (Thymeleaf feels just old nowadays).
My sell is pretty simple: You have regulations coming up in europe which will require you to keep applications up-to date and secure. Extending your SBOM by 1k NPM libraries is a huge cost. I want to get rid of that.
I tried to get HTMX adopted for a new project but the unanimous response was "what is this? why not React? everyone knows React. period" and most of my arguments for HTMX were ignored, because to most people, HTMX looked like some obscure, yet another JS framework created last week, with questionable future.
The reason is because all new technology is a staffing and training problem management needs to solve. Someone has to maintain your thing after its built and be ready when you leave the organization. If React can solve the issue in a similar timeframe and level of effort and it is easy to source React developers then obviously your proposal will be rejected because React is simply far easier to deal with from a training and staffing perspective for what you are trying to do. You need more merits to warrant the introduction of new languages and frameworks.
Very anti React person went for Svelte but the kind of modularity React offers, HTMX can't hope to match especially on larger projects.
Modern React is too simple. A component is just a pure function taking arguments and returning UI as JSX. The only other thing you need to know is few hooks.
Of course you get pushbacks. Is there any *real* advantage, technical or otherwise, at an organization level, of adopting this new model of creating web pages, other than your personal preferences? You are moving away from an established system with tools that everyone is familiar with, to a system that much fewer people use, with no clear performance/maintenance/management benefit (at least not demonstrated). Maybe you don't like writing JS/TS, but plenty of other people do, and they don't need to cater to your preferences.
People need to spend time learning this tool. They need to be proficient with it. Your new stack might need to still work with existing code at some point. That means training, overhead, ramp up and potential risk in a less established area. Why would people do that?
You should be thankful you didn't get warnings from your boss for messing around instead of actually pushing features out.
To be fair, it's not an unfair response. Being able to hire for a technology, and having a large community around the tech stack you use has tangible value.
HTMX might not be something that will vanish in a week, but it's also nowhere close to a mainstream framework.
the reality is that the only way to prove htmx is around for the long term is to stick around for the long term, and I hope this essay contributes towards that.
We'll see how this years JS rising stars shakes out.
I built an HTMX fragment framework for Django. It allows you to render a fragment, and automatically serves the fragment separately for live-updates. I'll open source it tonight and post back.
In my opinion, HTMX + custom elements does everything React does but better, and is a billion times cleaner.
People are commenting about "no new features as a feature", and I agree, but even better is this:
> People shouldn’t feel pressure to upgrade htmx over time unless there are specific bugs that they want fixed
Frickin A! Nice to see somebody pushing back against the trend of "if you haven't updated your software in the last five minutes you're on an unsupported configuration".
Why programmers like cooking: You peel the
carrot, you chop the carrot, you put the carrot
in the stew. You don't suddenly find out that
your peeler is several versions behind and
they dropped support for carrots in 4.3
A) New library versions are roughly as likely to introduce new bugs, as they are likely to fix old bugs. (If not, why are there still so many updates, you should be running out of bugs ...)
B) If you run into a bug, update that library, then look into fixing it and offering a PR with the fix. Easy-peasy.
Compared to: oh this is a bug in a library that's fixed in an update ... but then we need to update another library it depends on, but that requires an update to nodejs, but that requires us to update some other libraries, which introduce a new more serious regression, so we can't unless we re-write to remove that dependency ...
>In particular, we are trying to push the ideas of htmx into the HTML standard itself, via the Triptych project. In an ideal world, htmx functionality disappears into the web platform itself.
I have been calling for this for a very long time even during pjax era. I hope that is not only an ideal but a realistic pathway forward. Chrome / Blink or Safari / Webkit. If we could just get one of them to implement it as experimental feature. How could we push this forward?
JPEG XL and HTMX in HTML, along with some sort of basic rich text editor for everyday writing is what I want browser to be included by default.
Readit News
It’s really quite buggy, in my experience it plays poorly with fundamental web and browser features (relative links are broken in at least 2 ways, I fixed a third way). One of the events just stopped working at all in the most recent release. The docs are lacking. And where it promises to let you write less JS, if you ever do need to write some JS you’re on your own in structuring that, and you’ll be fighting against HTMX (who gets to update the DOM, maintaining event handlers, etc).
As a (brief) contributor to HTMX, I also feel like these issues were all inevitable. It’s a single 5k line file with 190 top level functions in it meaning it’s pretty impenetrable to get up to speed on. When proposing a bug fix the maintainers weren’t sure if it would have other consequences. Tests didn’t cover the functionality. I’ve been mostly a backend engineer in my career, and I empathise with not wanting the complexity of a modern frontend, but that doesn’t mean we can’t have some basic organisation of the code to make it approachable and more obvious whether changes will work or not.
After porting to Turbo and Stimulus I have a more reliable code base, I have significantly less JavaScript, and I have a JS code base that much easier to reason about. I really wanted to like HTMX but the execution is not there. A focus on stability is a great fit for the project, but it’s most certainly not there yet and has quite a way to go in my experience.
I would love to know in what other two ways relative links are broken, and which event stopped working, so we can get those fixed. With respect to the fix you PRed (thank you, by the way), we did get that merged very quickly, and would love to do the same for whatever is broken here, even (especially) if you are no longer interested in doing the fix yourself. [0]
As for the DX of making changes to htmx: absolutely true! The single file is a DX we've chosen, and it has both costs and benefits, which we've written about in "Why htmx doesn't have a build step". [1]
[0] https://github.com/bigskysoftware/htmx/pull/1960
[1] https://htmx.org/essays/no-build-step/
The relative link bugs are [0] and [1], and I fixed [2]. My fix was merged quickly, but the other two bugs of what appears to be similar significance, have been open for well over a year each. My issue however is less about these specific issues, and more the general lack of support for hypermedia, which speaks to a general state of HTMX not living up to its promises.
As for the DX, I think not having a build step, and code structure, are somewhat orthogonal. I agree with much of that essay, but most of it is about issues with complex build systems and the use of Typescript. It's not about having 190 top-level functions, which, with all due respect, I think indicates a lack of architecture. Again, the issue is less about the specifics, and more about the fact that HTMX is not living up to its promise of simplicity because of how impenetrable the codebase is in this regard.
As mentioned, so far I have found Stimulus and Turbo to be better implementations of what HTMX appears to promise to be. More activity in this space from anyone and everyone is great here though!
[0]: https://github.com/bigskysoftware/htmx/issues/1476 [1]: https://github.com/bigskysoftware/htmx/issues/1736 [2]: https://github.com/bigskysoftware/htmx/pull/1960
> and which event stopped working
It was `htmx:load`. On 1.x this fired on first page load, which I used to do a bunch of setup of the other little bits of JS I needed, and which would cause that JS to re-setup whenever the page changed.
On 2.x this never fired as far as I could tell. Maybe I got something else wrong, but only downgrading to 1.x seemed to fix it immediately, I didn't investigate further.
I did wonder if there were breaking changes in 2.x, but as far as I could tell from the release notes and documentation there were not.
* Note to non-JS hackers: JS module symbol scope is per-source file.
HTMX had no issue, tho
Which leads to the appeal of HTMX. It promises no other dependence. It just does exactly what it advertised. I'm not sure whether your issues were due to implementation or specific known bugs in HTMX not covered.
I am curious to know more about Hotwire, I'm just worried about state management and this is greatly overlooked when it comes to adding application logic beyond just hydration of specific components on page.
So far I have not seen anything that competes with Sveltekit.
Personally I'm using Hotwire (was using HTMX) with a Swift backend with no issues.
Deleted Comment
That's interesting. Do some people prefer this style? If yes, how come?
Also, having all the code in a single file helps expression exposition of the code. You can sort of captivate the reader of your code, and present the code in the order of your choosing.
But the htmx.js file itself seems to struggle from a certain type of internal naming scheme that will take a while to get up to speed with and doesn't really lend itself to being easy to context switch in & out of it, where you might simply forget that things exist and end up re-writing or inlining these fragments.
This naturally stems from a very organic development process, where something starts out as a quick prototype, then the functions get too big so you split fragments out into things like `shouldProcessHxOn` and `processHXOnRoot` which absolutely make sense at the time where you're avoiding duplication, and trying to turn it into something 'more proper' with 'better abstractions' would actually cause the code to balloon in size and make it much bigger and much more like object spaghetti.
On the whole though, a large amount of the file is type documentation, e.g. `/* @param {Node} start */` which is more a failing of JavaScript itself than anything else, and honestly a 5k self-contained file with good public documentation of what's user-facing vs internal is pretty easy to grok if it's something you work with frequently.
If you were to rewrite this in a saner language like Python with a more functional style, you could probably condense it down to 1000 lines or less.
[1]: https://htmx.org/api/
I have backend solutions and existing databases and existing backends. I would never consider a Js backend in a production app to begin with, despite the benefits an isomorphic approach offers. I dislike when physical actual boundaries in code execution contexts are obfuscated, for one...
But not everyone is building SPAs, and my dev server is my actual backend, thanks
This is the way.
Having lived the alternative, I won't consider building anything significant on top of an abstraction that doesn't credibly promise these.
When the abstraction you've built on changes or fails, the thing you built breaks. When you choose an unstable abstraction, you're creating future bugs you'll have to spend future time on to resolve (and if it wraps the lower layer rather than sitting beside it, you have fewer options to fix them).
These aren't concerns for things that will be short-lived, or are small enough to replace if needed. But I've seen plenty of small and temporary things turn into large and permanent things when they end up being useful.
Given my experience with node ecosystem, react, and nextjs, I am inclined to agree.
But the node ecosystem includes essentially everything that touches on javascript, both the bad and the good.
I don't think there are very many ecosystems that are guaranteed to have only good stuff. Regardless of ecosystem, the developer has to examine what is available and make wise choices.
My experience is that probably more than 9/10 temp projects end up forever projects. My goal is never to work anywhere again that insists on just get it done quick and dirty "its temporary" ever again.
1. If you consider yourself a "backend developer" only and want to write the minimum amount of JS/TS.
2. If your application is simple. Yes you can do more complicated interactivity with oob swaps, but you end up with more complexity than you chose HTMX for.
For my next projects, I will still use Django but with React/Vue for pieces that need interactivity. As an example in my HTMX app, I wanted to add a profile image uploader. Lots of great frontend libraries exist to resize / modify your image before even uploading it to your server.
Finally, HTMX is just not testable the same way modern frontend libraries are. I've managed to write some decent tests using beautifulsoup, but it's night and day compared to vitest or jest.
For example, error handling in complex forms. When you have React handling errors you simply return a 400 JSON response with fields and reasons, or some other error message, and React decides what to do depending on the context, which it knows. When this responsibility is moved to the backend you now need to track the request location, state etc. and find the right fragment, which very quickly turned the code into a mess.
I think the choice of backend is also important. I suspect that Java (Spring Boot) made using HTMX much less pleasant than it would have been with something else, especially when it comes to templates and routing. Using Java for HTML templates (Thymeleaf or any of the other popular libraries) is something I will never do again.
Edit:
The analogy with jQuery is interesting. I feel the same way about HTMX now as I did about jQuery ten years ago. I used to plug jQuery into every project even if it was just to select elements or whatever, but whenever I used jQuery entirely over the frameworks that were popular at the time (Ember, Angular) I ended up with way messier code.
Maybe not? I'm just returning a 422 JSON response with fields and reasons and I have a tiny bit of JavaScript in the frontend that just plugs them in to the form with the built-in Constraint Validation API.
https://dev.to/yawaramin/handling-form-errors-in-htmx-3ncg
> I suspect that Java (Spring Boot) made using HTMX much less pleasant than it would have been with something else, especially when it comes to templates and routing.
I strongly agree with that and created a library to help with those aspects: https://github.com/yawaramin/dream-html?tab=readme-ov-file#f...
The problem is that end to end tests are the hardest kind to write. At least if you have a frontend code base you can have some tests there and get some confidence about things working at a lower level.
Only using the standard Django test client? I don't find this myself when I've had to work with HTMX code e.g. if you're using HTMX for your sign up form, it can be completely broken on the happy path and on form errors if the HTMX attributes are wrong, and the standard Django test client won't let you know, so you lose a lot of confidence when making refactors/changes.
This is a great point and should be underscored more. I think generally the HTMX vs React/Vue/Svelte argument gets undercut when people don't express their innate bias on which part of the stack they want to give more control to. HTMX is great if you're pro-expanding the server; JS Frameworks if you're trying to expand it from the application layer.
They're both fantastic expansions of what server-side rendering can do. They can't really do work as nice as what React can, but you can get perhaps 85% of React for 5-10% of the development time. And a big increase in usability of your app.
If I was to write tests, it'd be basically http get/post/put/delete requests and measuring the responses are what I expect.. how can HTMX be any different here ?
How do you "test" a button works without a browser engine ? Every browser engine ?
https://github.com/jsdom/jsdom
https://github.com/capricorn86/happy-dom
but they're about as reliable as you can expect: it's difficult to keep up the pace with the big three (or two) on standards compliance, and they usually don't even try.
So the only reliable solution is a headless Chromium, Firefox, and/or WebKit-based noname browser like the sibling says.
https://pptr.dev/guides/what-is-puppeteer
https://playwright.dev/
https://www.selenium.dev/documentation/
What's your plan for "plugging" these into your HTML? Web components?
Does Django have some kind of integration with Vite for hot reload during dev?
I'm interested in using it more, but I want to be 100% confident that I understand how to get htmx sites to work well with screen readers. I worry about things like fetching new data into a page not altering the screen reader user in the same way as refreshing a page completely would.
I'm not interested in whether or not htmx uses the correct ARIA attributes - I want to be confident that those ARIA attributes (or similar) do the right thing.
My ideal is still to use JavaScript libraries where the documentation not only describes how they work with screen readers, but is accompanied by video evidence showing the experience a screen reader user gets for different problems solved by that library.
As for handling dynamic content for screen readers, focus management is already a thing, and is in the scope of browser standards and the HTML your backend returns. As before, it's your responsibility to manage this. HTMX will neither help you nor get in your way.
HTMX merely extends hypertext functionality to its (mostly) natural conclusion. It is not a component library, or a framework for building components, or a site building framework, or...
You can use other tools to enhance and audit accessibility, but their use is orthogonal to HTMX. I think web developers in general are very used to frameworks abstracting a ton of complexity, but HTMX is not a framework so much as a standardized set of tools for specific low level problems, it is not a one stop shop.
Leaving accessibility up to the end developer feels like a genuine missed opportunity for me here. One of the great things about NOT using a JavaScript library is that you can rely on the browser's default accessibility features for forms and links. Those benefits are the thing I care most about when considering HTMX or jQuery or React or Vue or similar.
tl;dr htmx is better than a lot of alternatives, but Simon is right, it can improve this story and it has a responsibility to do so.
As a framing device: any interactivity that is not described with HTML is interactivity that someone is responsible for making accessible (which you correctly pointed out). Unlike JS frameworks, htmx encourages the developer to solve problems with HTML first, so the inaccessible surface area that the developer has to worry about is going to be much smaller on htmx-based applications than it is with JS-based applications. That's a pretty strict win from where a lot of the industry is right now.
That having been said, I agree with you (and disagree with a lot of our defenders in the comments) that thinking about this is in-scope for htmx. In fact, I'm a firm believer that libraries are exactly where responsibility for implementing ARIA attributes live. The average web developer should not have to think about this at all—they should be able to use declarative abstractions and trust that they are annotated correctly for screen readers. This is the only system that scales, and htmx should adhere to it as much as possible.
Ideally, htmx would just add the polite notification attribute to the elements it processes, and give an easy way to customize that. I think it's basically possible to do this in a backwards-compatible way (first as an extension) that aligns with the maintenance strategy outlined in this essay. And I do think we can improve the documentation as well.
What would be the appropriate place, imho, would be component frameworks that are built on top of htmx. FastHTML is an example; they already have htmx integration and they talk about server-side components. If we look at a popular one in React, this is what they do: https://blog.logrocket.com/aria-live-regions-for-javascript-...
Thinking about it in terms of dream-html[1], it might look like:
[1] https://github.com/yawaramin/dream-htmlIsn't this more of a general browser question that would apply to any website that uses Javascript to load page elements?
How would using HTMX (as opposed to any other library, or plain old Javascript) affect the answer to the question?
In a way it’s a bit of a lesson in managing complexity, rather than seek to be “the next JavaScript framework to replace all the others with its theory of the universe”, it instead carved off a smaller slice and said these Thich are related, we’re just for dealing with these thing, nothing more.
In one swoop a whole raft of manual developer programming workload was packed up with a new easier to understand abstraction.
Kudos to the team, I’m grateful for the considered way you’ve developed this tool for the rest of us.
Kudos to the developers.
I really like turbo-rails [0] (the ruby gem that Rails 7+ bundles in for turbo support, meaning helpers that make turbo frames/responses a native "thing" rails understands) because it's a complete solution. There's at least some obvious structure to build off of, and I'm not stuck trying to build up my own framework on the BE for my newly simpler FE.
django-htmx [1] also fits in this case too. I feel like any honest pitch of HTMX should involve some BE solution as well.
[0] https://github.com/hotwired/turbo-rails
[1] https://github.com/adamchainz/django-htmx
A large chunk of our business comes from Spring Boot, so we are experimenting with JTE - looks decent so far (Thymeleaf feels just old nowadays).
My sell is pretty simple: You have regulations coming up in europe which will require you to keep applications up-to date and secure. Extending your SBOM by 1k NPM libraries is a huge cost. I want to get rid of that.
Modern React is too simple. A component is just a pure function taking arguments and returning UI as JSX. The only other thing you need to know is few hooks.
People need to spend time learning this tool. They need to be proficient with it. Your new stack might need to still work with existing code at some point. That means training, overhead, ramp up and potential risk in a less established area. Why would people do that?
You should be thankful you didn't get warnings from your boss for messing around instead of actually pushing features out.
HTMX might not be something that will vanish in a week, but it's also nowhere close to a mainstream framework.
https://htmx.org/essays/when-to-use-hypermedia/#if-your-team...
the reality is that the only way to prove htmx is around for the long term is to stick around for the long term, and I hope this essay contributes towards that.
We'll see how this years JS rising stars shakes out.
In my opinion, HTMX + custom elements does everything React does but better, and is a billion times cleaner.
Would be interested in seeing this
> People shouldn’t feel pressure to upgrade htmx over time unless there are specific bugs that they want fixed
Frickin A! Nice to see somebody pushing back against the trend of "if you haven't updated your software in the last five minutes you're on an unsupported configuration".
Why programmers like cooking: You peel the carrot, you chop the carrot, you put the carrot in the stew. You don't suddenly find out that your peeler is several versions behind and they dropped support for carrots in 4.3
B) If you run into a bug, update that library, then look into fixing it and offering a PR with the fix. Easy-peasy.
Compared to: oh this is a bug in a library that's fixed in an update ... but then we need to update another library it depends on, but that requires an update to nodejs, but that requires us to update some other libraries, which introduce a new more serious regression, so we can't unless we re-write to remove that dependency ...
I have been calling for this for a very long time even during pjax era. I hope that is not only an ideal but a realistic pathway forward. Chrome / Blink or Safari / Webkit. If we could just get one of them to implement it as experimental feature. How could we push this forward?
JPEG XL and HTMX in HTML, along with some sort of basic rich text editor for everyday writing is what I want browser to be included by default.
https://alexanderpetros.com/triptych/
https://github.com/alexpetros/triptych?tab=readme-ov-file