Why Bun Over Node.js

Node.js made server-side JavaScript possible. Before Node, the idea of running JavaScript outside the browser was a curiosity. Ryan Dahl changed that in 2009, and the ripple effects shaped the entire software industry. npm became the largest package registry in the world. Companies built their backends, their tooling, their entire platforms on Node. Without Node.js, the modern JavaScript ecosystem simply would not exist.

But when I was choosing a runtime and package manager for Eden Stack, I chose Bun. Here's why.

Speed That Actually Matters

Let's start with the numbers, because they're hard to ignore.

Bun launches in 8-15ms. Node.js takes 60-120ms. That's roughly a 6x difference in cold start time. For a single script invocation, you might not notice. But when you're running dev servers, executing test suites, or iterating through build steps dozens of times per day, those milliseconds compound into minutes.

On HTTP throughput benchmarks, Bun handles around 52,000 requests per second compared to Node.js at 14,000. That's nearly 4x. Now, I should be honest here: these numbers come from synthetic benchmarks. Real-world applications with database queries, business logic, and network calls narrow the gap significantly. In production workloads, both runtimes deliver roughly similar throughput because the bottleneck is I/O, not the runtime itself.

The speed you feel as a developer, though, is real. Scripts start faster. Tests run faster. The feedback loop tightens. That's what matters day to day.

Native TypeScript Execution

This is the feature that sold me.

With Node.js, running TypeScript has historically meant one of several things: a compile step with tsc, a wrapper like ts-node, or configuring a bundler. Node.js 22 introduced --strip-types for basic TypeScript support, but it strips types without full transformation support for features like enums and decorators.

Bun runs .ts, .tsx, and .jsx files natively. No configuration. No extra tooling. No build step for development. You write TypeScript, you run it with bun run, and it works.

# Node.js (traditional)
npx tsc && node dist/index.js
 
# Node.js 22 (experimental)
node --strip-types index.ts
 
# Bun
bun run index.ts

For a stack like Eden that's TypeScript end-to-end, from Drizzle schemas to Elysia API routes to TanStack Start components, removing the compilation step from the development loop is a meaningful improvement.

Bun as a Package Manager

Bun isn't just a runtime. It's also a package manager, and a fast one.

Installing a 50-dependency project takes Bun about 0.8 seconds. The same install takes npm roughly 14 seconds and pnpm around 4 seconds. For larger dependency trees, the gap widens further. A project with 800+ dependencies that takes npm over two minutes finishes in under five seconds with Bun.

Why the difference? Bun is written in Zig, a compiled systems language. It makes roughly 165,000 system calls during a typical install compared to npm's 1,000,000+. It uses a global cache with hard links, so packages downloaded once are available instantly across all your projects.

In CI pipelines, this adds up. A team running 50 pipeline runs per day can save over eight hours of compute time per month just from faster installs. That's real money and real developer time waiting for green checks.

Bun's lockfile (bun.lock) also deserves mention. Since Bun 1.2, it defaults to a human-readable text format that plays nicely with code review and git diffs, while still parsing faster than JSON or YAML alternatives.

The Compatibility Story

Here's where I need to be straightforward, because this is Bun's biggest weakness.

Bun achieves roughly 95% npm package compatibility. That sounds high, and for most projects it is. The standard libraries work. Express works. Most ORMs work. Popular tools like Drizzle, Elysia, and TanStack all run on Bun without issues.

But that remaining 5% can bite you. The pain points:

• Native addons: Packages that rely on node-gyp and N-API bindings sometimes fail. Popular native modules like bcrypt, sharp, and better-sqlite3 work, but obscure or outdated native dependencies can break.
• Node.js internals: Packages depending on V8-specific behavior, exact error message formats, or undocumented Node.js APIs may behave differently. Bun uses JavaScriptCore (Safari's engine) under the hood, not V8.
• Edge cases in core modules: Some patterns in vm, worker_threads, cluster, and child_process behave differently or are only partially implemented.
• Docker workflows: The official Node.js Docker images don't include Bun. You'll need Bun's official images or an extra install step in your Dockerfile.

The Bun team is closing these gaps aggressively. Bun 1.2 was the biggest compatibility release yet, improving Windows support and node:cluster. But if your project depends on a specific native module without a pure JavaScript alternative, test carefully before committing.

The Community Factor

Node.js has been around since 2009. When something goes wrong, you'll find a Stack Overflow answer, a blog post, or a GitHub issue with a workaround. The debugging knowledge base is enormous.

Bun's community is growing quickly but it's still younger. When you hit an edge case, you might be the first person to encounter it. The documentation is good and improving, but you won't always find someone who's solved your exact problem before.

For teams comfortable reading source code and filing issues upstream, this is manageable. For teams that rely heavily on community-sourced solutions, it's a real consideration.

When Node.js Still Makes Sense

I'm not here to say Node.js is obsolete. It's the right choice in several scenarios:

• Mature production systems: If you have a Node.js application running reliably in production, migrating to Bun for speed alone rarely justifies the risk.
• Heavy native module usage: Projects depending on canvas, specialized image processing, or other packages where node-gyp is non-negotiable should stay on Node.
• Team familiarity: Switching runtimes has real onboarding costs. If your team knows Node.js deeply and doesn't have pain points, the migration may not be worth it.
• Serverless edge cases: Some benchmarks show Bun with longer cold starts than Node.js in specific serverless environments like AWS Lambda. If you're optimizing for serverless cold starts, benchmark your own workload before deciding.
• Enterprise compliance: Some organizations require runtimes with specific certifications or long-term support guarantees. Node.js has a well-established LTS cycle. Bun doesn't yet.

Why Eden Stack Uses Bun

For a modern TypeScript starter kit, the calculus was clear:

1. Developer experience: Native TypeScript execution, faster startup, tighter feedback loops.
2. Install speed: Seconds instead of minutes, both locally and in CI.
3. Unified tooling: One tool for runtime, package management, and script execution. No separate npm, npx, or ts-node to manage.
4. Ecosystem fit: Every major dependency in Eden Stack (TanStack Start, Elysia, Drizzle, Better Auth, Stripe, Inngest) runs on Bun without issues.
5. Forward momentum: Bun's compatibility improves with every release, while its performance advantages remain structural.

The honest truth is that for most web applications, the runtime choice matters less than people think. Both Node.js and Bun will serve your HTTP requests. Both will connect to your database. Both will run your business logic. The difference is in the developer experience around those tasks: how fast your tools respond, how little configuration you need, how tight your iteration loop feels.

For Eden Stack, Bun makes that experience better. And for developers starting new TypeScript projects in 2026, I think it's the right default.

This post reflects my opinions after building production applications with both runtimes. Your mileage may vary, and technology decisions should be based on your specific requirements.