In 2022, Jarred Sumner released Bun following his frustrations with the speed of Node.js when developing a Next.js project. The origin of the name is unclear, and the logo doesn’t help! It could relate to the food, fluffy rabbits, “bundle”, or perhaps it’s a short, memorable name and the bun.sh domain was available.
npm start to launch your Node script, you can run
bun start and take advantage of Bun’s speed.
Tasty Bun Benefits
Internally, Bun uses ES Modules, supports top-level
await, translates CommonJS, and implements Node’s
node_modules resolution algorithm. Bun caches modules in
~/.bun/install/cache/ and uses hardlinks to copy them into a project’s
node_modules directory. All projects on your system will therefore reference a single instance of the same library, which reduces diskspace requirements and improves installation performance. (Note that macOS installations retain local versions for speed.)
Bun supports Node’s
npm equivalent commands, and bunx — a
npx-like option to auto-install and run packages in a single command. For example:
bunx cowsay "Hello, world!"
bun init scaffolds empty projects in the same way as
npm init, but you can also template a new project with
bun create <template> <destination>, where
<template> is an official package, a Github repository, or a local package. For example, to create a new Next.js project:
bun create next ./myapp
bun build ./index.ts —outdir ./out
There’s no need for nodemon-like tools, since
bun has a
—watch flag which restarts scripts or tests when you modify a dependency file. Restarts are so fast that it becomes possible to live-reload on each keystroke. (Whether this is practical and not a distraction is another matter!)
Live reloading is not pretty! (Warning: flickering content!) View original animated GIF.
—hot mode is available, where Bun watches for changes and soft reloads modules. All files are re-evaluated, but the global state persists.
Environment variables contained in project
.env files are automatically loaded and parsed, making them available in Bun applications, so there’s no need to use packages such as dotenv.
As well as its own Bun APIs for networking, file access, child processes, and so on, Bun supports:
Web APIs such as
setTimeout, and events.
Node.js compatibility APIs such as
util, as well as globals including
__filename. Bun claims that 90% of the most-used APIs are fully implemented, although you should double-check those specific to your project.
Finally, Bun has a native SQLite3 client — bun:sqlite — which could reduce the number of dependencies required in some projects.
Bun is in active development, so the following features are yet to appear:
a Deno-like permission model to restrict access to files, the network, child processes, environment variables, OS information, and so on. Adding permission rights later can cause complications (as seen in Node.js 20), so I suspect options will arrive before the version 1.0 release.
Tools such as a Read-Eval-Print Loop (REPL), dependency inspector, linter, debugger, code formatter, documentation generator, and a standalone script generator are missing but should appear over time.
Bun has not reached a version 1.0 release, but it’s available as a single binary you can install on Linux, macOS, and Windows WSL with:
curl -fsSL https://bun.sh/install | bash
Alternatively, you can install it with Node’s package manager:
npm install -g bun
A native Windows version is coming, although the Windows Subsystem for Linux is often the easier and better-performing option. Alternatively, you can also use Docker to run Bun in a container:
docker run —rm —init —ulimit memlock=-1:-1 oven/bun
Once installed, you can upgrade the engine with:
To uninstall, remove the
~/.bun binary and cache directory:
rm -rf ~/.bun
Then update your shell configuration file (
.zshrc, or similar) to remove
~/.bun/bin references from the
Bun is reliable if you use it from the start of your project. Speed is better than Node.js, although you’re unlikely to see a significant performance boost unless your app is doing specific intensive tasks such heavy SQLite processing or WebSocket messaging.
Node.js compatibility is good for smaller, simpler projects, and I successfully launched some scripts using
bun start without making changes. More complex applications did fail, with obscure error messages generated deep in the
Bun vs Deno vs Node.js
Deno addressed many of Node’s drawbacks, but developers didn’t necessarily feel compelled to switch:
- Deno didn’t support Node’s third-party modules.
- Migrating from Node.js to Deno required learning new techniques.
- While Deno offered a better development experience, Node.js was good enough.
Deno has now added Node.js compatibility options. That was the easiest way to get developers to transition to Deno, but in the meantime, Node.js has adopted some of Deno’s features, including ES modules, a native test runner, and a
Bun has taken a different approach, aiming to be a fast, Node-compatible engine with Deno’s advancements. The signs are promising, but it’s not there yet:
Performance is great, but few developers complain about Node.js speed.
Bun has the potential to replace your tooling suite, but it’s yet to offer the full range found in Deno.
Summary: Should You Switch to Bun?
bun start, but the larger your codebase, the less chance it will execute without modification.
Deno is probably a better option than Bun for new projects, given that it’s more mature and feature-complete.
Bun is great, but it’s new, being actively developed, and yet to reach a version 1.0 milestone. The runtime is stable, but few would bet on its long-term future at this stage. That said, Bun has some interesting ideas which I hope both the Node.js and Deno teams consider adopting (CLI APIs and auto-loaded