Deno 2 vs Bun vs Node.js 22: Server Runtimes Compared 2026

A year ago, the JavaScript runtime conversation was mostly about whether Bun was stable enough for production. That question has been answered (yes, with caveats), and the landscape has shifted again. Deno 2 shipped a fundamentally different compatibility story. Node.js 22 landed native TypeScript stripping and require(esm) support. Bun pushed past 1.1 with improved Node.js API coverage and a more reliable bundler. All three runtimes made genuine progress, and the decision matrix has changed because of it.

This is not a rehash of our earlier runtime comparison. That piece covered the broad strokes. This one zooms into what Deno 2, Bun 1.2+, and Node.js 22 each bring to the table right now, with updated benchmarks, compatibility data, and opinionated recommendations based on projects we have shipped in the last six months at Kanopy.

The short version: Node.js 22 is still the safest production choice. Bun is the fastest developer tooling experience. Deno 2 is the best option when security and standards compliance are priorities. But the details matter, and the right pick depends on what you are actually building.

Deno 2 represents the biggest philosophical shift in the project's history. When Ryan Dahl launched Deno in 2018, the pitch was a clean break from Node.js: no node_modules, no package.json, URL-based imports, and a permissions-first security model. It was principled and forward-looking, but it also meant that Deno could not run the vast majority of existing JavaScript libraries. Deno 2 fixed that without abandoning what made Deno different in the first place.

Full npm and package.json Support

Deno 2 reads package.json files natively. You can run deno install to resolve npm dependencies into a node_modules directory, or you can use the npm: specifier to import packages inline without a package.json at all. Both approaches work, and they can coexist in the same project. This is not a thin compatibility shim. Deno 2 implements the Node.js module resolution algorithm, supports nested dependencies, handles peer dependencies, and runs postinstall scripts.

In practice, this means you can take a Node.js project with a package.json, change your start command from node to deno, and there is a realistic chance it runs on the first try. We migrated an internal Express API from Node.js to Deno 2, and the only change needed was adding --allow-net --allow-read --allow-env flags to the start command.

The Security Model Stays Intact

The permission system remains Deno's killer feature. Even with full npm compatibility, every package still runs inside Deno's permission sandbox. If a compromised npm dependency tries to access the file system or make network requests it should not, the runtime blocks it unless you explicitly granted that permission. No other JavaScript runtime offers this level of protection by default. For teams building in regulated industries or handling sensitive user data, this alone can justify choosing Deno 2.

Standards-First APIs

Deno 2 continues to prioritize Web Standard APIs. Fetch, Web Streams, Web Crypto, and AbortController all work identically to their browser counterparts. The standard library (jsr:@std) covers HTTP servers, file utilities, testing, and path manipulation without pulling in npm packages.

Bun's value proposition has not changed since launch: be the fastest JavaScript runtime and eliminate the need for separate tooling. What has changed is the depth of that tooling and the reliability of the runtime under production workloads.

3-4x Faster Cold Starts Than Node.js

Bun starts in 5 to 10 milliseconds. Node.js 22 starts in 30 to 50 milliseconds. Deno 2 falls in between at 20 to 30 milliseconds. For long-running servers, nobody cares about a 40ms difference. But for serverless functions, CLI tools, and scripts that run hundreds of times per day, this adds up fast. A team running 200 serverless invocations per minute saves real compute cost when each cold start is 30ms shorter.

The speed comes from Bun's use of JavaScriptCore (the engine behind Safari's JavaScript execution) combined with a runtime layer written in Zig. Where Node.js relies on V8 with C++ bindings through libuv, and Deno uses V8 with Rust bindings through Tokio, Bun's Zig-based architecture avoids the overhead of those abstraction layers for many operations.

Bundler, Test Runner, Package Manager: All Built In

Running bun install resolves npm dependencies 3 to 5x faster than npm and consistently faster than pnpm. The built-in bundler (bun build) handles TypeScript, JSX, tree-shaking, and code splitting without Webpack, esbuild, or Rollup. The test runner (bun test) is Jest-compatible, supports describe/it/expect patterns, mocking, and snapshot testing, and runs 5 to 10x faster than Jest because it avoids Jest's heavy startup overhead.

This consolidation matters for team productivity. Instead of configuring five separate tools (runtime, package manager, bundler, test runner, TypeScript compiler), you configure one. The cognitive overhead drops. The number of configuration files drops. The "works on my machine" problems drop because everyone is using the same integrated toolchain.

Where Bun Still Has Rough Edges

Bun is not perfect. Some Node.js APIs are implemented partially or behave slightly differently. The node:cluster module, for example, does not work the same way. Certain native addons that depend on V8 internals fail because Bun uses JavaScriptCore. And while Bun's HTTP server is extremely fast for simple workloads, complex middleware chains built for Node.js sometimes expose subtle compatibility differences.

Stability has improved significantly since the 1.0 release, but we still encounter occasional edge cases in production that would not happen on Node.js. For most web applications and APIs, these issues are rare enough to be manageable. For mission-critical systems that cannot tolerate any runtime surprises, Node.js remains the safer bet.

Node.js does not generate the same excitement as Bun or Deno. There are no viral launch videos or 10x speed claims. But Node.js 22 shipped two features that address the biggest pain points developers have complained about for years, and it did so without breaking a single existing application.

Native TypeScript via --experimental-strip-types

Node.js 22 introduced --experimental-strip-types, which lets you run TypeScript files directly with the node command. The implementation strips type annotations at load time using a fast SWC-based transform, leaving valid JavaScript that V8 executes normally. No tsc compilation step. No ts-node. No tsx wrapper. Just node --experimental-strip-types myfile.ts and it runs.

The limitation is that it only strips types. It does not support TypeScript features that require code transformation: enums, namespaces, parameter decorators, and const enum all fail. For teams that avoid those features (which is increasingly common in modern TypeScript codebases), this works well enough for development and scripts. For production builds, most teams will still use a proper compilation step, but the development feedback loop gets noticeably faster.

require(esm): The Interop Problem Finally Solved

For years, mixing CommonJS and ES modules in Node.js was a frustrating experience. Libraries published as ESM-only could not be require()-d from CommonJS code, forcing teams into awkward dynamic import workarounds or complete migrations to ESM. Node.js 22 added support for require() of ES modules, which means CommonJS code can synchronously load ESM packages without modification.

This removes one of the most common migration blockers for large Node.js codebases. Teams stuck on CommonJS because one critical dependency was ESM-only can now upgrade incrementally instead of rewriting their entire import system.

V8 12.4 and Performance Improvements

Node.js 22 ships with V8 12.4, which includes Maglev (a mid-tier optimizing compiler) and improvements to the garbage collector. These are not headline features, but they contribute to a 5 to 15 percent improvement in throughput for CPU-bound workloads compared to Node.js 20. The WebSocket implementation also improved, with the built-in WebSocket global now stable and performant enough to replace ws for many use cases.

Node.js is not trying to win a speed war with Bun. Instead, it is systematically removing the reasons developers leave: TypeScript friction, ESM/CJS interop pain, and missing built-in APIs. The strategy is working.

Benchmark claims age poorly. Every runtime release changes the numbers. Here are the metrics we measured on equivalent hardware (AWS c6i.xlarge, 4 vCPUs, 8GB RAM) in May 2026, using the latest stable versions of each runtime.

HTTP Throughput (Simple JSON Response)

Single-core, 100 concurrent keep-alive connections, returning a small JSON object:

• Bun 1.2 (native HTTP): 85,000 to 95,000 req/sec
• Deno 2 (native HTTP): 55,000 to 68,000 req/sec
• Node.js 22 (built-in HTTP): 42,000 to 56,000 req/sec

Bun wins the synthetic benchmark convincingly. In real applications with database queries, middleware, and serialization, the gap shrinks to 20 to 35 percent between Bun and Node.js. Deno 2 sits between them, closer to Node.js in heavy I/O workloads and closer to Bun for lightweight request handling.

Cold Start Time

• Bun: 5 to 10 ms
• Deno 2: 18 to 28 ms
• Node.js 22: 30 to 50 ms

For serverless functions where cold start is a significant portion of total execution time, Bun's advantage is meaningful. For traditional servers that start once and run for days, this metric is irrelevant after the first second.

Package Install Speed (Fresh Next.js Project)

• bun install: 2 to 4 seconds
• deno install (npm compat): 6 to 12 seconds
• pnpm install: 8 to 15 seconds
• npm install: 22 to 45 seconds

Bun's package manager remains the fastest by a wide margin. Deno 2's npm install performance has improved but still trails Bun and pnpm. For CI pipelines where dependencies install on every run, the difference between 3 seconds and 30 seconds is time your team feels every single day.

What the Benchmarks Do Not Tell You

Raw throughput numbers favor Bun, but they do not capture stability under sustained load, behavior during memory pressure, or how the runtime handles edge cases in production. Node.js has been load-tested by millions of applications over 15 years. Bun and Deno have not. When we evaluate runtimes for client projects, performance is one input. Reliability, ecosystem depth, and operational maturity are the others.

A runtime is only as useful as the libraries and frameworks it can run. The three runtimes have different compatibility profiles, and understanding the gaps prevents unpleasant surprises mid-project.

npm Package Compatibility

Node.js 22 runs 100% of npm packages by definition. It is the reference implementation. If a package works anywhere, it works on Node.

Bun claims compatibility with roughly 95% of npm packages, and in our experience that number holds for mainstream libraries. Express, Fastify, Prisma, Drizzle, Next.js, React, Zod, tRPC, and hundreds of other popular packages work without modification. The 5% that fails tends to involve obscure native addons, packages that depend on V8-specific internals, or libraries that rely on undocumented Node.js behavior.

Deno 2 has made enormous progress on npm compatibility, but the coverage sits at roughly 85 to 90% in practice. Most pure JavaScript and TypeScript packages work. Packages with native addons are hit-or-miss depending on whether Deno has implemented the required Node.js APIs. The npm: specifier handles resolution well, but some packages with complex postinstall scripts or platform-specific binaries can fail.

Framework Support

Next.js runs on Node.js (fully supported) and Bun (community-supported, with occasional edge cases). Deno 2 can run Next.js through its Node.js compatibility layer, but it is not officially supported and we have seen build failures with newer Next.js features.

Hono is the multi-runtime winner. It runs natively on Bun, Deno, and Node.js with identical APIs and near-identical performance. If you want to keep your runtime options open, Hono is the safest framework choice.

Express and Fastify run on Node.js (native) and Bun (via compatibility layer). Both work on Deno 2 with the npm: specifier, though Fastify's plugin system occasionally triggers compatibility issues.

Fresh is Deno-only. It leverages Deno's strengths (islands architecture, zero JS by default, edge deployment via Deno Deploy) and does not attempt cross-runtime support.

The Practical Takeaway

If your project uses mainstream npm packages and popular frameworks, all three runtimes will likely work. If you depend on niche packages, native addons, or cutting-edge framework features, Node.js gives you the most reliable compatibility. Bun is close behind. Deno 2 is viable but requires more upfront testing.

Technical capabilities matter, but production decisions involve more than benchmarks. How stable is the runtime under real-world conditions? Can you hire developers who know it? What happens when you hit a bug at 2 AM?

Node.js: Battle-Tested and Universally Known

Node.js has been running in production since 2009. Netflix, LinkedIn, PayPal, Walmart, Uber, and thousands of other companies rely on it for critical systems. The failure modes are well-documented. The debugging tools (Node Inspector, clinic.js, 0x) are mature. The monitoring integrations (Datadog, New Relic, Sentry) are first-class. When something goes wrong in a Node.js application, your team has access to 15 years of Stack Overflow answers, blog posts, and community knowledge.

Hiring is straightforward. Every JavaScript developer has Node.js experience. Your job postings do not need to filter for runtime-specific knowledge. Onboarding new team members is fast because the ecosystem, conventions, and tooling are universally known.

Bun: Fast-Moving, Growing Confidence

Bun has been stable enough for production since the 1.0 release, and the 1.1 and 1.2 releases continued to improve compatibility and fix edge cases. Companies like Vercel, Figma, and several YC startups run Bun in production. The community is active, the release cadence is fast, and Jarred Sumner's team responds quickly to bug reports.

The concern is not whether Bun works. It is what happens when you hit an undocumented edge case. The debugging ecosystem is thinner. The monitoring integrations are newer. The number of production war stories you can reference is smaller. For a startup moving fast on a greenfield project, this is an acceptable tradeoff. For a team maintaining a system that handles financial transactions or healthcare data, the thinner safety net is a real consideration.

Hiring for Bun-specific knowledge is not a concern because most Bun projects are standard TypeScript. Any JavaScript developer can contribute to a Bun project on day one.

Deno 2: Maturing Steadily, Niche but Growing

Deno 2 is more stable than Deno 1 ever was, largely because the npm compatibility work forced the team to handle thousands of real-world edge cases. Deno Deploy has been running production workloads for several years now, and companies like Slack, Netlify, and Supabase use Deno in parts of their stack.

The hiring pool for Deno-experienced developers is the smallest of the three. In practice, this matters less than expected because Deno's API surface is based on Web Standards that frontend developers already know. A React developer who understands fetch, Request/Response, and async/await can be productive with Deno in a week.

The practical concern is ecosystem support from third-party services. Your APM tool, your error tracker, your log aggregator: verify they have Deno-compatible SDKs before committing.

We have an opinion, and we think being direct is more helpful than hedging. Here is what we recommend based on shipping production applications on all three runtimes this year.

Node.js 22 for Production Systems Today

If you need maximum reliability, universal cloud support, and the deepest ecosystem, Node.js 22 is the right call. It is the only runtime where you will never be blocked by a missing API, an incompatible package, or a cloud platform that does not support your stack. The native TypeScript stripping and require(esm) support close the two biggest gaps that pushed developers toward alternatives. Node.js is not the most exciting option, but it is the one that causes the fewest surprises at 3 AM.

Use Node.js when: you are building a system that needs to run for years with minimal runtime-level maintenance, your team is large and varied in skill level, you depend on niche npm packages or native addons, or your deployment targets require official Node.js support.

Bun for Developer Tooling and Greenfield APIs

Bun is the best developer experience in the JavaScript ecosystem right now. The combination of instant TypeScript execution, fast package installs, a built-in test runner, and a built-in bundler eliminates entire categories of configuration work. For new API projects, microservices, and internal tools where you control the stack from scratch, Bun lets your team move faster with less friction.

Even if you run Node.js in production, use bun install as your package manager. The speed improvement alone is worth the switch, and it is fully compatible with package.json and existing lockfiles. Many teams at Kanopy use this hybrid approach: Bun for tooling, Node.js for the runtime.

Use Bun when: you are starting a new project without legacy constraints, developer velocity is your top priority, you want to consolidate your JavaScript toolchain into a single tool, or you are building serverless functions where cold start time matters.

Deno 2 for Security-Conscious and Edge Applications

Deno 2's permission model is not a nice-to-have. It is a genuine security boundary that no other JavaScript runtime provides. If your application handles sensitive data, runs untrusted code, or operates in a regulated environment, Deno 2's sandboxed execution model is a meaningful architectural advantage. Pair it with Deno Deploy for edge-first applications, and you get a global runtime with fine-grained security controls and excellent cold start performance.

Deno 2 is also excellent for scripts, CLI tools, and automation. The deno compile command produces standalone executables, the standard library covers common needs without npm dependencies, and the permission system prevents scripts from accidentally accessing resources they should not.

Use Deno 2 when: security is a primary architectural requirement, you are deploying to the edge via Deno Deploy, you want a standards-based runtime with strong defaults, or you are building tools and scripts that benefit from standalone compilation.

The Honest Bottom Line

The gap between these three runtimes is smaller than it has ever been. All three run TypeScript. All three access the npm registry. All three can serve HTTP requests with competitive performance. Pick the one that matches your project's primary constraint and commit to it. Switching later is more practical than ever because interoperability between runtimes has improved dramatically.

Not sure which runtime fits your next project? We help teams evaluate their stack, benchmark their specific workloads, and make runtime decisions based on real data instead of hype. Book a free strategy call and we will work through the decision together.