Alan West

Posted on Oct 10 Originally published at blog.authon.dev

Deno Has One Year Left. Node Won Without a Fight.

#discuss #javascript #webdev #node

Deno Deploy has six months left. The Deno runtime has one year of patch releases, and then, in the announcement's own words, "we will end our development of the Deno runtime." The whole team is going to Cloudflare.

Ryan Dahl built Deno in 2018 to fix what he regretted about Node. Node is still here, on v22 on my machine, still running most of the JavaScript world. I think the runtime war is over, and Node won it without ever really having to fight.

What the announcement actually says

The post is Deno is joining Cloudflare, dated October 9, 2026, by Ryan Dahl, with a joint post on the Cloudflare blog co-written with Kenton Varda. Financial terms weren't disclosed.

I read it line by line, because a lot of the takes in the threads were written from the headline. What's confirmed and what isn't:

Product	Status	Timeline
Deno CLI / runtime	Maintenance only: monthly bug-fix and security releases	One more year, then "we will end our development of the Deno runtime"
Deno Deploy	Shutting down. Paying customers get migration help to Workers	Keeps running for six months, then shuts down
JSR	Continues, infrastructure moves to Cloudflare	No end date given
rusty_v8	Continues, with work toward integrating it into workerd	No end date given
Fresh	Not addressed	Not mentioned
Deno KV	Not addressed	Not mentioned
Subhosting	Not addressed beyond the product listing	Not mentioned

On HN, theodorejb quoted the runtime paragraph, and binlog called it "a wild detail to just bury at the bottom." The paragraph ends: "Deno will remain open source, and we welcome others who want to continue its development." So anyone can pick up the code, but after next October nobody is being paid to work on it.

The repos are still MIT and nothing is archived

Open source promises are cheap, so I queried the GitHub API on October 10:

curl -s https://api.github.com/repos/denoland/deno | jq '.license.spdx_id, .archived, .pushed_at'
# "MIT"
# false
# "2026-10-07T13:56:06Z"

denoland/deno: MIT, not archived, latest release v2.9.7 (September 17, 2026). The LICENSE.md header still reads "Copyright 2018-2026 the Deno authors", and its last change was the yearly bump in January.
jsr-io/jsr: MIT, not archived, pushed to on October 10.
denoland/rusty_v8 and denoland/std: both MIT and active.
Fresh: denoland/fresh now redirects to freshframework/fresh. Still MIT, last pushed October 3, latest release 2.3.3 from April 28. The repo already lives outside the denoland org, which may say more about Fresh's future than the announcement does.

Nothing has been relicensed or archived, so if you need to fork, you can.

Node took the Deno ideas people wanted

Deno's pitch was web standards, TypeScript without a build step, secure by default, and no node_modules. Every one of those pushed the ecosystem forward, and Node picked up the parts people wanted. flanbiscuit's HN comment has the dates: the permission model arrived in Node v20 (April 2023), and running .ts files natively works without a flag since v22.18.0. pseudosavant put it bluntly: Deno "was successful for the Node community, but not for Deno the runtime or business."

Deno's biggest concession came earlier, when it added npm compatibility. On Lobsters, simonw linked an HN comment he attributes to Dahl (posted as rough-sea), saying Deno "has been sucked into the gravity well of node compatibility, which forces it to behave exactly as Node does." conartist6, a library author, said that was the moment they gave up on explicitly supporting Deno. If a runtime behaves exactly like Node, you test against Node. Meanwhile Node got to absorb the good ideas at its own pace while Deno spent its energy on compatibility.

What about Bun

Yes, Bun is fast. And conartist6 argues it "was really Bun not Node that was setting the pace." I partly agree: Bun forced Node to care about startup time and built-in tooling.

But Bun is owned by Anthropic now. Per neuronexmachina on HN, 1.4 was a rewrite from Zig to Rust, and commenters argued over whether releases slowed afterward (locknitpicker says the cadence "dropped like a rock", rwz says they "shipped a metric ton of new features in 1.4"). kuekacang asked straight out: "I went all-in with bun. Did I bet wrong?" nateb2022 went back to Node for its native ML-KEM and ML-DSA support.

That leaves neither of the two big alternatives as an independent company trying to replace Node: Deno is becoming part of Workers, and Bun is a tool inside an AI company. Bun can keep winning benchmarks and developer love without getting any closer to replacing Node.

Who actually loses

Deno Deploy customers. You have a six-month clock, and the only supported path is Workers. That's a real migration: different runtime APIs, Durable Objects instead of whatever you were doing, and Cloudflare's pricing model.

Deno KV users. The announcement doesn't mention KV at all. On HN, hoppp listed "Deno.serve, KV etc.." as platform lock-in; brlewis replied that Deno.serve uses the standard Request and Response objects. They're both right. Your HTTP handlers will port in an afternoon. Your KV data model won't, and nobody has told you where it's going.

People who chose Deno for the CLI. You get monthly security patches for a year. After that you're relying on a community fork that doesn't exist yet. hoppp is already proposing one ("Lets fork it into opendeno"), and Lobsters sysop 355E3B pointed to the HashiCorp/IBM deal and the OpenTofu and OpenBao forks as the model for what the community might do next. Maybe, but OpenTofu had a license change to rally around. Deno has an MIT repo and a polite goodbye, which is much harder to organize a fork around.

JSR users are probably fine. It's explicitly staying, on Cloudflare infra. If you publish there, also publish to npm and stop worrying.

Workers itself might come out ahead. manuel on Lobsters, who has used Deno, said "I think CF's workers architecture is very good" and hoped it becomes a serious open source option. Dahl's post says the goal is for the Workers model to be the default way to build servers "whether you run on Cloudflare's network or your own infrastructure", and, per TechCrunch, Deno had already shipped celld, an open-source implementation of Workers. If self-hosted Workers gets good, that's the most interesting result of the whole deal.

What to do this week

If you have anything running on Deno, this is the list I'd work through:

Inventory Deno-only APIs:

   grep -rnE 'Deno\.(openKv|cron|serve|env|readTextFile|Command)' --include='*.ts' .

Deno.serve is easy to replace. Deno.openKv and Deno.cron are where the real migration cost is.

Check your imports. Node rejects both jsr: and npm: specifiers (ERR_UNSUPPORTED_ESM_URL_SCHEME). npm: ones become plain package imports; JSR packages install with npx jsr add and are then imported by bare name. Move what you can.
Run your code on Node 22.18 or later. Type stripping is on by default there, so plenty of small Deno services will run with few changes. One catch I hit on v22.23.3: it only strips types, so a file with an enum fails with a syntax error. Better to find those now than in month five.
If you're on Deno Deploy, pick a date. Six months goes fast. Decide between Workers (supported migration, more lock-in) and Node on a plain container (more work now, less dependence on one vendor later).
Pin your Deno version (v2.9.7 is current) and subscribe to releases so you notice when the monthly patches stop.

I liked Deno

URL imports, permission flags, a real standard library: Deno is the runtime that made me take TypeScript-first tooling seriously. But "Node killer" was always the wrong frame. Deno's ideas won, and most of us ended up using them inside Node.

So I want to hear from people who actually bet on it. If you shipped something on Deno, are you staying on a runtime with a one-year clock, moving to Workers, or going back to Node? And Bun people: tell me why an Anthropic-owned Bun is still a real Node replacement. Bring numbers.

DEV Community