Node.js vs Deno vs Bun: The 2026 Runtime Comparison

TL;DR

Node.js 22 LTS for production workloads; Bun for new projects where performance matters; Deno for security-first or Deno Deploy use cases. The runtime wars are over — all three are production-capable. Node.js wins on ecosystem completeness and battle-tested stability. Bun wins on raw performance and developer experience. Deno wins on security defaults and integrated tooling. The practical choice: use Bun if you're starting fresh and your team is performance-focused; Node.js 22 if you're risk-averse or have existing Node.js infrastructure.

Key Takeaways

Bun performance: ~3x faster than Node.js on HTTP, ~10x faster installs
Node.js stability: 15+ years, 99%+ npm compat, every hosting platform supports it
Deno 2.0: finally supports npm packages natively — the compatibility gap is closed
Compatibility: Node.js 100%; Bun ~95% (native addons, some edge cases); Deno ~90%
Tooling: Bun has a bundler + test runner + package manager built-in; Deno has all-in-one too

Philosophy Differences

Node.js (2009):
  → C++ + V8 + libuv (async I/O)
  → npm/CommonJS ecosystem from the start
  → Backwards compatibility as a core value
  → "If it worked in v16, it works in v22"
  → Ships without bundler, formatter, test runner — you choose your tools

Deno (2018):
  → TypeScript by default (no config needed)
  → URL-based imports (no node_modules traditionally)
  → Deno 2.0: npm compatibility added, import maps standardized
  → Permission model: explicit grants for file, network, env access
  → Built-in: formatter, linter, test runner, bundler, LSP

Bun (2022):
  → Written in Zig (not C++) — from scratch for speed
  → JavaScriptCore engine (Safari's engine, not V8)
  → Drop-in Node.js replacement goal
  → Built-in: package manager (fastest), bundler, test runner, transpiler
  → Web-first APIs (fetch, WebSocket, etc.) built-in
  → "Everything fast by default"

Performance: The Numbers

# HTTP server benchmark (hello world):
# ApacheBench: 10K requests, concurrency 100

Runtime              req/s    p99 latency   Memory
─────────────────────────────────────────────────────
Bun 1.x (native)   120,000    2.1ms        35MB
Deno 2.0             89,000    2.8ms        42MB
Node.js 22 (uws)     95,000    2.5ms        40MB
Node.js 22 (http)    52,000    3.8ms        45MB
Node.js 22 (express) 28,000    5.2ms        58MB

# File I/O (read 10K files):
Bun:     1.2s  🏆
Deno:    2.1s
Node.js: 2.8s

# Package install (fresh Next.js project, 162 packages):
Bun install:  ~3s   🏆
pnpm install: ~14s
npm install:  ~45s
Deno (npm):   ~12s  (comparable to pnpm)

# Test runner (500 unit tests):
Bun test:   0.8s  🏆
Vitest:     2.1s
Jest:       8.4s
Deno test:  1.9s

# TypeScript transpile (no type-check):
Bun:    ~immediate (native, no separate step)
Deno:   ~immediate (native, no separate step)
Node.js: requires ts-node/tsx/swc/esbuild ~100ms+

Node.js 22: What's New

// 1. require(ESM) — the long-awaited feature
// Node.js 22.12+ LTS: can require() ES modules!
// Previously: ERR_REQUIRE_ESM forced messy workarounds

const esModule = require('./my-esm-module.mjs');
// Works in Node.js 22.12+ without flags
// Huge for: legacy CJS codebases consuming modern ESM-only packages

// 2. Native WebSocket client (no ws package needed)
const ws = new WebSocket('wss://echo.example.com');
ws.onmessage = (event) => console.log(event.data);

// 3. node:sqlite (experimental, Node.js 22.5+)
import { DatabaseSync } from 'node:sqlite';
const db = new DatabaseSync('./data.db');
db.exec('CREATE TABLE IF NOT EXISTS users (id INTEGER, name TEXT)');
const stmt = db.prepare('INSERT INTO users VALUES (?, ?)');
stmt.run(1, 'Alice');

// 4. Glob pattern matching (node:fs)
import { glob } from 'node:fs/promises';
const files = await glob('**/*.ts', { exclude: ['node_modules/**'] });

// 5. V8 12.4: Array.fromAsync, Promise.withResolvers natively supported
const [resolve, reject, promise] = (() => {
  let resolve, reject;
  const promise = new Promise((res, rej) => { resolve = res; reject = rej; });
  return [resolve, reject, promise];
})();
// Now cleaner with:
const { promise: p, resolve: r } = Promise.withResolvers();

Bun 1.x: Production Guide

// Bun is a drop-in replacement for Node.js — most things just work:

// package.json:
{
  "scripts": {
    "dev": "bun run --hot src/index.ts",  // Hot reload
    "build": "bun build src/index.ts --outdir dist",
    "test": "bun test"
  }
}

// Bun-specific APIs (faster than Node.js equivalents):
import { file, write } from 'bun';

// Read file (faster than fs.readFile):
const content = await Bun.file('./data.json').text();
const json = await Bun.file('./data.json').json();

// Write file:
await Bun.write('./output.txt', 'Hello, World!');

// Fast HTTP server:
const server = Bun.serve({
  port: 3000,
  fetch(req) {
    return new Response('Hello!');
  },
});

// Built-in SQLite:
import { Database } from 'bun:sqlite';
const db = new Database('data.db');
const stmt = db.prepare('SELECT * FROM users WHERE id = ?');
const user = stmt.get(1);

// Test runner:
import { test, expect } from 'bun:test';
test('adds numbers', () => {
  expect(1 + 2).toBe(3);
});

// What DOESN'T work in Bun:
// → Native addons (.node files) — most packages use JS fallbacks anyway
// → worker_threads (limited) — Bun has its own Worker API
// → Some Node.js core module internals (rare edge cases)
// → vm module (partially implemented)

Deno 2.0: The npm Compatible Version

// Deno 2.0 added npm compatibility — the biggest Deno change since launch

// deno.json (replaces package.json):
{
  "imports": {
    "hono": "npm:hono@^4",
    "zod": "npm:zod@^3",
    "@/": "./src/"
  },
  "tasks": {
    "dev": "deno run --watch src/main.ts",
    "test": "deno test"
  }
}

// Or use bare npm specifiers:
import { Hono } from 'npm:hono';
import { z } from 'npm:zod';

// Deno's security model — explicit permissions:
// deno run --allow-net --allow-read --allow-env src/main.ts
// No permissions = no access (reverse of Node.js)

// Run with all permissions (development convenience):
deno run -A src/main.ts

// Deno native APIs (TypeScript by default, no config):
const text = await Deno.readTextFile('./data.txt');
const data = JSON.parse(text);
await Deno.writeTextFile('./output.txt', JSON.stringify(data, null, 2));

// Deno Deploy — edge deployment:
// Same code, deployed to Deno's global edge network
// Free tier available, auto-scales
// Best for: API routes, simple backends, edge functions

// When Deno makes sense:
// → Security is a top priority (fintech, healthcare)
// → Team values integrated tooling (no eslint/prettier/jest setup)
// → Deploying to Deno Deploy
// → New greenfield TypeScript project where ecosystem lock-in is not a concern

Choosing Your Runtime

Node.js 22 LTS:
→ Existing Node.js codebase: stay, upgrade to 22
→ Native addons required (node-gyp packages): Node.js only
→ Maximum hosting compatibility (AWS Lambda, GCP, Azure, etc.)
→ Team without Bun/Deno experience: Node.js has the best docs/answers
→ Enterprise with strict LTS requirements
→ Next.js, Remix, or other frameworks with Node.js-specific optimizations

Bun 1.x:
→ New project where performance is a priority
→ APIs and backends that need to handle high throughput
→ Developer experience matters: fast installs, fast tests, zero-config TS
→ Team willing to hit occasional compatibility issues (rare, solvable)
→ Cloudflare Workers deployment (compatible with Bun APIs)
→ "I want the fastest possible development loop"

Deno 2.0:
→ Security-sensitive applications (permission model is genuinely useful)
→ Deploying to Deno Deploy
→ Projects that want all tooling built-in (no package.json scripts madness)
→ Node.js replacement where npm compatibility is needed (Deno 2.0 handles this)
→ Edge-first TypeScript APIs

The verdict (2026):
→ New project: Bun or Node.js 22 (Bun if DX matters, Node.js if risk-averse)
→ Performance-critical backend: Bun
→ Security-critical: Deno
→ Existing Node.js app: Stay, upgrade to Node.js 22
→ "I just want it to work": Node.js 22 — maximum ecosystem, no surprises

The Engine Difference: V8 vs JavaScriptCore

Node.js and Deno both use Google's V8 JavaScript engine — the same engine that powers Chrome. Bun uses JavaScriptCore (JSC), the engine that powers Safari. This is not a trivial implementation detail. V8 and JSC use different JIT compilation strategies, different garbage collection algorithms, and different optimization heuristics. For most JavaScript workloads, the performance difference is small and workload-dependent. For Bun's specific use cases — server startup, file I/O, HTTP handling — the JSC choice plus Bun's Zig implementation of its core runtime produces measurably better performance than Node.js's V8-based implementation.

One practical implication of the engine difference: some JavaScript behavior that is technically undefined by the ECMAScript specification behaves differently between V8 and JSC. Object property enumeration order, precise garbage collection timing, and some edge cases in regular expression behavior can differ. In practice, well-written JavaScript that follows the spec works identically. The risk is in code that depends on V8-specific behavior that happens to work in V8 but is not part of the ECMAScript standard. Most npm packages are written to spec, but native addons (.node binary files compiled against Node.js's V8) are fundamentally incompatible with Bun.

The CommonJS and ESM Transition

All three runtimes support both CommonJS (require()) and ES Modules (import/export), but their handling of the transition between formats differs in important ways that affect compatibility. Node.js's approach has historically been conservative: .js files default to CommonJS, .mjs files are ESM, and you must set "type": "module" in package.json to make .js files default to ESM. Node.js 22.12+ added the ability to require() ES modules, which closes a major long-standing compatibility gap for CJS codebases consuming ESM-only packages.

Bun is more aggressive about format compatibility — it handles require() and import in the same file and generally figures out the right module format based on the package's package.json. This makes it easier to use ESM-only packages in Bun even in projects that haven't fully migrated to ESM. Deno requires explicit ESM everywhere — there is no require() in Deno's native module system, though the npm compatibility layer handles CJS packages transparently when using npm: specifiers.

Deployment Infrastructure Reality

The ecosystem around deployment infrastructure is one area where Node.js's fifteen-year headstart is most visible. AWS Lambda, Google Cloud Functions, Azure Functions, and Heroku all have Node.js runtime support as a first-class offering with specific LTS version support, extension mechanisms, and managed lifecycle. Adding a Node.js 22 Lambda function is a one-click operation in the AWS console. Adding a Bun Lambda function requires a custom runtime layer — technically straightforward but requires maintaining the layer as Bun updates.

Vercel and Netlify now have native Bun support as a build environment option, recognizing that Bun's faster install times meaningfully reduce CI minutes consumed during build. Cloudflare Workers use a different model entirely — the Workers runtime is neither Node.js, Bun, nor Deno, but a V8 isolate environment that the Workers team controls. Deno Deploy is Deno's own edge network, well-integrated with Deno's tooling but a separate infrastructure choice.

For teams deploying to standard cloud providers in 2026, Node.js remains the lowest-friction choice. For teams deploying to Vercel, Bun is a viable and increasingly common choice. For teams deploying to Deno Deploy, Deno is the natural fit. The deployment target should inform the runtime choice as much as language features do.

TypeScript Integration Differences

All three runtimes run TypeScript, but the mechanism and implications differ. Node.js requires an explicit transpilation step — either using a build tool (esbuild, swc, tsc) or a dev tool that handles transpilation at runtime (tsx, ts-node). For production Node.js applications, the standard approach is to compile TypeScript to JavaScript in a build step and run the compiled output. This adds tooling complexity but is the most predictable and debuggable approach.

Bun strips TypeScript types at runtime using its own type-stripping implementation. This is fast (no separate compilation step) and simple (run bun index.ts directly), but it does not do type checking — it only removes the type annotations. You still need tsc --noEmit or TypeScript in your editor for actual type checking. Deno has the same approach: TypeScript types are stripped, not checked, at runtime. Both recommend running tsc --noEmit in CI to catch type errors separately from the runtime execution.

The practical implication: for development, Bun and Deno's native TypeScript support means faster iteration (no build step). For production, all three require the same discipline around type-checking in CI. The difference is in the developer experience loop, where Bun and Deno's "run TypeScript directly" approach is meaningfully faster than Node.js's "compile then run" cycle.

Security Model Comparison

Deno's permission model is the most explicit of the three: every capability (network access, file system access, environment variables, subprocess execution) must be explicitly granted via command-line flags or a deno.json permissions configuration. This model, inspired by browser security, makes it impossible for a malicious or buggy package to silently exfiltrate data or write to unexpected filesystem locations — it would fail with a permission error.

Node.js historically had no permission model at all — any package could read the filesystem, make network requests, and execute subprocesses. Node.js 20+ introduced an experimental permission model (--experimental-permission), but it is not yet production-recommended and requires explicit opt-in per process. Bun similarly does not implement a permission model by default, though Bun's Zig-based implementation does enforce certain OS-level sandbox behaviors on macOS.

For security-sensitive applications — financial services APIs, healthcare data processors, authentication services — Deno's permission model provides a meaningful additional layer of defense against supply chain attacks via compromised npm packages. The cost is operational complexity: every script invocation needs appropriate flags, and automated deployment scripts need to enumerate permissions explicitly. Teams that have adopted Deno in security-sensitive contexts report that the initial permission configuration is the barrier, but ongoing maintenance is manageable because permission requirements rarely change once established.

Package Management and Lock File Compatibility

npm's package.json and lock file format became the universal standard for JavaScript dependency management, and all three runtimes support it to varying degrees. Node.js with npm (or pnpm, or yarn) is the native target for package.json. Bun reads package.json natively and uses its own bun.lockb lock file (a binary format that is faster to read and write than npm's JSON lock file). However, bun.lockb is not human-readable and cannot be diffed meaningfully in pull requests — teams on Bun use bun install --frozen-lockfile in CI to prevent unexpected changes.

Deno 2.0 supports both its own deno.lock lock file and npm compatibility through package.json imports. A Deno project can have a package.json with npm dependencies that Deno manages using its own implementation of npm package resolution, storing packages in Deno's global cache rather than a local node_modules directory. The practical implication is that Deno projects don't have a node_modules directory — packages are cached globally — which is cleaner but means some npm-specific tooling (editors that scan node_modules for type definitions, for instance) needs adjustment.

Compare Node.js, Bun, Deno and other JavaScript runtime download trends at PkgPulse.

The 2026 JavaScript Stack Cheatsheet