--- title: HTMX 4.0.0 released: what changed and what's new | daily.dev description: HTMX 4.0.0 launched on August 28, 2026 with major breaking changes: attribute inheritance is now explicit via the :inherited suffix, event names follow a new... canonical: https://daily.dev/posts/htmx-4-0-0-released-what-changed-and-what-s-new-stp97vuxo twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: HTMX 4.0.0 released: what changed and what's new | daily.dev og:description: HTMX 4.0.0 launched on August 28, 2026 with major breaking changes: attribute inheritance is now explicit via the :inherited suffix, event names follow a new... og:url: https://daily.dev/posts/htmx-4-0-0-released-what-changed-and-what-s-new-stp97vuxo og:image: https://api.daily.dev/og/posts/sTp97VUxO.png og:image:alt: HTMX 4.0.0 released: what changed and what's new og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # HTMX 4.0.0 released: what changed and what's new **[Collections](https://daily.dev/sources/collections)** · 2 min read · 2 upvotes · 0 comments ## Summary HTMX 4.0.0 launched on August 28, 2026 with major breaking changes: attribute inheritance is now explicit via the :inherited suffix, event names follow a new htmx:phase:action pattern, back navigation re-fetches pages instead of restoring DOM snapshots, and 4xx/5xx responses are swapped into the DOM by default. Internally, fetch() replaces XMLHttpRequest. New features include built-in innerMorph/outerMorph swaps, the element, and extensions like hx-preload, hx-sse, hx-ws, and hx-multipart. Migration aids include an htmx-2-compat extension, a CLI upgrade checker, and LLM skills files. npm's latest tag stays on htmx 2.x until early 2027, with htmx 2 supported indefinitely. ## Content htmx 4.0.0 shipped on August 28, 2026, after eight months of development. The headline change is a full internal rewrite from XMLHttpRequest to the native fetch API, which opens the door to streaming, SSE, and WebSocket support that XHR couldn't handle cleanly. ## What's changed Three behavioral changes break from htmx 2.x defaults: - **Attribute inheritance is now explicit.** Attributes no longer propagate implicitly to child elements. You have to opt in with the `:inherited` suffix. - **Event names follow a new pattern.** All events now use `htmx:phase:action` naming for consistency. - **History navigation re-fetches pages.** The old approach of restoring DOM snapshots from localStorage is gone by default. Back navigation now triggers a fresh request. Also worth noting: error responses (4xx/5xx) are now swapped into the DOM by default instead of being silently ignored. ## New features - **Built-in morph swaps** via an improved idiomorph algorithm (`innerMorph` and `outerMorph`), which preserve DOM state during updates. - **``**, a new tag for flexible multi-target updates, similar to out-of-band swaps but cleaner. - **New extensions**: `hx-preload`, `hx-download`, `hx-alpine-compat`, `hx-history-cache`, plus streaming extensions `hx-sse`, `hx-ws`, and `hx-multipart`. - **`hx-live`**, a new front-end scripting extension. - **`htmax.js`** bundle for those who want everything in one file. ## Migration The team ships an `htmx-2-compat` extension for gradual migration and an official `upgrade-check` CLI tool to flag breaking changes in existing codebases. There are also LLM skills files to help automate the migration. If you're not ready to move yet: htmx 2 keeps the `latest` tag on npm until early 2027, and the team says it will be supported indefinitely. htmx 4 is currently under the `next` tag. The team is framing this as infrastructure built to last decades, which is either admirable or ambitious depending on how you feel about that kind of claim. Either way, the fetch rewrite and morph swaps are genuinely useful additions. ## Questions this post answers ### What breaking changes does htmx 4.0.0 introduce compared to htmx 2? htmx 4.0.0 introduces three breaking changes: attribute inheritance is no longer implicit and requires an explicit `:inherited` suffix, event names follow a new `htmx:phase:action` naming pattern, and back navigation now re-fetches pages instead of restoring DOM snapshots from localStorage. Error responses (4xx/5xx) are also now swapped into the DOM by default instead of being ignored. _Teams planning an htmx 2 to 4 migration can track breaking changes like these on daily.dev._ ### How do I migrate an existing htmx 2 project to htmx 4? Use the official htmx-2-compat extension for a gradual transition, along with the upgrade-check CLI tool that flags breaking changes in an existing codebase. LLM skills files are also provided to help automate parts of the migration. htmx 2 stays on npm's latest tag until early 2027 and will remain supported indefinitely, so migration isn't urgent. _daily.dev helps developers weighing framework migrations like htmx 2 to 4 stay on top of tooling updates._ ### Why did htmx 4.0.0 switch from XMLHttpRequest to the fetch API? The switch to fetch was made to enable streaming, server-sent events (SSE), and WebSocket support, which XMLHttpRequest couldn't handle cleanly. This fetch-based rewrite is the headline architectural change in htmx 4.0.0, released August 28, 2026, after eight months of development, and underlies new extensions like hx-sse, hx-ws, and hx-multipart. _Developers evaluating htmx's new streaming capabilities can follow architecture changes like this on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 2 discussions and 190 comments across lobsters, hackernews (as of 2026-09-13). **TL;DR:** The release lands to a generally warm but joking reception, with substantive threads about whether htmx still matters in an LLM-assisted coding world, how well it scales to complex apps, and lighthearted riffing on the project's quirky community persona. **Sentiment:** 40% positive · 40% mixed · 20% skeptical **The case for** - Many report htmx plus a simple backend (Go/Django/Rails + SQLite/Postgres) as a productive, low-friction stack, especially with LLM coding assistants that handle it well. - Some argue LLMs will boost htmx adoption since models are also good at writing accompanying web components/JS glue. - Commenters appreciate the project's informal, non-corporate personality and long-running inside jokes. - One long-time user with production experience describes htmx's targeting/locality-of-behaviour approach and workarounds (custom events, response headers) as manageable with discipline. **The pushback** - Several worry that LLMs generating JavaScript on demand erodes htmx's original value proposition of avoiding hand-written JS. - Some report moving away from htmx back to React/Angular for more complex, stateful apps, finding server-side state management unpleasant. - Target/ID drift when swapping elements is flagged as a real pain point with no compile-time safety net. - A few practical complaints: broken anchor navigation, a broken game page, and mismatched release artwork (borrowed from Omarchy). **By community** - lobsters (mixed): Discussion centers on a substantive technical question about ID/target drift in htmx apps, with detailed, largely constructive answers, plus a side gripe about excessive LLM usage in the release process. - hackernews (mixed): A big, sprawling thread mixing genuine enthusiasm and stack-sharing with a running debate about htmx's relevance in the LLM era, some site bugs, and a lot of running jokes about who is 'CEO of HTMX.' **Hottest debate:** Whether LLMs that can now write JavaScript on demand undermine htmx's core reason for existing, or will instead boost its adoption. **Open questions** - How well will htmx's new explicit attribute-inheritance model and other breaking changes be understood by LLMs trained on older conventions? - How does the new hx-live scripting extension compare in practice to Alpine.js? - Is there a reliable way to prevent target/ID drift in larger htmx codebases beyond discipline and tests? **Highlights** > I can provide a comment from my own experience, having used HTMX for some years while also having spent many years using React. Target drift is indeed a problem that can occur. HTMX is not compiled so there are no automated checks. Tests can go a long way to cover this issue but you're still at the mercy of discipline and exhaustiveness. However, there are aspects of how HTMX is meant to be used that should further clarify your question. Targeting by id is [not the only way to target elements](https://four.htmx.org/docs#targeting-with-extended-selectors). In the context of swapping DOM elements that are close to the trigger, I'd reach for other selectors like `find`, `closest`, `this`, etc than an id. Nonetheless, the elements behind these selectors can also change so you still have target drift. HTMX argues _for_ an implementation designed around [locality of behaviour](https://htmx.org/essays/locality-of-behaviour/), meaning you'd implement an interaction such that you can see right away how things work out. Yet, this is somewhat contingent on the affordances that your server has for generating and returning markup. For things that need updating beyond that locality, and disregarding out-of-band-swaps (which are bound to target drift too), I've turned to using [custom events](https://four.htmx.org/reference/attributes/hx-trigger#custom-events) or [response headers](https://four.htmx.org/docs#response-headers) to handle cascading effects. Obviously, this is way different to the reactivity model that React and others use. HTMX is not that and you'll be disappointed if that's your expectation. I like HTMX for certain projects and use reactive libraries instead where it makes sense. These are not mutually exclusive either; you can delegate interactions/elements that require more reactivity to a reactive library and communicate over events. That being said, my experience working with developers who only know React or the reactive model is that they'll find it difficult and counter intuitive to use HTMX, and even more so to combine it surgically with a reactive library / plain Javascript where necessary. In a project in which I participated Vue was added progressively until we ended up moving everything over to it when requirements for reactivity where such that it made sense to do so. The rest of the team was overjoyed when HTMX was removed, though HTMX did a great job to carry the project up for over a year while the product found product/market fit and now had enough traction to justify growing the team. > — [ggpsv on lobsters · 3 points](https://lobste.rs/s/77uge9/htmx_4_0_0_has_been_released#c_bgwaak) > I mean, as someone who uses htmx, three parts to that answer: 1. I don't use htmx for massive sprawling interactive apps. It's not a good fit for that. So I don't know this has ever actually come up. 2. But I also don't really use IDs unless I'm replacing several thing at once. You can always just target `this` or things like `closest .classNameHere` and equivalents, in which case this doesn't apply. 3. And to the extent that it _would_ apply, in any large-enough code base, I almost always have linters to prevent this kind of thing for CSS reasons (at least if I'm not using something like BEM or SMACCS or whatever the hotness is right now). tl;dr: if you're doing something big enough where this would actually suddenly be A Thing, I personally would _really_ say it's time to look at Svelte or React (or maybe [Unpoly](https://unpoly.com/) if you're really set on a mostly-static approach). I think htmx is great at its niche, which is basically _web sites with interactive bits_. I don't think htmx is great for complex interactive _apps_, and IMVHO you're gonna have a bad time trying to shoehorn it into that world. > — [gecko on lobsters · 2 points, 1 comments](https://lobste.rs/s/77uge9/htmx_4_0_0_has_been_released#c_a0flf8) > There's definitely something to this: I expect LLMs to hurt the adoption of htmx and most smaller web libraries. That's fine: it's always been a labor of love and is BSD 0, so I hope the ideas are interesting and that the people who decide to use it enjoy it. > — [recursivedoubts on hackernews · 3 comments](https://news.ycombinator.com/item?id=49481406) > I think, at least for the next few years, certain preferences and consensuses were accidentally embedded in the models to your benefit. They love htmx! Claude will independently suggest using it instead of more general js frameworks for smaller projects. A gpt model told me, and I wrote this down because it was striking, "htmx won the argument it was making." It's the same thing with rust. I'm an ocaml expert and ocaml genuinely fits a lot of the problems I work with better regardless of that. But because of when the models were trained and what they were trained on, a certain sort of alt-consensus opinion is frozen into them, and it believes rust is a better choice for nearly everything! I think you're good for the next few years at least. It's an open question what happens after that dead internet theory recursive loop of llms trained on llm output etc so who knows you might be good forever. > — [giraffe\_lady on hackernews · 2 comments](https://news.ycombinator.com/item?id=49482127) > Maybe a contrarian view, but as someone very knowledgeable about .NET API backends + angular on the frontend, I've found that HTMX made things more difficult as it required me to move back to mixing presentation concerns with business-logic and data concerns (basically have the backend produce the UI, which is whole point of HTMX). This is not a criticism but I suspect that the people enjoying HTMX are either people preferring old-school server-side rendering or react users. Just sharing my experience, because HTMX is the absolute darling of hacker news. Since i mainly develop real SPA, i found that is more complex than just using typscrpit if you build something non-trivial as managing state on the server is not fun at all. In my opinion if you are happy using angular, you'll find that HTMX is a step backward in terms for dev experience. Can't speak about react, but since it is not a battery included stack unlike Angular, i can understand why many people find they'd be better off moving things server-side instead of messing around with 15 third-party libraries. My 2 cents > — [rednb on hackernews · 4 comments](https://news.ycombinator.com/item?id=49484694) > I'll shill datastar for a second, there's barely a notion of frontend state management if you treat HTML as a projection surface with interactivity. I'd argue HTML is the most efficient wire format for interactive web apps, especially with streaming + compression. Seriously DB->json->client->toHtml DB->toHtml->client Just imagine if that html wire format also conveyed the interactivity too and you eliminate the issues. And you can always seperate whatever concerns you want in whatever tpl lang of your choice. Also htmx 4 is kinda just an worse datastar funnily enough In it's own way. > — [fatplexer on hackernews](https://news.ycombinator.com/item?id=49485455) **Source threads** - [lobsters](https://lobste.rs/s/77uge9/htmx_4_0_0_has_been_released) · 34 points · 11 comments - [hackernews](https://news.ycombinator.com/item?id=49478178) · 277 points · 179 comments ## Similar posts on daily.dev - [HTMX 4.0: Hypermedia finds a new gear](https://daily.dev/posts/htmx-4-0-hypermedia-finds-a-new-gear-swv18ajzs) · InfoWorld · 119 upvotes · 4 comments --- Tags: [#webdev](https://daily.dev/tags/webdev), [#htmx](https://daily.dev/tags/htmx) [View this post on daily.dev](https://daily.dev/posts/htmx-4-0-0-released-what-changed-and-what-s-new-stp97vuxo) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"HTMX 4.0.0 released: what changed and what's new","url":"https://daily.dev/posts/htmx-4-0-0-released-what-changed-and-what-s-new-stp97vuxo","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/htmx-4-0-0-released-what-changed-and-what-s-new-stp97vuxo"},"datePublished":"2026-08-29T07:20:23.244Z","dateModified":"2026-09-13T19:31:41.424Z","description":"HTMX 4.0.0 launched on August 28, 2026 with major breaking changes: attribute inheritance is now explicit via the :inherited suffix, event names follow a new...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/0a0111a090aaced8a57edc2bae4e38a2?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/0a0111a090aaced8a57edc2bae4e38a2?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Collections","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Collections","logo":"https://media.daily.dev/image/upload/s--fk_6ycEi--/f_auto,q_auto/v1780996001/logos/collections?_a=BAMAMiWQ0","url":"https://daily.dev/sources/collections"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/htmx-4-0-0-released-what-changed-and-what-s-new-stp97vuxo","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":2},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"webdev,htmx","timeRequired":"PT2M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Collections","item":"https://daily.dev/sources/collections"},{"@type":"ListItem","position":3,"name":"HTMX 4.0.0 released: what changed and what's new"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/htmx-4-0-0-released-what-changed-and-what-s-new-stp97vuxo#faq","mainEntity":[{"@type":"Question","name":"What breaking changes does htmx 4.0.0 introduce compared to htmx 2?","acceptedAnswer":{"@type":"Answer","text":"htmx 4.0.0 introduces three breaking changes: attribute inheritance is no longer implicit and requires an explicit `:inherited` suffix, event names follow a new `htmx:phase:action` naming pattern, and back navigation now re-fetches pages instead of restoring DOM snapshots from localStorage. Error responses (4xx/5xx) are also now swapped into the DOM by default instead of being ignored. Teams planning an htmx 2 to 4 migration can track breaking changes like these on daily.dev."}},{"@type":"Question","name":"How do I migrate an existing htmx 2 project to htmx 4?","acceptedAnswer":{"@type":"Answer","text":"Use the official htmx-2-compat extension for a gradual transition, along with the upgrade-check CLI tool that flags breaking changes in an existing codebase. LLM skills files are also provided to help automate parts of the migration. htmx 2 stays on npm's latest tag until early 2027 and will remain supported indefinitely, so migration isn't urgent. daily.dev helps developers weighing framework migrations like htmx 2 to 4 stay on top of tooling updates."}},{"@type":"Question","name":"Why did htmx 4.0.0 switch from XMLHttpRequest to the fetch API?","acceptedAnswer":{"@type":"Answer","text":"The switch to fetch was made to enable streaming, server-sent events (SSE), and WebSocket support, which XMLHttpRequest couldn't handle cleanly. This fetch-based rewrite is the headline architectural change in htmx 4.0.0, released August 28, 2026, after eight months of development, and underlies new extensions like hx-sse, hx-ws, and hx-multipart. Developers evaluating htmx's new streaming capabilities can follow architecture changes like this on daily.dev."}}]} ```