On Friday, August 28, the htmx team released version 4.0.0 — eight months of work, a ground-up rework of the library’s internals, the long-promised migration from XMLHttpRequest to the Fetch API. And then they did something almost no one in open source does: they declined to make it the default.
The new version is not marked latest on NPM. Version 2.x will keep that tag until early 2027. The website references 4.0; the package manager does not. If you install htmx today the way most people install htmx — by pasting a script tag and never thinking about it again — you will get the old version. Deliberately.
The stated reason is refreshingly candid. The team does not want to force-upgrade users who rely on non-versioned CDN URLs. Translation: we know you copy-pasted a script tag in 2023 and haven’t opened a changelog since. We’re not going to punish you for it.
The latest Tag Is a Promise
In the NPM ecosystem, latest is the default. It’s what you get when you run npm install htmx without a version. It’s what the CDN serves when you request the unversioned URL. For most projects, shipping a major version means flipping latest to the new release within days, sometimes hours. The breaking changes land, the GitHub issues fill up, and the maintainers point to the migration guide.
htmx is doing the opposite. The 4.0 line will sit on the next tag — a kind of purgatory for releases that exist but don’t want to be found — until some point in early 2027. That’s not a technical decision. It’s a governance one. The team is treating its distribution channel as a contract with people who will never read the announcement, never read the migration guide, and never know there was a version 4.0 at all.
The technical changes are real, and they matter. The fetch() migration enables streaming response bodies. Idiomorph, the DOM-morphing algorithm, is now the default instead of an extension. Attribute inheritance is explicit rather than implicit. Error responses can be routed by status code. These are the things the Hacker News thread will argue about. They are not the interesting part.
The Cost of Inattention
Who are the people the htmx team is protecting? They’re not the ones commenting on the release thread. They’re the developers who added htmx to a Django template in 2023 because a blog post told them to, and who have since moved on to other problems. The library now sits at 47,920 GitHub stars and 152,014 weekly NPM downloads, and was named the most admired front-end tool in the State of JS 2024 results. That’s not a community of people who read release notes. That’s a community of people who have better things to do.
A developer at a mid-sized e-commerce company, reached in a Slack DM, put it plainly: “We have a script tag from 2023. I don’t know what version it pulls. I don’t want to know. I just want it to keep working.”
The htmx team has decided that person is their responsibility. Not a cautionary tale, not a support burden, not someone who should have known better. A user. And the maintainer bears the cost of the user’s inattention.
A Rebuke to ‘Pin Your Versions’
This is the part that should make the open-source world uncomfortable. The standard advice — repeated in every postmortem, every supply-chain security talk, every “lessons learned” thread — is that users should pin their versions. Read the changelog. Review the diff. Take responsibility for your dependencies. It’s good advice. It’s also, for the vast majority of software in production, fiction.
htmx 4.0 is a quiet rebuke to that fiction. The team could have shipped the fetch() migration, flipped latest, and spent the next six months closing issues titled “my site broke.” Instead, they’re eating the cost of their own popularity. They’re keeping a promise they made implicitly, years ago, to people who will never know it was kept.
That’s not the kind of thing that gets a Hacker News comment. It’s not a technical argument. It’s a moral one, and it’s the most interesting thing about htmx 4.0. The library that refuses to upgrade you is making a claim about who owns the breakage when software changes. Most maintainers would rather not think about it. htmx just spent eight months thinking about it, and then shipped the answer.