Loading today’s stories
Build1 distinct publisher3 min readPublished
The rewrite swaps XMLHttpRequest for fetch and folds morphing and streaming into the core. The migration cost sits in your HTML, where attribute inheritance now needs an explicit :inherited suffix.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
The tag choice is the load-bearing decision, and it works by resolution order. An install or CDN link with no version pinned resolves to whatever holds `latest`, and htmx 2 holds it until early 2027 [4][5]. So the default path keeps serving 2.x, and reaching htmx 4 means typing a tag or a version [7]. Gross gives that as the reason directly: non-versioned CDN links would otherwise pull a major upgrade into production applications whose owners never chose it [5].
The work you would be scheduling is in the markup. htmx 2 let an attribute on a parent element reach its descendants automatically, a behavior carried over from intercooler.js and modeled loosely on CSS [8]. htmx 4 makes that opt-in with an `:inherited` suffix, so a parent confirmation becomes `hx-confirm:inherited` if child controls should still receive it [9]. The release calls this the most consequential breaking change, and the failure mode is quiet: miss one and requests, targets and headers change across the app [10].
The upgrade checker is the mitigation. It scans templates and scripts for inheritance issues, renamed or removed attributes, old event names and obsolete APIs [11], and it parses HTML, PHP, Jinja, ERB and Handlebars [12]. Four classes of breakage, five formats [13]. For that coverage to mean anything on your codebase, your htmx attributes have to live in files the scanner can read. Markup assembled in application code, or in a template dialect that is not on that list, is an inheritance audit you do by reading.
History is the change I would model before committing. htmx 2 kept page snapshots in `localStorage`, where DOM mutations made by third-party scripts survived restoration after the code responsible for them was gone [15]. htmx 4 refetches the page on back navigation instead, with a `sessionStorage`-backed extension available if you want local caching [16]. That is a correctness fix paid for in requests, and the bill lands on whatever serves your pages.
The process behind the rewrite is worth reading as engineering. Gross started thinking about htmx 4 while building fixi, and Christian Tanul brought him streaming HTML ideas that gave the request-layer replacement a purpose, according to the release [17]. Gross then recruited Michael West and Alexander Petros, and the group began by porting fixi against the existing htmx test suite, drifting back toward htmx 2 behavior as they hit the reasons for the original decisions [18]. Gross says the behavioral gap between the majors is now relatively small [19]. A rewrite that ends up agreeing with the code it replaced is the good outcome, even if it makes for a duller changelog.
What would justify moving early is streaming. The fetch base is meant to be invisible to application developers while giving extensions a cleaner footing for server-sent events, WebSockets and multipart streaming [20], and the new `<hx-partial>` element lets one response carry several targeted document updates [22]. Morphing, now integrated from West's work on Gross's idiomorph, reconciles returned HTML against the live document rather than replacing a target outright [21]. The rest of the list, including preload and download extensions and the `hx-live` scripting layer, is convenience [23], and convenience does not usually pay for a template-wide attribute audit.
Ranked by verification strength, evidence, and original report placement.
Carson Gross, a Montana State University professor, created the htmx JavaScript library.
Gross released htmx 4.0.0 on August 28 after eight months of work on the library.
htmx 4 replaces the library's XMLHttpRequest-based internals with the browser fetch API, adds built-in morphing and streaming features, and changes several behaviors accumulated since htmx's intercooler.js origins.
htmx 4 is available through package managers and CDNs but will remain under npm's next tag until early 2027.
htmx 2 will retain npm's latest tag because non-versioned CDN links could otherwise pull the major upgrade into production applications without their owners choosing it.
The htmx 4 announcement says htmx 2 will remain supported indefinitely and tells users they should feel no pressure to migrate.
Distinct publishers with included, body-backed reporting in this cluster.
1 article · August 28, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
security
Two Artifactory flaws poisoned metadata, not artifacts, and that was enough to break a shared cache1 distinct publisher
build
A file-copy Allure adapter for Katalon, and the history IDs that make retries useful1 distinct publisher
science
A backdoored litellm release turns every CI job that installed it into a credential incident1 distinct publisher
security
Talos: obfuscated JavaScript is phishing kit plumbing, and beautifiers will not read it for you1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Faithful to one release, checked by no one
Every technical detail here — fetch internals, the :inherited suffix, the event renaming, the history refetch — reaches us through the htmx release notes as relayed by RuntimeWire, which says so at the top. That is strong provenance for what the project intends and weak provenance for how the code behaves in someone else's templates. These are unusually falsifiable claims; they simply haven't been tested outside the project yet.
Shipped, and deliberately not the default
htmx 4 is installable today and is specifically arranged not to arrive by accident: latest still points at htmx 2 and will until early 2027. The 49,000 stars RuntimeWire cites are attention, a caveat the piece makes itself. So uptake reads as 'available and gently discouraged from spreading' — a design choice rather than a failure, and also the reason there is nothing yet to count.
The maintainer is the one downplaying it
Note who is applying the brakes. Gross parks a full internal rewrite under next, promises htmx 2 forever, and tells nobody to hurry; RuntimeWire matches that register instead of reaching for a major-version hook. If anything the calm undersells the blast radius of the inheritance change, which can rewrite requests and headers in HTML that still looks perfectly correct.
Sponsor-funded, and pointed away from urgency
The account rests on an announcement written by the person whose library it is, and RuntimeWire notes that htmx takes GitHub Sponsors money and that Gross once hoped the GitHub accelerator might turn the work into a full-time job. Those incentives usually push toward urgency; here they push the other way, since a small volunteer team would have to absorb the support load of any migration wave. Read the caution as sincere and the credit-sharing as interested.
Solid on what shipped, silent on how it lands
One publisher, one primary source, and a subject where the facts are code that anyone can read: the shape of the release is dependable and its consequences are not. We're confident htmx 4 exists as described and that npm's default hasn't moved. We know nothing about how the migration actually goes — which is the part that will matter to readers by 2027.