The Future of Htmx

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.<p>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).<p>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.<p>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.

&gt; ...you can use as much or as little of it as you like... Stability as a Feature... No New Features as a Feature...<p>This is the way.<p>Having lived the alternative, I won&#x27;t consider building anything significant on top of an abstraction that doesn&#x27;t credibly promise these.<p>When the abstraction you&#x27;ve built on changes or fails, the thing you built breaks. When you choose an unstable abstraction, you&#x27;re creating future bugs you&#x27;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).<p>These aren&#x27;t concerns for things that will be short-lived, or are small enough to replace if needed. But I&#x27;ve seen plenty of small and temporary things turn into large and permanent things when they end up being useful.

I&#x27;ve created a Django application using HTMX. Usually I&#x27;d jump to React or Vue. It was a great exercise and I can see where HTMX would be a great fit.<p>1. If you consider yourself a &quot;backend developer&quot; only and want to write the minimum amount of JS&#x2F;TS.<p>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.<p>For my next projects, I will still use Django but with React&#x2F;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 &#x2F; modify your image before even uploading it to your server.<p>Finally, HTMX is just not testable the same way modern frontend libraries are. I&#x27;ve managed to write some decent tests using beautifulsoup, but it&#x27;s night and day compared to vitest or jest.

Anyone got a good feel for the htmx accessibility story at the moment?<p>I&#x27;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.<p>I&#x27;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.<p>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.

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&#x2F;has gone into developing html. And even for having the clarity to name it as such.<p>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.<p>In one swoop a whole raft of manual developer programming workload was packed up with a new easier to understand abstraction.<p>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 &#x2F; Fragments? If yes, how would you design it? Do we REALLY need an SPA?<p>Kudos to the developers.

People are commenting about &quot;no new features as a feature&quot;, and I agree, but even better is this:<p>&gt; People shouldn’t feel pressure to upgrade htmx over time unless there are specific bugs that they want fixed<p>Frickin A! Nice to see somebody pushing back against the trend of &quot;if you haven&#x27;t updated your software in the last five minutes you&#x27;re on an unsupported configuration&quot;.

&gt;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.<p>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 &#x2F; Blink or Safari &#x2F; Webkit. If we could just get one of them to implement it as experimental feature. How could we push this forward?<p>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&#x27;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.<p>There&#x27;s this vague general sense that the &quot;Web used to be simple&quot; and that &quot;Everything is so complex now&quot;. There&#x27;s even an enemy that can be pointed at: React and various other frameworks&#x2F;libraries and JS tools. Sometimes even JS itself isn&#x27;t safe from this.<p>Though I can never find myself agreeing with the arguments (if any get presented at all). There&#x27;s a reason we&#x27;re writing web APPS instead of web SITES now even if you might dislike it. Just as there&#x27;s a reason the world itself is now more complex now.<p>Ultimately I don&#x27;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&#x27;t pretend that the backend ecosystem is any different from JavaScript. By the time you&#x27;ve chosen the language, debated the backend framework&#x2F;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 &quot;No new features as a feature&quot;. IMO, page router NextJS is perfect (and in line with the original API it pitched), and the bifurcation to app&#x2F;page router has been complicated. Yes, I am fully aware that NextJS works with both app&#x2F;page. I just find it mentally confusing to wrap my head around both worlds.<p>I feel this way about base React too, including -- functional&#x2F;class components, hooks&#x2F;non-hooks, and more recently, RSCs&#x2F;Client components. Although I&#x27;m more willing to see React as an evolving research project, as contradictory as this may sound.

&gt; No New Features as a Feature<p>No new features is such an underrated feature. It&#x27;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.<p>In the world of AI tooling, &quot;completed&quot; 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.

&quot;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.&quot;<p>This argument is that jQuery is still very popular compared to JS <i>frameworks</i> like React, etc.<p>What about vanilla JS?<p>As someone who isn&#x27;t that experienced with JS, my understanding is that modern vanilla JS is &quot;about as good as&quot; jQuery. i.e. if you don&#x27;t need much JS these days, just choose vanilla JS.

I&#x27;ve found Htmx to be smug and misleading. &quot;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.&quot;

Overhyped, back to 20 years ago. No proper framework in any language. And no it&#x27;s not the new jquery.<p>You can&#x27;t do real time time tickers. You can&#x27;t call client side functions.<p>It&#x27;s hyped by entry level web devs, because they don&#x27;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.<p>It&#x27;s like going back to sysinit when you have systemd only worse. But HN never fails to hype bs tech

Anybody have any thoughts on if the View Transition API is going to replace a lot of HTMX usage?<p>This multi-page demo is decent, where each click is actually loading a new page: <a href="https:&#x2F;&#x2F;view-transitions.chrome.dev&#x2F;stack-navigator&#x2F;mpa-prerender&#x2F;" rel="nofollow">https:&#x2F;&#x2F;view-transitions.chrome.dev&#x2F;stack-navigator&#x2F;mpa-prer...</a><p><a href="https:&#x2F;&#x2F;developer.chrome.com&#x2F;docs&#x2F;web-platform&#x2F;view-transitions" rel="nofollow">https:&#x2F;&#x2F;developer.chrome.com&#x2F;docs&#x2F;web-platform&#x2F;view-transiti...</a><p>&gt; 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&#x27;s built as a multi-page application (MPA) or a single-page application (SPA). Typical situations where you would use view transitions include:<p>&gt; A thumbnail image on a product listing page that transitions into a full-size product image on the product detail page.<p>&gt; A fixed navigation bar that stays in place as you navigate from one page to another.<p>&gt; A grid with items moving positions as you filter through.<p>So this would cover a few uses of HTMX?<p>Recent Safari and Chrome now have decent support. Sounds like Firefox are working on it but I couldn&#x27;t find an expected release date.

I have used and like HTMX. But I think Unpoly is more batteries included, in a good way:<p><a href="https:&#x2F;&#x2F;unpoly.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;unpoly.com&#x2F;</a><p>It has more built-in functionality that most web applications are going to need.

I&#x27;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 <a href="https:&#x2F;&#x2F;github.com&#x2F;guyroyse&#x2F;htmx-tailwind-vite">https:&#x2F;&#x2F;github.com&#x2F;guyroyse&#x2F;htmx-tailwind-vite</a> and been delighted about it, it&#x27;s exactly what I need.

I&#x27;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.<p>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 &quot;no new feature as a feature&quot; part, but hasn&#x27;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.<p>There are so many sites out there using 4-5+ year old versions of React, and they all work perfectly fine. There&#x27;s no compulsion to upgrade if you don&#x27;t want to.

From the article;<p>&gt; 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.<p>I feel that is misleading. I worked on a lot of websites and none of them included jQuery willingly or sometimes even knowingly.<p>Either it&#x27;s shipped as a peer dependency or we&#x27;re talking about wordpress and the like which use it (and drives much of the web!).<p>I&#x27;ve seen it frequently shipped because of scripts embedded into a larger frontend codebase. Stuff they really don&#x27;t want there to begin with.<p>I do not for a second believe that 75% of frontend dev work is in jQuery. In fact, I&#x27;d be surprised if it&#x27;s more than 5% of all frontend engineering work is using jQuery.<p>Obviously some people might still use it for whatever reason; but those are a tiny majority (and probably quite vocal about it &#x2F; over represented if they still prefer it).<p>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&#x27;s still the preferred choice for the majority of web developers.

I really wish htmx would use fetch rather than xhr, and now it looks like that won’t happen. Fetch is easier to proxy, so it would open up a lot more possibilities for backends, like ones running in browser or a native process. I had to hack together a xhr fetch proxy to make this happen.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;logankeenan&#x2F;xhr-fetch-proxy">https:&#x2F;&#x2F;github.com&#x2F;logankeenan&#x2F;xhr-fetch-proxy</a>

I value the hard stance on stability and backwards compatibility over the constant churn that some JS libraries&#x2F;frameworks have. I understand the need both approaches, but this is a breath of fresh air.<p>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.

Good. For a couple of seconds, I feared something like &quot;The next step of our wonderful journey...&quot;.

Love this.<p>The attitude of the htmx developers is highly commendable.

It is clear that htmx has a growing community, but it still feels a bit too backend-minded to convince frontend developers to adopt it. I tried it in a prototype, and it was quite pleasant until I realised I needed to account for additional state management and backend wrangling to be able to provide some dynamic features. That was the moment I realised htmx is not a fully fledged product but rather a core feature that sits neatly atop a traditional server-driven setup.<p>That&#x27;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&#x27;s the only way I can see dev teams buying into the paradigm change and htmx jumping into mainstream usage.

I&#x27;d love to see the single `htmx.js` source file annotated and displayed like the classic `backbone.js` documentation[1]<p>[1]: <a href="https:&#x2F;&#x2F;backbonejs.org&#x2F;docs&#x2F;backbone.html" rel="nofollow">https:&#x2F;&#x2F;backbonejs.org&#x2F;docs&#x2F;backbone.html</a><p>[2]: <a href="https:&#x2F;&#x2F;github.com&#x2F;jashkenas&#x2F;backbone&#x2F;blob&#x2F;master&#x2F;backbone.js">https:&#x2F;&#x2F;github.com&#x2F;jashkenas&#x2F;backbone&#x2F;blob&#x2F;master&#x2F;backbone.j...</a><p>[3]: <a href="https:&#x2F;&#x2F;github.com&#x2F;bigskysoftware&#x2F;htmx&#x2F;blob&#x2F;master&#x2F;src&#x2F;htmx.js">https:&#x2F;&#x2F;github.com&#x2F;bigskysoftware&#x2F;htmx&#x2F;blob&#x2F;master&#x2F;src&#x2F;htmx....</a>

I&#x27;m huge a supporter of the HTMX philosophy. I highly recommend reading Hypermedia Systems especially for people that are just beginning doing web development. I&#x27;ve purchased the book and it was a wonderful read especially for its explanations and pragmatism.

&gt; This means accepting and documenting the quirks of the current implementation.<p>If you&#x27;re planning no new features as a feature, why not first remove those quirks? Why keep them around?<p>&gt; People shouldn’t feel pressure to upgrade htmx over time unless there are specific bugs that they want fixed<p>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&#x27;t have to refuse progress - it&#x27;s just a &quot;more&quot; work for the creator.

I will never understand how is it possible that htmx has become more popular than Unpoly, when Unpoly exists since a long time ago, has been very stable, has a lot more features, it has a nicer API, better docs, etc. I just don’t get it.

If you like this approach but want a full-stack JS solution, check out Joystick [1] (the philosophy [2] page echoes a lot of the same sentiments here).<p>[1] <a href="https:&#x2F;&#x2F;cheatcode.co&#x2F;joystick" rel="nofollow">https:&#x2F;&#x2F;cheatcode.co&#x2F;joystick</a><p>[2] <a href="https:&#x2F;&#x2F;docs.cheatcode.co&#x2F;joystick&#x2F;philosophy" rel="nofollow">https:&#x2F;&#x2F;docs.cheatcode.co&#x2F;joystick&#x2F;philosophy</a>

It could be my inexperience, but something that helps manage state would be awesome. I’ve found myself having to do some pretty wild things to maintain a certain UI state server side. It could be that’s just the way it is too. Otherwise, I’ve used htmx a decent amount and really like it.

I briefly evaluated htmx with a go backend - and for simple navigation etc it works quite well. where I struggle is using more advanced web-components like datepickers etc. - as I dont want reimplement it from scratch.<p>any advise from others how they handle complex client side components?

Off topic but the other day I tried again to build a vanilla JS application.<p>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.<p>I like to try library free JS every now and then and yet again it was not competition for react.<p>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.<p>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.

I am a fan of this approach. About to launch a SaaS now and htmx powers much of the interaction so far.<p>Tools like htmx make it easier for solo founders and small teams who don&#x27;t have the bandwidth or the desire to manage all the churn. Keep the dependencies tight and ship!

Greatly appreciate this philosophy and what htmx brings to the table. It is very simple and quick to pick up, and the longterm stability and simplicity are major advantages for web development.

I use alpine and htmx. God above I have no idea how the more complex pages work. They&#x27;re a maintainability nightmare. Still, Claude can write both and it works, soo...

i used htmx to write a full b2b insuretech app with customers in 15 days. thats concept to live production grade, enterprise financial app.<p>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.

&gt; No New Features as a Feature<p>&gt; We are going to be increasingly inclined to not accept new proposed features in the library core<p>I deeply wish the C# team recognized the value of this.

I&#x27;m so in love with the philosophy of this project. It&#x27;s one of the few frameworks that I feel can do no wrong.

Even better:<p><a href="https:&#x2F;&#x2F;leanrada.com&#x2F;htmz&#x2F;" rel="nofollow">https:&#x2F;&#x2F;leanrada.com&#x2F;htmz&#x2F;</a>

I did stuff with intercooler a while ago and loved it, I never got around to htmx, maybe now is the time

Is jquery something people start projects with today? If so, what is the motivation?

Everything listed here is a great pitch for vanillajs with zero framework at all.

&gt; the front end world in particular, which has comical levels of churn<p>Unbelievably so

I&#x27;ve built <a href="https:&#x2F;&#x2F;golfcourse.wiki" rel="nofollow">https:&#x2F;&#x2F;golfcourse.wiki</a> with heavy use of htmx.<p>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.<p>Htmx is perfect for this.<p>Is it elegant? Yes and no. Is it ideal? No. But <i>what it does very well</i> is let me focus on the code I&#x27;m writing (python&#x2F;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&#x27;t actually want to be in.<p>I&#x27;m not getting paid for this, and I won&#x27;t actually spend my time coding if I&#x27;m not excited about the way I&#x27;m working. Htmx let&#x27;s me code the way I want to code and that&#x27;s why I&#x27;m a big fan.

This is so refreshing to read

Htmx always sounded nice and I always wanted to give it a try - yet, paradoxically, I always had my reservations about it on the conceptual level.<p>With something like Elm, I&#x27;m basically thinking of the frontend as a state machine (composed of smaller state machines). I always know what&#x27;s [supposed to be] going on exactly, and assuming that all the underlying machinery is working as expected and that I haven&#x27;t messed up anywhere, I can be sure that everything is consistent. Basically, things are data-driven.<p>Htmx feels like a step back in this regard. Let&#x27;s say <a href="https:&#x2F;&#x2F;htmx.org&#x2F;examples&#x2F;delete-row&#x2F;" rel="nofollow">https:&#x2F;&#x2F;htmx.org&#x2F;examples&#x2F;delete-row&#x2F;</a> - something back in my mind yells at me that I don&#x27;t really know what I&#x27;m presenting in that table. The state is in DOM, all &quot;inverted&quot; as the frontend is not really aware what it&#x27;s displaying (it can figure it out by introspecting the DOM, but that&#x27;s exactly what feels off). I&#x27;m just concerned that it&#x27;ll end up like my ancient Delphi or Visual Basic projects, where it was impossible to understand what&#x27;s going on, because everything got tangled up in a ball. This is opposite of data-driven approach that I don&#x27;t really know a name for... &quot;shape-driven&quot;?<p>I look at examples like <a href="https:&#x2F;&#x2F;htmx.org&#x2F;examples&#x2F;sortable&#x2F;" rel="nofollow">https:&#x2F;&#x2F;htmx.org&#x2F;examples&#x2F;sortable&#x2F;</a> and I just can&#x27;t shrug off the feeling that with such design the frontend has no idea about what&#x27;s going on, and while it&#x27;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.<p>I suspect this is because HTML was always about documents, and never about interactive applications, so there&#x27;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&#x2F;CSS for rendering, and canvas-based GUIs being the way to go, unburdened by the document-based foundations anymore. In other words, I&#x27;m not really convinced that Hypermedia is a suitable foundation for a lot of the things people actually build online.<p>Htmx surely has appeal in simplicity, but doesn&#x27;t this simplicity brings back all the complexity people tried to get rid of all this time? Is there something I&#x27;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&#x27;s never aware of what&#x27;s going on? Or is it something else?<p>My apologies for the confusion, or if I wrote something weird (I sure babbled a lot). I&#x27;m just trying to keep up with the world and understand it.<p>(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&#x27;t bloat and rot over time?)

i love frontends like shadcn&#x2F;ui too much to go away from react - AS MUCH as I&#x27;d love to do it since I hate npm cancer to death

I feel this article makes the same mistake many technical articles make.<p>What does it do? After reading a large chunk of the article, I have no idea. No, wait it &quot;enables behavior&quot;.<p>Maybe it&#x27;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.

This is just people&#x27;s subconsciousness fighting against the rolling progress. It&#x27;s trying to avoid learning new things and trying to preserve the status quo where you can keep rolling using the already acquired knowledge. It&#x27;s anti-thetical to being a hacker.<p>The modern way is to use LLMs to auto generate all this code and do some small corrections in the process. So you wouldn&#x27;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&#x27;t run geosites forever.