Deno 2.9 nearly doubled its cold start and learned to read Bun's lockfiles

Deno 2.9 shipped today. The release roughly doubles the runtime’s cold start, adds a tool for packaging web apps as native desktop binaries, and quietly makes Deno read the lockfiles of every rival package manager.

That last item is the real story. For most of the runtime war, picking Deno over Node.js or Bun meant re-resolving your entire dependency tree to switch. Deno 2.9 drops the cost of trying it. You can now point Deno at a project that was built for npm or Bun, keep its existing lockfile, and find out in minutes whether it runs. For the millions of developers who write JavaScript and TypeScript but have never seriously tested Deno, that is the change that matters, more than any benchmark.

What’s new

The headline numbers come straight from the Deno team’s announcement, benchmarked against the 2.8 release from earlier this year. Performance is the loudest pitch, but the package-management and Node.js work is what actually lowers the barrier to adoption. Here is what landed:

• Cold start of 17.3ms, down from 34.2ms. That is a 1.98x speedup, with memory use falling from 142MB to 64MB, a 2.2x reduction. Deno.serve throughput climbed to 72.4k requests per second from 56.8k.
• deno install reads foreign lockfiles. It now seeds deno.lock from an existing npm, pnpm, yarn, or Bun lockfile, and migrates pnpm workspaces. The promise in the release notes is blunt: “The versions you were running under npm are the versions you run under Deno.”
• deno desktop, an experimental command, wraps a web app in a webview and the Deno runtime to produce a standalone binary. It auto-detects Next.js, Astro, Fresh, SvelteKit, and several others, and cross-compiles to Linux, Windows, and macOS. It drew its own Hacker News thread before the full release landed.
• Node compatibility moved to 26.3.0. Bare builtins now resolve without flags, so import "fs" maps to node:fs on its own.
• Post-quantum web crypto. The runtime adds ML-KEM, ML-DSA, and SLH-DSA, plus ChaCha20-Poly1305 and the SHA-3 family. The whole crypto.subtle layer was rewritten from JavaScript to Rust to cut per-call overhead.
• Supply-chain defaults tightened. A min-release-age policy is now on by default with a 24-hour window, so a freshly published, possibly compromised package version cannot land in your tree the moment it appears.

What’s still unclear

Deno keeps describing itself as a faster, safer Node, and the Node-compat work is where that bet gets tested. The Hacker News thread on 2.9 ran mixed to sour at 109 points, with several developers reporting regressions after an AI-assisted rewrite of the node:http stack. One commenter put the migration math plainly: “when I run the project using bun, it runs. When I try it using deno, it doesn’t.”

Deno’s Bartek Iwańczuk, who wrote the release post, responded in the thread that the rewrite closed roughly 30 issues and reached about 90% compatibility, while conceding “we just don’t catch everything.” So the open question is not whether Deno is faster. It clearly is. The question is whether 90% is the number that gets a real npm project to switch, when Bun’s whole pitch is that your code already runs.

Two other gaps are worth naming. deno desktop is experimental, and the cloud path for several of its features still leans on a single provider rather than a portable backend, so a binary you build today may need rework as the tooling settles. And Deno.serve now ships with automatic response compression turned off by default, a small behavior change that will surprise anyone who upgrades without reading the notes. Check your response sizes after you bump.

What this means for you

The lockfile reader is the part that changes your day. For two years the JavaScript runtime wars forced a hard choice: commit to Node, Bun, or Deno, then re-resolve your whole dependency tree to move. Deno 2.9 turns that into a softer experiment. Point deno install at an existing project, keep your package.json and your Bun or pnpm lockfile, and see whether it runs, without rewriting anything first.

So treat 2.9 as a trial, not a migration. Spin Deno up on a service you already ship, lean on the 1.98x cold start and the on-by-default supply-chain delay, and watch for the node:http edge cases the thread flagged. If your stack is plain HTTP handlers and standard builtins, the odds are good. If it leans on deep Node internals, wait for the next point release before you bet a production deploy on it.