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]
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.
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.
> ...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 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'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.
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.
> 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.
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 ?
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.
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’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.
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 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.
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".
>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.
I don't want to bring politics into this, but I find the hype behind HTMX eerily similar to the populist vibes I get reading what their voters write.
There's this vague general sense that the "Web used to be simple" and that "Everything is so complex now". There's even an enemy that can be pointed at: React and various other frameworks/libraries and JS tools. Sometimes even JS itself isn't safe from this.
Though I can never find myself agreeing with the arguments (if any get presented at all). There's a reason we're writing web APPS instead of web SITES now even if you might dislike it. Just as there's a reason the world itself is now more complex now.
Ultimately I don't hate HTMX or the people who want to use it. Though to me the experience of actually using it is awful. I would ask people that they don't pretend that the backend ecosystem is any different from JavaScript. By the time you've chosen the language, debated the backend framework/chosen your templating solution and DB library and build system you could have gotten through the decision paralysis for JS too.
As a React developer, I love that HTMX is trying to aim for stewardship and "No new features as a feature". IMO, page router NextJS is perfect (and in line with the original API it pitched), and the bifurcation to app/page router has been complicated. Yes, I am fully aware that NextJS works with both app/page. I just find it mentally confusing to wrap my head around both worlds.
I feel this way about base React too, including -- functional/class components, hooks/non-hooks, and more recently, RSCs/Client components. Although I'm more willing to see React as an evolving research project, as contradictory as this may sound.
I’ve been bitten so many times with the app/page router thinking I was looking at docs for one but I was actually looking at them for the other. So annoying.
No new features is such an underrated feature. It's funny sometimes when people see some Common Lisp or Clojure library with no commits in the last X period of time, and people immediately come to the conclusion that something must be wrong.
In the world of AI tooling, "completed" should have a huge advantage over libraries with lots of churn. Maybe a positive side-effect of new AI tooling is that there will be competitive pressure for libraries to reach a completed, no-new-features state.
"Today many web developers consider jQuery to be “legacy software.” With all due respect to this perspective, jQuery is currently used on 75% of all public websites, a number that dwarfs all other JavaScript tools."
This argument is that jQuery is still very popular compared to JS frameworks like React, etc.
What about vanilla JS?
As someone who isn't that experienced with JS, my understanding is that modern vanilla JS is "about as good as" jQuery. i.e. if you don't need much JS these days, just choose vanilla JS.
I've found Htmx to be smug and misleading. "Look how simple it is! No JavaScript! Ignore the fact that you need a complex backend in a separate language and environment to generate your html."
Overhyped, back to 20 years ago.
No proper framework in any language.
And no it's not the new jquery.
You can't do real time time tickers. You can't call client side functions.
It's hyped by entry level web devs, because they don't know any better.
You get all the baggage with it, that you hoped to be rid of with the separation of data provider and client consumer.
Session management, path parsing and matching, flash messages, complicated nested
if else blocks. Argh.
Search engines can crawl js nowadays.
It's like going back to sysinit when you have systemd only worse.
But HN never fails to hype bs tech
> The View Transition API gives you the power to create seamless visual transitions between different views on your website. This creates a more visually engaging user experience for users as they navigate your site, regardless of whether it's built as a multi-page application (MPA) or a single-page application (SPA). Typical situations where you would use view transitions include:
> A thumbnail image on a product listing page that transitions into a full-size product image on the product detail page.
> A fixed navigation bar that stays in place as you navigate from one page to another.
> A grid with items moving positions as you filter through.
So this would cover a few uses of HTMX?
Recent Safari and Chrome now have decent support. Sounds like Firefox are working on it but I couldn't find an expected release date.
i think the transition API, when it is broadly available for MPAs, could replace a fair number of simple UI use cases of htmx. The main feature it would likely obsolete is the `hx-boost` feature:
If that goes away, htmx will be useful for smaller transclusional features at a lower level of complexity, so the two should complement one another in my opinion.
I've been a Vue user for years, I do automations and glue code mostly, and most of the times using Vue is a bit too much, for my last project I used https://github.com/guyroyse/htmx-tailwind-vite and been delighted about it, it's exactly what I need.
I'd love to use HTMX at work. Sadly the security folks would probably balk at checking in JS code that uses eval(), even though you can disable eval at runtime in the HTMX config.
I thought about writing a script to remove all references to eval (and all tests relying on eval), but at that point it would probably be easier to just rewrite the library.
I see so many people praising the "no new feature as a feature" part, but hasn't semantic versioning already solved that problem? If you are on version 3.x.x of a library, why do you care if 4.x or 5.x or 6.x is launched, other than FOMO? Just keep using whatever version you want and let others have shiny new things.
There are so many sites out there using 4-5+ year old versions of React, and they all work perfectly fine. There's no compulsion to upgrade if you don't want to.
Because your potential dependencies will require 5.x as a peer dependency, so you have to use 5.x. Because your current dependencies will fix bugs or introduce features that you need in versions that upgrade their peer dependency to 5.x, so you have to use 5.x. Because the package itself will fix certain bugs that exist in 3.x but will only fix them in 5.x, so you have to use 5.x.
> Today many web developers consider jQuery to be “legacy software.” With all due respect to this perspective, jQuery is currently used on 75% of all public websites, a number that dwarfs all other JavaScript tools.
I feel that is misleading. I worked on a lot of websites and none of them included jQuery willingly or sometimes even knowingly.
Either it's shipped as a peer dependency or we're talking about wordpress and the like which use it (and drives much of the web!).
I've seen it frequently shipped because of scripts embedded into a larger frontend codebase. Stuff they really don't want there to begin with.
I do not for a second believe that 75% of frontend dev work is in jQuery. In fact, I'd be surprised if it's more than 5% of all frontend engineering work is using jQuery.
Obviously some people might still use it for whatever reason; but those are a tiny majority (and probably quite vocal about it / over represented if they still prefer it).
So yes, to all intends and purposes I would claim jQuery is legacy software. Current usage (wherever they got that number from) does not mean it's still the preferred choice for the majority of web developers.
[+] [-] danpalmer|1 year ago|reply
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.
[+] [-] alexpetros|1 year ago|reply
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/
[+] [-] mring33621|1 year ago|reply
HTMX had no issue, tho
[+] [-] srameshc|1 year ago|reply
[+] [-] pkkkzip|1 year ago|reply
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.
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] werdnapk|1 year ago|reply
[+] [-] arresin|1 year ago|reply
That's interesting. Do some people prefer this style? If yes, how come?
[+] [-] urronglol|1 year ago|reply
[+] [-] jmull|1 year ago|reply
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.
[+] [-] game_the0ry|1 year ago|reply
Given my experience with node ecosystem, react, and nextjs, I am inclined to agree.
[+] [-] citizenpaul|1 year ago|reply
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.
[+] [-] jilles|1 year ago|reply
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.
[+] [-] queenmab|1 year ago|reply
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.
[+] [-] igortg|1 year ago|reply
[+] [-] eawgewag|1 year ago|reply
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.
[+] [-] viraptor|1 year ago|reply
[+] [-] x0x0|1 year ago|reply
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.
[+] [-] worthless-trash|1 year ago|reply
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 ?
[+] [-] pier25|1 year ago|reply
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?
[+] [-] silviogutierrez|1 year ago|reply
[+] [-] simonw|1 year ago|reply
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.
[+] [-] imacrayon|1 year ago|reply
[+] [-] 1propionyl|1 year ago|reply
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.
[+] [-] alexpetros|1 year ago|reply
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.
[+] [-] nodamage|1 year ago|reply
Isn'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?
[+] [-] evolve2k|1 year ago|reply
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.
[+] [-] xvinci|1 year ago|reply
Kudos to the developers.
[+] [-] graypegg|1 year ago|reply
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
[+] [-] kgeist|1 year ago|reply
[+] [-] jjk7|1 year ago|reply
In my opinion, HTMX + custom elements does everything React does but better, and is a billion times cleaner.
[+] [-] BrenBarn|1 year ago|reply
> 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".
[+] [-] ksec|1 year ago|reply
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.
[+] [-] recursivedoubts|1 year ago|reply
https://alexanderpetros.com/triptych/
https://github.com/alexpetros/triptych?tab=readme-ov-file
[+] [-] dminik|1 year ago|reply
There's this vague general sense that the "Web used to be simple" and that "Everything is so complex now". There's even an enemy that can be pointed at: React and various other frameworks/libraries and JS tools. Sometimes even JS itself isn't safe from this.
Though I can never find myself agreeing with the arguments (if any get presented at all). There's a reason we're writing web APPS instead of web SITES now even if you might dislike it. Just as there's a reason the world itself is now more complex now.
Ultimately I don't hate HTMX or the people who want to use it. Though to me the experience of actually using it is awful. I would ask people that they don't pretend that the backend ecosystem is any different from JavaScript. By the time you've chosen the language, debated the backend framework/chosen your templating solution and DB library and build system you could have gotten through the decision paralysis for JS too.
[+] [-] eawgewag|1 year ago|reply
I feel this way about base React too, including -- functional/class components, hooks/non-hooks, and more recently, RSCs/Client components. Although I'm more willing to see React as an evolving research project, as contradictory as this may sound.
[+] [-] WD-42|1 year ago|reply
[+] [-] uludag|1 year ago|reply
No new features is such an underrated feature. It's funny sometimes when people see some Common Lisp or Clojure library with no commits in the last X period of time, and people immediately come to the conclusion that something must be wrong.
In the world of AI tooling, "completed" should have a huge advantage over libraries with lots of churn. Maybe a positive side-effect of new AI tooling is that there will be competitive pressure for libraries to reach a completed, no-new-features state.
[+] [-] bravura|1 year ago|reply
This argument is that jQuery is still very popular compared to JS frameworks like React, etc.
What about vanilla JS?
As someone who isn't that experienced with JS, my understanding is that modern vanilla JS is "about as good as" jQuery. i.e. if you don't need much JS these days, just choose vanilla JS.
[+] [-] robertoandred|1 year ago|reply
[+] [-] lakomen|1 year ago|reply
You can't do real time time tickers. You can't call client side functions.
It's hyped by entry level web devs, because they don't know any better. You get all the baggage with it, that you hoped to be rid of with the separation of data provider and client consumer. Session management, path parsing and matching, flash messages, complicated nested if else blocks. Argh. Search engines can crawl js nowadays.
It's like going back to sysinit when you have systemd only worse. But HN never fails to hype bs tech
[+] [-] seanwilson|1 year ago|reply
This multi-page demo is decent, where each click is actually loading a new page: https://view-transitions.chrome.dev/stack-navigator/mpa-prer...
https://developer.chrome.com/docs/web-platform/view-transiti...
> The View Transition API gives you the power to create seamless visual transitions between different views on your website. This creates a more visually engaging user experience for users as they navigate your site, regardless of whether it's built as a multi-page application (MPA) or a single-page application (SPA). Typical situations where you would use view transitions include:
> A thumbnail image on a product listing page that transitions into a full-size product image on the product detail page.
> A fixed navigation bar that stays in place as you navigate from one page to another.
> A grid with items moving positions as you filter through.
So this would cover a few uses of HTMX?
Recent Safari and Chrome now have decent support. Sounds like Firefox are working on it but I couldn't find an expected release date.
[+] [-] recursivedoubts|1 year ago|reply
https://htmx.org/attributes/hx-boost/
There are already people, including people on the core htmx team, who think that hx-boost isn't a great feature:
https://htmx.org/quirks/#some-people-don-t-like-hx-boost
If that goes away, htmx will be useful for smaller transclusional features at a lower level of complexity, so the two should complement one another in my opinion.
[+] [-] rsyring|1 year ago|reply
https://unpoly.com/
It has more built-in functionality that most web applications are going to need.
[+] [-] AbraKdabra|1 year ago|reply
[+] [-] kweingar|1 year ago|reply
I thought about writing a script to remove all references to eval (and all tests relying on eval), but at that point it would probably be easier to just rewrite the library.
[+] [-] recursivedoubts|1 year ago|reply
[+] [-] paxys|1 year ago|reply
There are so many sites out there using 4-5+ year old versions of React, and they all work perfectly fine. There's no compulsion to upgrade if you don't want to.
[+] [-] reshlo|1 year ago|reply
[+] [-] atsjie|1 year ago|reply
> Today many web developers consider jQuery to be “legacy software.” With all due respect to this perspective, jQuery is currently used on 75% of all public websites, a number that dwarfs all other JavaScript tools.
I feel that is misleading. I worked on a lot of websites and none of them included jQuery willingly or sometimes even knowingly.
Either it's shipped as a peer dependency or we're talking about wordpress and the like which use it (and drives much of the web!).
I've seen it frequently shipped because of scripts embedded into a larger frontend codebase. Stuff they really don't want there to begin with.
I do not for a second believe that 75% of frontend dev work is in jQuery. In fact, I'd be surprised if it's more than 5% of all frontend engineering work is using jQuery.
Obviously some people might still use it for whatever reason; but those are a tiny majority (and probably quite vocal about it / over represented if they still prefer it).
So yes, to all intends and purposes I would claim jQuery is legacy software. Current usage (wherever they got that number from) does not mean it's still the preferred choice for the majority of web developers.