Compare with Node.js and Deno
Choose a runtime by engine, TypeScript support, package management, permission model, and deployment shape
Last updated on
Answer the selection question first
All three runtimes execute modern JavaScript. The differences that matter are compatibility boundaries, permission models, package ecosystems, and deployment shapes — not "who is faster." Microbenchmark rankings should never drive the decision; your dependency tree, deployment platform, and team experience should.
Capability matrix
| Dimension | Bun | Node.js | Deno |
|---|---|---|---|
| JS engine | JavaScriptCore | V8 | V8 |
| TypeScript execution | Native, zero config | Experimental since 22.6; erasable syntax runs by default since 23.6, enum etc. still need a transform flag | Native, zero config |
| Type checking | Not included; keep tsc | Not included; keep tsc | Built-in deno check |
| Package management | bun install + text bun.lock | npm + package-lock.json (or pnpm/Yarn) | deno add + deno.lock; JSR registry and npm: specifiers |
node_modules | Required | Required | Not by default (global cache) |
| Node API compatibility | Implements most node: APIs and Node-API; verify edges | Native | Deno 2 covers most node: / npm:; verify edges |
| Permission model | No built-in sandbox | Experimental permission model (--allow-fs-read, etc.) | Sandboxed by default with explicit --allow-* / --deny-* |
| Tests | bun test (Jest-style) | node:test | deno test |
| Bundling | bun build | Not built in (esbuild/tsup, etc.) | No general bundler (deno compile targets executables) |
| Single-file executable | bun build --compile | SEA (more steps) | deno compile |
Volatile rows: check primary sources
Node.js TypeScript support and permissions, and Deno's npm compatibility, are all moving fast. Reviewed on 2026-08-02; confirm against the Node.js docs and Deno docs before writing this into a decision record.
Decision paths
| Your constraint | Lean toward |
|---|---|
| Greenfield CLI or internal service wanting one toolchain and native TS | Bun |
| Production system with heavy native addons requiring LTS and maximum compatibility | Node.js |
| Default-deny sandbox, URL imports, minimal edge scripting | Deno |
| Targeting Cloudflare Workers / Deno Deploy style edge platforms | The platform runtime decides, not local preference |
| Existing large repository | Validate in parallel per Migrate from Node.js; don't switch on faith |
Three common misjudgments
- "Bun is Node-compatible, so no testing needed": native addons, edge-case loaders, and diagnostic tooling can all behave differently — verify each.
- "Deno can't use npm packages": Deno 2's
npm:support covers most common packages, but edges need testing just like Bun. - "Node can't run TypeScript": current Node runs erasable type syntax directly; the real question — who runs type checks and production builds — is identical across all three runtimes.
Constraint wording for agents
Runtime: Bun 1.3.14. Do not suggest Deno permission flags or npm-only workflows.
If a dependency is documented Node-only or Deno-only, stop and report before migrating it.Official references: Bun Node.js compatibility, Node.js TypeScript support, Deno runtime.