Node.js vs Bun: Why Capuzzella Chose the Faster Runtime

Node.js made server-side JavaScript possible. Bun made it fast. Here's why Capuzzella runs on Bun — and why the shift from Node to Bun mirrors a larger change happening across the JavaScript ecosystem.

Where Node.js Came From

In 2009, Ryan Dahl took Google's V8 JavaScript engine out of Chrome and wrapped it in an event-driven, non-blocking I/O runtime. The result was Node.js — a way to run JavaScript on the server. It was a breakthrough. Frontend developers could suddenly write backend code in the same language they already knew. The ecosystem exploded: npm became the largest package registry in the world, and JavaScript became the de facto language of web development, full stack.

Node.js earned its place. It proved that JavaScript outside the browser wasn't a toy. It powered startups and Fortune 500 companies alike. Netflix, LinkedIn, PayPal, and Uber all built critical infrastructure on it.

Why Node.js Moves Slowly

Fifteen years later, Node.js carries the weight of its own success. It's governed by the OpenJS Foundation, which brings together corporate stakeholders from Google, IBM, Microsoft, Intel, and others. Every significant change goes through a Technical Steering Committee, working groups, and a consensus-driven process involving dozens of contributors with different priorities.

This governance model ensures stability — exactly what enterprises need. But it comes at a cost: Node.js evolves slowly. Features that should be straightforward — native TypeScript support, a built-in bundler, a faster HTTP server — take years to land, if they land at all. The runtime still ships with legacy APIs that no one would design today, but can't be removed without breaking millions of existing applications.

Node.js also inherited architectural decisions from 2009 that are hard to undo:

• npm as a separate tool. The package manager is a standalone project with its own release cycle, its own bugs, and its own performance characteristics. Installing dependencies is famously slow.
• CommonJS as the default module system. The ESM transition has been painful. Dual-publishing packages for both module systems remains a source of friction years after ESM became a standard.
• No built-in TypeScript support. Node only recently added experimental type stripping. For over a decade, TypeScript users needed transpilation toolchains (tsc, ts-node, tsx) just to run their code.
• No built-in test runner (until recently). The community spent years choosing between Mocha, Jest, Vitest, and Ava before Node shipped its own node:test module.

None of this makes Node.js bad. It makes it slow to adapt. And in a world where developer expectations have shifted dramatically, that gap created an opening.

Bun: Built to Fill the Gap

Jarred Sumner started building Bun in 2021 with a clear thesis: a single person with the right design choices could build a faster JavaScript runtime than the one maintained by a committee. Instead of V8, Bun uses Apple's JavaScriptCore engine (the one inside Safari and WebKit), which starts up faster and uses less memory. Instead of C++, the runtime is written in Zig, a systems language designed for performance-critical code.

But Bun isn't just a different engine. It rethinks what a JavaScript runtime should include out of the box:

• Package manager built in. bun install is dramatically faster than npm install because it uses hardlinks, a global cache, and a binary lockfile.
• Native TypeScript and JSX. Bun transpiles TypeScript and JSX natively. No tsc, no build step, no configuration. You write .ts files and run them directly.
• Built-in bundler. bun build replaces webpack, esbuild, and Rollup for many use cases.
• Built-in test runner. bun test is Jest-compatible and runs significantly faster.
• Web-standard APIs. fetch, Request, Response, WebSocket — they all work natively without polyfills.

The Numbers Speak for Themselves

Bun's performance advantage isn't incremental — it's dramatic. Here's an HTTP/2 "Hello World" server benchmark comparing Bun v1.1.31 to Node v23.0.0:

Bun handles 128,879 requests per second — nearly 2.5x faster than Node's 52,785. And that's for a trivial Hello World response. For real-world workloads involving file serving, the gap widens further.

A more recent benchmark from Bun's team shows Bun v1.2.16 serving an 8 KB package.json file at 219,714 requests per second — 5x faster than Node v24.1.0 at 39,178 req/s. When your CMS serves static HTML files as its primary job, this kind of throughput difference matters.

Why Bun Is the Right Runtime for Capuzzella

Capuzzella is a CMS that stores every page as a static HTML file on the filesystem. The runtime's job is straightforward: serve those files fast, handle API requests for the editor, and get out of the way. This workload plays directly to Bun's strengths.

• File serving speed. Capuzzella's published pages are static HTML files served directly from disk. Bun's I/O layer, built on system-level optimizations in Zig, delivers these files faster than Node can. The 5x file-serving advantage shown in the benchmarks translates directly to faster page loads for every visitor.
• Startup time. Bun starts in milliseconds, not seconds. For a CMS that should feel instant when you launch it — whether on a VPS, a local dev machine, or a container — cold start time matters. Bun's JavaScriptCore engine initializes faster than V8.
• Native TypeScript. Capuzzella's codebase is JavaScript, but as it grows, the ability to run TypeScript files directly — without a build step or transpilation toolchain — keeps the developer experience clean and the deployment pipeline simple.
• Fewer moving parts. Bun replaces what would otherwise be Node + npm + a test framework + a TypeScript compiler. Fewer dependencies mean fewer things to break, fewer security advisories to track, and a smaller attack surface.
• Single-binary deployment. Bun is a single binary. Combined with Capuzzella's file-based architecture (no database for content), the entire CMS can run on minimal infrastructure. There's no node_modules bloat to ship, no native addon compilation to debug.

The Right Tool for the Job

Node.js built the JavaScript server ecosystem. It deserves credit for that. But it was designed for a different era — one where "JavaScript on the server" was the hard problem, and raw performance was secondary to proving the concept worked.

Bun starts from a different premise: the concept is proven, now make it fast. Strip out the legacy. Ship the tools developers actually need. Optimize the hot paths that matter for real workloads.

For Capuzzella — a CMS that serves static HTML files, runs an API for AI-powered editing, and values simplicity over complexity — Bun is exactly the runtime the job demands. Fast file serving, minimal overhead, batteries included.