AI AI & Dev — what's actually happening Dev — what's actually happening

DevJavaScriptRuntimes

Bun 2.0, Deno 2.0 and the Runtime Wars Are Actually Interesting Now

For years Node.js had no serious competition. That's no longer true — and the competition is making everything better.

3 min read

I’ve been running Bun in production for four months. Not as an experiment — as the primary runtime for a small but real API service that handles a few thousand requests per day.

Here’s what I can tell you: it’s fast, and the DX is genuinely better, but the ecosystem gaps are still real and will bite you if you’re not careful.

Let me give you the honest picture.

Why this moment matters

For most of JavaScript’s history on the server, Node.js was the only serious option. Ryan Dahl, who created Node, eventually regretted several of its design decisions — enough that he built Deno from scratch to fix them. Then Jarred Sumner looked at Deno and Node and decided to rebuild from scratch again, optimizing for raw speed.

The result is a Cambrian explosion that’s actually healthy for the ecosystem. Competition is forcing Node to move faster. The v22 and v23 releases have been notably more aggressive than anything we saw in the v18-v20 era.

Bun 2.0: what changed

Bun’s big unlocks in 2.0:

The bundler matured. The bun build pipeline is now fast enough and compatible enough that I’ve replaced esbuild in several projects. Not in all — esbuild’s plugin ecosystem is still richer — but for standard TypeScript + JSX bundles, Bun wins on speed.

bun:sqlite is genuinely great. Synchronous, zero-dependency SQLite bindings that are faster than better-known alternatives. For small services that don’t need Postgres, this is a real unlock.

Compatibility improved substantially. The Node.js compatibility layer now handles the vast majority of npm packages without shimming. node:crypto, node:stream, node:fs — mostly solid now.

# Install and run in one command
bun add hono
bun run server.ts
# ~50ms cold start vs ~300ms with ts-node

Deno 2.0: the pivot worked

Deno 2.0 made a bet that I thought was risky: full npm compatibility. The original Deno philosophy rejected npm entirely in favor of URL-based imports.

They blinked. And it was the right call.

Deno 2.0 with npm compatibility means you can use the existing ecosystem while getting Deno’s genuine advantages: built-in TypeScript, built-in formatter/linter, deno.json configuration that actually makes sense, and the permission model that stops scripts from reading your entire filesystem.

The permission model is underrated for security-sensitive contexts. deno run --allow-net=api.stripe.com script.ts — that script can only make network calls to Stripe. Nothing else. That’s a real security primitive that Node doesn’t have.

What Node.js got right in response

Node didn’t sit still:

  • --experimental-strip-types in v22 lets you run TypeScript files directly without a build step (with caveats)
  • The permission model (experimental) mirrors Deno’s approach
  • The built-in test runner (node:test) is now good enough that I’ve stopped reaching for Vitest on simpler projects

My take for 2026

Don’t rewrite your production Node.js apps to Bun or Deno unless you have a specific reason. But for new projects:

  • Bun for APIs and CLIs where raw speed and startup time matter
  • Deno for scripts, automation, and anything where you value the security model or the integrated toolchain
  • Node when ecosystem compatibility is paramount or you’re on a team that doesn’t want to manage unfamiliar tooling

The runtime wars are making JavaScript a better place to live. That’s the story, really.