Thank you, Deno

Ryan Dahl announced last week that the Deno team is joining Cloudflare. The Deno runtime winds down over the next year, JSR keeps running on Cloudflare's infrastructure, & the team's new job, per Cloudflare's post, is merging Deno's celld into workerd.

The announcement came two years to the day after Deno 2 shipped. Bun joined Anthropic ten months ago. The tempting conclusion is that the alternative-runtime experiment is over & Node has won by default. In reality, the ecosystem has gotten the benefits Deno was pushing, just not from Deno itself.

Competition is imperative to a healthy ecosystem

Unfortunately, Deno never really hit critical mass in production; Node is as dominant in 2026 as it was in 2018. What Deno did achieve was to reinvigorate & put pressure on the incumbent, & that pressure didn't only run one way.

Deno started as a clean break. Ryan stood up at JSConf EU in 2018 & listed what he'd do differently from Node: deny-by-default permissions, TypeScript as a first-class input, web-standard APIs on the server, ES modules only, a single executable. And, pointedly, no npm, no package.json & no node_modules. Dependencies were URLs. The slides put it plainly: "There is no need to list dependencies."

A lot of us who'd spent years on npm & Node were skeptical of that last part (not the permissions or the TypeScript, which were obviously good) & said so at the time. We'd been there before, in the hotlinking era, when every page pulled jquery.min.js off somebody else's server & broke when it moved or got compromised. A URL tells you where something was, not what it is. Once you care that the bytes you tested are the bytes you ship, you need an integrity hash & somewhere to record it, & you've reinvented the lockfile. Matteo Collina of the Node TSC said in 2020 that "another left-pad incident is waiting to happen, but this time there is no 'central entity' that can fix it." Some of this skepticism was defensive but happened to be right in the end.

Deno 1.0 shipped in 2020 on the original terms, & then spent the next four years walking them back one piece at a time. First the deps.ts convention, one file that re-exported every URL: a manifest in all but name. Then lock.json, an integrity hash per URL: a lockfile. Then import maps, so you could write bare specifiers again. Deno's own documentation today recommends registries over HTTPS imports because they "can drift to different versions across files" & "trust the serving host." Those were the objections from 2018, restated as guidance.

Then Bun showed up. Bun 0.1 was released in July 2022 with the opposite bet: rebuild the toolchain from scratch for speed, but run existing npm packages, read package.json & act as a drop-in replacement for node. About six weeks later, Deno published "Big Changes Ahead for Deno", announcing npm: specifiers, a commitment to make 80–90% of npm packages work within three months & a new goal of being "the fastest JavaScript runtime." Deno credited user feedback for the shift; the timing suggests Bun was a large part of it. Deno 2, in October 2024, finished the job with full Node & npm compatibility. Four years after launching as the alternative to Node's ecosystem, Deno had become another way to run it.

That was the right call, & it was also an admission that the ecosystem wasn't going to abandon over a decade's worth of dependencies overnight. Cloudflare's workerd, which it open-sourced in 2022, grew its own Node compatibility layer for the same reason: that's where the packages are.

Node ended up needing to respond. Since 2018 it has shipped a global fetch, WebSocket, Web Streams & Web Crypto; a stable test runner & --watch; --env-file & single-executable builds; a stable permission model; type stripping on by default; node:sqlite; & require(esm). Node's contributors (many volunteers) did the hard work to listen & make big changes, & they deserve a ton of credit for it, but I don't think it happens on that timeline without three other runtimes shipping many of these ideas first. A mature open source project rarely lacks good ideas. It lacks urgency, & competitors supply that urgency.

The standards work came out of the same pressure: WinterCG formed in 2022 because several serious runtimes made "what's the minimum common API?" a practical question, & now, as Ecma TC55, it should outlast whichever runtimes consolidate next.

Package managers & registries

For most of its history the JavaScript package ecosystem was a monoculture: one client, one registry, & an API contract informal enough that it stayed effectively undocumented for a decade & a half. Nearly every improvement since came from someone refusing to accept the status quo.

Yarn (2016) insisted installs be deterministic & gave us the lockfile, workspaces & an offline cache; npm 5 shipped package-lock.json the next year. pnpm showed that node_modules didn't have to be hundreds of megabytes of duplicated files. Bun made install fast enough that the incumbents had to revisit their performance. Deno argued you should be able to read a dependency's source before you take it, & while URL imports didn't last, that idea did.

The clearest recent example is install scripts. pnpm & Bun stopped running them by default; vlt never did. The argument had been made inside npm for the entire time I worked there without ever becoming the default. In June of this year, after a run of supply-chain worms, GitHub announced that npm 12 would stop running them by default too. Nothing about the idea changed in those years; enough other package managers shipped it that npm could no longer treat it as radical. The pressure runs in both directions too: we borrowed catalogs from pnpm, & pnpm's namedRegistries borrowed our named-registry aliases.

On the registry side, JSR deserves credit. It made a different set of bets than we did: publish TypeScript source, require ESM, generate docs from code. We disagreed with parts of it & added jsr: support to vlt anyway because our users asked for it. It survives the wind-down because, as far as I can tell, it's cheap to run, its API is documented, & Cloudflare had a reason to keep it alive.

What changes now

The two most popular independent, venture-backed JavaScript runtimes now live inside companies whose business is something else. Jarred Sumner said the Bun team's relationship with the Claude Code team "probably will look similar to the relationship between Google Chrome <> V8," with more independence, & Cloudflare's post makes clear that workerd's roadmap is Cloudflare's. That's how JavaScriptCore & V8 have always been funded, & it's still a change.

Whether a community fork of the Deno runtime emerges will tell us whether the ecosystem values a secure-by-default, standards-first runtime enough to pay for one that isn't attached to a cloud. And celld-into-workerd is new optionality at a layer that has had very little: a self-hostable, open implementation of Workers & Durable Objects, led by Ryan & Bert Belder.

JavaScript has insurance at almost every layer: three production engines, several runtimes, several package managers. When one layer consolidates, as the runtime layer is doing now, the others hold. The churn that makes this possible is also what people complain about most. "JavaScript fatigue" has been a running joke for a decade: a new framework every week, a new bundler every month, & yet another package manager, which, yes, I'm aware I've contributed to. But nobody had to leave Node to get fetch, a permission model or TypeScript without a build step, & nobody has to switch package managers to get install scripts turned off by default anymore. Those things showed up in the tools people were already using because someone else shipped them first & the incumbent had to answer. The projects didn't always win, but the ideas usually did, & end-users collected them either way.

To Ryan, Bert, Bartek & the rest of the Deno team (past & present): your collective efforts have enriched our shared ecosystem. Thank you!

Darcy Clarke
Founder & CEO, vlt