Deno joins Cloudflare and the risk of a JavaScript monoculture

On 9 October, Ryan Dahl announced that the entire Deno team is joining Cloudflare. The weightiest part of the announcement isn’t the deal itself but what comes after: in a year they’ll stop developing the Deno runtime. Kate Holterhoff, from RedMonk, has published an analysis focusing on what this means for the ecosystem: there are fewer and fewer independent JavaScript runtimes, and nearly all of them depend on a browser’s engine.

What changes, concretely

The announcement is quite clear about the timelines:

The team will work on celld, a project built on the Workers programming model and Durable Objects, which Dahl says are a particularly good fit for running AI agents: cheap serverless execution, persistent state and WebSockets.

The Deno Deploy part took me back to my post from earlier this month on Netlify and its Edge Functions. There I explained that, since 2022, those functions had run on an external service that Netlify’s post didn’t name, but which was Deno Deploy, and that Netlify had just moved them to microVMs inside its own network. Eight days later came Deno’s announcement.

What we’re left with

According to RedMonk, without Deno there are two major general-purpose runtimes left, Node.js, from the OpenJS Foundation, and Bun, from Anthropic, plus Cloudflare’s workerd, built mainly for its own platform. What worries Holterhoff is where each one’s engine comes from:

flowchart LR
    A["V8 · Google"] --> N["Node.js"]
    A --> W["workerd"]
    A --> D["Deno"]
    J["JavaScriptCore · Apple"] --> B["Bun"]

Two of the three alternatives to Node now belong to companies whose main business is something else, and three of the four runtimes share Chrome’s engine.

Why it matters

The RedMonk piece makes the case with three ideas I think are well chosen:

• The Internet Explorer 6 precedent. Microsoft released it in 2001, it reached nine out of ten users, and then Microsoft largely stopped working on it. For about five years people coded for one browser’s quirks rather than for standards, until Firefox, Safari and Chrome brought competition back.
• Standards need independent implementations. At TC39 a proposal needs two independent implementations to make it into the standard, because a spec written for a single product ends up describing that product. On the server there’s WinterTC, which defines common APIs so code runs on any runtime. With fewer independent voices, whatever the most widely used runtime does becomes the standard by default.
• Monocultures fail together. Heartbleed, in 2014, affected most of the web because nearly everyone used OpenSSL, and it led to LibreSSL and BoringSSL. A serious bug in V8 would have a similar reach. Diversity doesn’t prevent bugs, but it limits how many people they hit.

What Deno already achieved

There’s one part of the story I think is fair to highlight: Deno never overtook Node, but it pushed it. Many of the ideas Deno launched with are now part of Node: ES modules, fetch(), .ts file support, a built-in test runner and a permission model.

That last one is close to home. This blog is built with Hugo, and Hugo runs Node with --permission, Node’s permission model that follows the idea Deno made popular. With Node 20 the build fails with bad option: --permission, and Hugo’s configuration needs a list of packages allowed to load native modules and spawn processes:

[security.node.permissions]
  allowaddons = ['tailwindcss', 'postcss']
  allowchildprocess = ['tailwindcss', 'postcss']

A tool like Hugo taking it for granted that JavaScript code runs with limited permissions is, to a large extent, a consequence of Deno raising the idea in 2018.

The forks

Deno remains open source, and the announcement itself invites others to carry it on. There are already two attempts:

• Ende shipped its first release in mid-October. It presents itself as a secure runtime for TypeScript, has dropped Node compatibility and keeps Deno as a permanent alias of its global object, so existing projects keep working.
• Dodo has no releases yet and must be built from source. They want to simplify the project’s structure, because Deno’s core is currently spread across several repositories and each change requires publishing several packages, which makes outside contributions very hard.

As RedMonk notes, they show both the community’s energy and the risk: maintaining a JavaScript runtime is a lot of work, and Linux has many companies funding its core, something these projects lack.

My takeaway

A little over a year ago I was writing enthusiastically about Deno 2.4 and the return of deno bundle, and it’s sad to see the runtime come to an end. I understand the decision: a venture-backed company has to deliver a return eventually, and being acquired is one of the likely endings.

For anyone with projects on Deno, there’s a year of runway with security patches and JSR is staying, so there’s no rush, but it’s worth deciding where to go. And for everyone, the practical lesson I take away is to lean as much as possible on standard APIs, fetch, Request, Response, Web Streams or Web Crypto, which work the same in Node, Bun, Deno and Workers. That’s what makes it easiest to switch runtimes when one disappears.

I’ll stick with the line from James Snell, of Cloudflare and Node’s technical steering committee, quoted in the piece: having no choice is never a good thing. It’s worth keeping in mind that RedMonk itself discloses that Cloudflare, Microsoft and Google are clients, but the underlying idea seems right to me: the web got better when several browsers competed, and the server needs the same.

Source: The Web Can’t Afford a JavaScript Runtime Monoculture, Kate Holterhoff, RedMonk, and Deno is joining Cloudflare, Ryan Dahl.