The htmx team is very happy to announce the release of htmx 4.0.0! This is the culmination of 8 months of work (plus a game) and we are very happy with the results.
The idea of htmx 4 started to germinate when I decided to create fixi and, in doing so, got
more familiar with the fetch() API and async programming in JavaScript. (htmx had always
used XMLHttpRequest due
to backwards compatibility issues.)
One chance evening I was contacted by Christian, who had some interesting ideas
around streaming HTML that
got me thinking that moving the internals to fetch() would simplify things for him and for the library in general.
After a bit of work I managed to get Michael and Alex on board, and we were off to the races.
Development has been very smooth. We started a port of fixi + the htmx test suite. Over time, we rediscovered why htmx did many of the things that it did and moved our new implementation closer and closer to the old one. At this point the behavioral differences between 2.x and 4.x are relatively small and where they do diverge we have made explicit choices that we feel will put htmx-based applications in a good spot for being 100-year web services
Note that we are not marking 4.0 as latest in NPM
because we do not want to force-upgrade users who are relying on non-versioned CDN URLs for htmx. Instead, 2.x will
remain latest and the 4.0 line will remain next until some point in early 2027. The website, however, will reference 4.0.
As mentioned above, htmx 4, from a user’s viewpoint, is almost identical to htmx 2. There are three major changes:
localStorage by default (which was a cause of many support headaches). Most people
won’t notice this at all.Internally, we migrated from XMLHttpRequest to fetch() but that should be transparent for most users of htmx.
In htmx 2 many attributes were “inherited” by default. This allows you to place attributes on parent elements and their behavior will apply to child elements. This behavior, which came from the intercooler.js days, was inspired by CSS and, unsurprisingly, worked out about the same as CSS: powerful but difficult to understand at times.
In htmx 4 attributes are not inherited unless you explicitly say so by adding an
:inherited after the attribute name:
<!-- htmx 2 -->
<div hx-confirm="Are you sure?">
<button hx-delete="/item/1">Delete</button>
</div>
<!-- htmx 4 -->
<div hx-confirm:inherited="Are you sure?">
<button hx-delete="/item/1">Delete</button>
</div>
This will be the largest upgrade burden in migrating from htmx 2 to htmx 4. To make things easier, we have provided a command line tool to find places you need to mark as inherited.
Note that attributes like hx-disinherit, etc. are no longer required and should be removed.
The events triggered by htmx 2 had grown organically over the life of the library and were not particularly well organized, making it difficult to know exactly which event was fired when.
In htmx 4, all events now follow htmx:phase:action[:sub-action]:
| htmx 2 | htmx 4 |
|---|---|
htmx:beforeRequest | htmx:before:request |
htmx:afterRequest | htmx:after:request |
htmx:beforeSwap | htmx:before:swap |
htmx:afterSwap | htmx:after:swap |
htmx:configRequest | htmx:config:request |
In addition, the following changes were made:
htmx:error. HTTP error responses fire
htmx:response:error.htmx:xhr:* events are removed. htmx 4 uses fetch().htmx:validation:* events are removed in favor of native browser form validation.The full table is in What’s New in htmx 4.
The command line upgrade checker flags old event names in hx-on attributes and in your JavaScript where it can find
them.
History support has always been included in htmx, allowing you to implement back-button aware actions with simple
attributes. In htmx 2, a cache in localStorage was used to snapshot pages for restoration. Unfortunately a large
source of issues was that this snapshot could include DOM mutations by 3rd party JavaScript libraries. When the page was
restored, those mutations remained but the underlying JavaScript logic was not.
htmx 4 does not cache pages in localStorage. On back navigation htmx re-fetches the page and swaps it into <body>,
or into the [hx-history-elt] element if one is present. This allows 3rd party JavaScript libraries to “just work” in
most cases and, with good request caching, is very fast.
If you want local caching instead, we now ship a very complete hx-history-cache
extension that restores history from sessionStorage and is designed to integrate well with scripting solutions like
Alpine.js, etc.
There are two big new features in htmx 4, both of which we are really excited about:
We now support morphing swaps out of the box with htmx. I created idiomorph and nearly included it in htmx 2.x but decided against it. In htmx 4, Michael has done great work improving on that algorithm and integrating it seamlessly into htmx.
<hx-partial>Another major new feature is the <hx-partial> tag. This tag is similar to out-of-band swaps,
but is much clearer when you want to do something beyond just replacing a single element with a new version of itself:
<hx-partial hx-target="#messages" hx-swap="beforeend">
<div>New message</div>
</hx-partial>
<hx-partial hx-target="#count">
<span>5</span>
</hx-partial>
Much of the excitement in htmx 4 is in the extensions. Switching to fetch() internally let us rethink how extensions
can and should work, and sparked the creation (and recreation) of many new extensions, for example:
hx-preload - preload content (e.g. on mouseover) to speed requests uphx-download - native, fetch-based file downloadshx-alpine-compat - smooths over compatibility issues between htmx and Alpine.jshx-history-cache - caches history in sessionStorage, provides Alpine.js compatibilityAdditionally, there are three new or updated streaming HTML extensions:
hx-sse streams over text/event-stream.hx-ws streams and sends over WebSockets.hx-multipart streams over multipart/mixedFinally, we decided it was time to try our hand at our own small front-end scripting solution that tightly integrates with htmx. hx-live is inspired by Alpine.js, jQuery and hyperscript, and makes front end scripting pleasant and fun. It even supports what we are calling DOM-based, HATEOAS-friendly reactivity.
There is a new htmax.js bundle in the distribution which packages htmx with the most popular of these in a single file if you don’t want to think about which ones you want to pick.
For a complete upgrade guide see What’s New in htmx 4.
As mentioned earlier, we are providing an upgrade tool to help you:
$ npx htmx.org@4.0.0 upgrade-check -- ./templates
File extensions: .html, .php, .js, .ts, .jinja, .jinja2, .j2, .erb, .hbs
Use --ext to add more (e.g. --ext .vue --ext .svelte)
Scanning 1 file(s)...
Found 8 issue(s) in 1 of 1 file(s).
templates/index.html:1: [inheritance] hx-headers needs :inherited suffix (descendant on line 3 has hx-delete) (this looks like a CSRF token; without :inherited the header does not reach child elements and the server rejects the request)
templates/index.html:2: [inheritance] hx-target needs :inherited suffix (descendant on line 3 has hx-delete)
templates/index.html:2: [inheritance] hx-confirm needs :inherited suffix (descendant on line 3 has hx-delete)
templates/index.html:3: [renamed-attr] hx-disable -> rename to hx-ignore (hx-disable now means 'disable during request')
templates/index.html:4: [removed-attr] hx-vars is removed -> use hx-vals with js: prefix
templates/index.html:4: [removed-attr] hx-prompt is removed -> load the hx-prompt extension to keep the same syntax
templates/index.html:9: [old-event] old event name "htmx:afterRequest" -> "htmx:after:request"
templates/index.html:9: [old-api] htmx.addClass() is removed -> use element.classList.add()
We are also shipping an agent skill to assist in upgrading
htmx 4.0 can be installed via a package manager referencing version 4.0.0, or can be linked via a CDN:
<script src="https://unpkg.com/htmx.org@4.0.0/dist/htmx.min.js"></script>
or Downloaded
Like it or not, a lot of people are using LLMs and we are providing the following skills files for LLMs:
htmx-guidance - core htmx skills for developing with htmx 4htmx-debugging - diagnosing htmx issues during devhtmx-extension-authoring - writing and debugging htmx 4 extensionshtmx-upgrade-from-htmx2 - migrating a codebase from htmx 2.x to 4.x(Let’s leave aside if releasing a new version of a library in the LLM era is a good or bad thing!)
We hope you enjoy htmx 4. htmx 2 will continue to be supported indefinitely so don’t feel any pressure to upgrade.
I’d like to thank the following people for all their help with this release:
Wouldn’t be an htmx update without upgrade music: