Why Bun Uses JavaScriptCore Instead of V8

If you have written server-side JavaScript, the word V8 is likely the first thing that comes to mind. V8 is the engine inside Chrome, and it is the engine that powers Node.js and Deno. When Bun appeared in 2022 promising dramatically faster startup and installs, the surprise was not just the speed. It was that Bun does not use V8 at all. Bun is built on JavaScriptCore, the engine that WebKit provides and that Safari uses.

That choice looks like a small implementation detail, but it is central to everything Bun does. Jarred Sumner, Bun's creator, wanted a runtime that started almost instantly, used a fraction of the memory, and felt lighter than Node in everyday use. JavaScriptCore has a reputation for strong cold-start behavior and a smaller memory footprint in embedded scenarios, which fits exactly the goals Bun was chasing. Rather than inherit V8's overhead, Bun bet on an engine that had spent years being optimized for embedding in small, fast contexts.

There is a real architectural payoff beyond raw numbers. Because JavaScriptCore is a browser-derived engine, Bun inherits a close relationship with web platform primitives. The runtime can expose the same global APIs that a browser provides, like fetch, WebSocket, and a set of built-in web standards, with fewer compatibility shims standing in the way. That is a large part of why Bun can run modern TypeScript and JavaScript with so little ceremony and can talk to web-oriented services so directly.

From a senior developer's chair, the interesting part is what this means in practice on a daily project. Startup latency is the most visible win. Tools like tests, migration scripts, and CLI helpers that spawn a fresh interpreter feel meaningfully faster because the engine boots quickly. Memory usage in long-running service processes tends to be lower too, which matters when you are packing many worker instances onto a single machine to keep hosting bills down.

The trade-off is compatibility pressure. Node.js and the broader ecosystem were built around V8, and a small set of internal behaviors differ when you run the same code on JavaScriptCore. Bun has invested heavily in compatibility layers so that most Node modules work unchanged, but the careful engineer still tests libraries that reach for engine-specific internals, especially old native modules or tools that poke at V8's memory model. Knowing your runtime's engine helps you reason about which failure modes you should expect.

The lesson here extends beyond Bun. Engines are a strategic decision, not a footnote. Node chose V8 because it reused a proven browser engine. Bun chose JavaScriptCore because it prioritized startup speed and embeddability. Deno, originally on V8, shows that even the same engine can serve different product philosophies. When you evaluate a runtime, ask what engine sits underneath, because that single choice shapes startup time, memory use, API surface, and compatibility all at once.

For most projects, Bun's JavaScriptCore foundation is invisible until you need it. It shows up as fast boots, lean processes, and clean web-platform APIs. It means holding Bun to a V8-shaped mental model will occasionally mislead you. Embrace the engine difference as a feature, test the code paths that matter, and you get the speed without the surprise.