Thank You, Deno

Ryan Dahl’s Deno team is joining Cloudflare and winding the standalone Deno runtime down over the next year, with the JavaScript Server Registry (JSR) staying live and Deno’s celld being merged into Cloudflare’s workerd. Deno began as a clean break from Node - deny-by-default permissions, TypeScript first-class input, Web-standard server APIs, ES modules only, and URL-based dependencies - but steadily reversed several of those choices (deps.ts, lock.json, import maps) as practical problems emerged. The arrival of Bun, and Bun’s emphasis on speed plus npm compatibility, pushed Deno to embrace npm and Node compatibility too; by Deno 2 the runtime largely ran the existing Node ecosystem. That tug-of-war gave Node urgency to adopt web APIs, a permission model, a stable test runner, type stripping, and other features, while standards work (WinterCG → Ecma TC55) crystallized common server APIs.

Package managers and registries also changed because competitors shipped alternatives: Yarn brought deterministic installs and lockfiles, pnpm reduced node_modules bloat, Bun accelerated installs, and several clients stopped running install scripts by default - an idea npm later adopted. JSR’s different bets (TS source, ESM, doc generation) survive because they’re cheap to run and useful. With major independent runtimes now inside commercial clouds, whether a community fork will preserve a secure-by-default, standards-first runtime remains open, but the ecosystem has already captured Deno’s key ideas. The piece closes by thanking Ryan, Bert, Bartek and the Deno teams for enriching the shared JavaScript ecosystem.