by polyrand on 1/6/25, 6:05 PM with 431 comments
by danpalmer on 1/6/25, 8:53 PM
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.
by jmull on 1/6/25, 7:03 PM
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.
by jilles on 1/6/25, 6:57 PM
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.
by simonw on 1/6/25, 8:00 PM
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.
by evolve2k on 1/6/25, 6:40 PM
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.
by xvinci on 1/6/25, 6:27 PM
Kudos to the developers.
by BrenBarn on 1/6/25, 7:53 PM
> 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".
by ksec on 1/6/25, 7:29 PM
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.
by dminik on 1/7/25, 12:53 AM
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.
by eawgewag on 1/6/25, 6:46 PM
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.
by uludag on 1/6/25, 7:08 PM
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.
by bravura on 1/6/25, 7:01 PM
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.
by robertoandred on 1/6/25, 9:41 PM
by lakomen on 1/6/25, 9:49 PM
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
by seanwilson on 1/6/25, 9:25 PM
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.
by rsyring on 1/6/25, 10:15 PM
It has more built-in functionality that most web applications are going to need.
by AbraKdabra on 1/6/25, 7:46 PM
by kweingar on 1/6/25, 7:01 PM
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.
by paxys on 1/6/25, 11:03 PM
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.
by atsjie on 1/7/25, 11:47 AM
> 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.
by logankeenan on 1/6/25, 6:50 PM
by tbatchelli on 1/6/25, 6:39 PM
I also happen to think that most web apps have no business being so complex, and that too much work goes into dealing with the added complexity of running SPAs where an SPA is not needed.
by fermigier on 1/6/25, 7:04 PM
by stevoski on 1/6/25, 7:01 PM
The attitude of the htmx developers is highly commendable.
by mtrovo on 1/6/25, 8:48 PM
That's why I think their roadmap looks right. I believe the way to broader adoption is to improve tooling, encourage standardisation, and integrate htmx more closely with well-known frameworks. That's the only way I can see dev teams buying into the paradigm change and htmx jumping into mainstream usage.
by metafeather on 1/7/25, 10:46 PM
[1]: https://backbonejs.org/docs/backbone.html
[2]: https://github.com/jashkenas/backbone/blob/master/backbone.j...
[3]: https://github.com/bigskysoftware/htmx/blob/master/src/htmx....
by liendolucas on 1/6/25, 8:07 PM
by jakubmazanec on 1/6/25, 9:52 PM
If you're planning no new features as a feature, why not first remove those quirks? Why keep them around?
> People shouldn’t feel pressure to upgrade htmx over time unless there are specific bugs that they want fixed
Truly, there exists a middle path: you can make breaking changes and user still can upgrade at their own pace (using future flags, codemods, etc.), you don't have to refuse progress - it's just a "more" work for the creator.
by 0xblinq on 1/12/25, 11:55 AM
by rglover on 1/6/25, 8:25 PM
by memhole on 1/7/25, 2:15 AM
by malteg on 1/7/25, 7:32 AM
any advise from others how they handle complex client side components?
by andrewstuart on 1/6/25, 6:39 PM
By the end of the day having built quite a lot I then converted the entire thing to react within half an hour stopped wasting my time and got in with the job of building the thing.
I like to try library free JS every now and then and yet again it was not competition for react.
I know react, it makes sense to me, I find it easy and powerful, I know how to fix most issues and probably most importantly Claude is able to write react for me almost without me intervening at all.
I’m not saying react is for everyone but for me it’s a power tool that I know and the AI knows very well and it gets big stuff built quick.
by lemonwaterlime on 1/6/25, 7:28 PM
Tools like htmx make it easier for solo founders and small teams who don't have the bandwidth or the desire to manage all the churn. Keep the dependencies tight and ship!
by kmos17 on 1/6/25, 6:57 PM
by nprateem on 1/7/25, 1:54 PM
by darcwader on 1/10/25, 2:47 PM
i can tell you that it fits so so perfectly for finance apps with lots of forms and data. we have a very sophisticated quote page which also with oob was a breeze.
by ijidak on 1/6/25, 9:49 PM
> We are going to be increasingly inclined to not accept new proposed features in the library core
I deeply wish the C# team recognized the value of this.
by mlekoszek on 1/6/25, 11:05 PM
by shagbag on 1/7/25, 12:28 AM
by dec0dedab0de on 1/7/25, 3:35 AM
by whinvik on 1/6/25, 6:32 PM
by morganherlocker on 1/6/25, 11:53 PM
by exabrial on 1/7/25, 5:43 PM
Unbelievably so
by scoofy on 1/7/25, 12:42 AM
Yes, my site appears a bit clunky (this is intentional), but as a solo, full stack developer working on a personal project, I wanted things to be stipped down and focus on having a solid backend and significant tests.
Htmx is perfect for this.
Is it elegant? Yes and no. Is it ideal? No. But what it does very well is let me focus on the code I'm writing (python/flask), without having to put three different hats on (frontend, backend, and interactive js), and it lets me code in the language I love (python) without forcing me into a gigantic javascript platform I don't actually want to be in.
I'm not getting paid for this, and I won't actually spend my time coding if I'm not excited about the way I'm working. Htmx let's me code the way I want to code and that's why I'm a big fan.
by cush on 1/7/25, 12:29 AM
by drdaeman on 1/6/25, 8:37 PM
With something like Elm, I'm basically thinking of the frontend as a state machine (composed of smaller state machines). I always know what's [supposed to be] going on exactly, and assuming that all the underlying machinery is working as expected and that I haven't messed up anywhere, I can be sure that everything is consistent. Basically, things are data-driven.
Htmx feels like a step back in this regard. Let's say https://htmx.org/examples/delete-row/ - something back in my mind yells at me that I don't really know what I'm presenting in that table. The state is in DOM, all "inverted" as the frontend is not really aware what it's displaying (it can figure it out by introspecting the DOM, but that's exactly what feels off). I'm just concerned that it'll end up like my ancient Delphi or Visual Basic projects, where it was impossible to understand what's going on, because everything got tangled up in a ball. This is opposite of data-driven approach that I don't really know a name for... "shape-driven"?
I look at examples like https://htmx.org/examples/sortable/ and I just can't shrug off the feeling that with such design the frontend has no idea about what's going on, and while it's fine if all I ever need is a small sorted list (that I can pull back from DOM - which acts like a weird pseudo-database), if it grows it becomes error-prone, difficult to comprehend and maintain.
I suspect this is because HTML was always about documents, and never about interactive applications, so there's this fundamental impedance mismatch when one tries to build an application in a browser. I thought the solution was to build a new abstraction replacing HTML - with things like React being intermediate steps, still using HTML/CSS for rendering, and canvas-based GUIs being the way to go, unburdened by the document-based foundations anymore. In other words, I'm not really convinced that Hypermedia is a suitable foundation for a lot of the things people actually build online.
Htmx surely has appeal in simplicity, but doesn't this simplicity brings back all the complexity people tried to get rid of all this time? Is there something I'm missing? Should I possibly think of the frontend as a terminal-like system that can run small programs but is not an application so it's never aware of what's going on? Or is it something else?
My apologies for the confusion, or if I wrote something weird (I sure babbled a lot). I'm just trying to keep up with the world and understand it.
(And, of course, no doubt, one can write crappy incomprehensible mess of a codebase using any technology. Maybe all my issues is that I have no idea how to write good Htmx code that wouldn't bloat and rot over time?)
by chimen on 1/6/25, 8:26 PM
by _tom_ on 1/6/25, 6:44 PM
What does it do? After reading a large chunk of the article, I have no idea. No, wait it "enables behavior".
Maybe it's only relevant to people that are already familiar with it. But it would seem that a hacker news front page would be a great opportunity to let more people know about your product.
by buryat on 1/6/25, 7:23 PM
The modern way is to use LLMs to auto generate all this code and do some small corrections in the process. So you wouldn't have to worry about the underlying tech and would only be concerned about the core functionality and actual mechanics of the product rather than being interested and spending efforts on memorization of the specific instructions for the machine. The whole evolution of the programming languages is a process in that direction and new technologies that were embraced by the newer generation like React and Vue.js is the way to go. You can't run geosites forever.