Explore Bun.js: The all-in-one JavaScript runtime

Bun.js is an all-in-one JavaScript toolkit whose jolly moniker belies its transformative potential. Bun brings together several important topics in server-side JavaScript, resulting in a single, high-performance tool. It is a runtime like Node or Deno, a package manager like NPM or pnpmand a build tool like webpack or Vite. It has quickly evolved from a one-man side project to a compelling alternative to standard approaches.

Bun vs. Node.js

Bun.js is essentially a server-side JavaScript runtime like Node. On top of this is built a package manager and a packer/builder. The runtime itself is the current focus of development and is the most complete part of the project. The package manager is the next most developed, and the packager is the most alpha stage at the moment.

Bun creator Jarred Sumner told me, “We want to make JavaScript faster to run and easier to write. An important part of that is ecosystem compatibility. Bun is designed as a drop-in replacement for Node.js. People shouldn’t have to rewrite their code to use Bun.”

Bun is built from the ground up with the WebKit/Safari JavaScriptCore engine (instead of V8 like Node). It is not a fork of Node. The libraries are built in C and Zig, and explicitly avoid any dependencies on Node or NPM, thus minimizing JavaScript on your stack. All of these decisions are in the service of maximizing performance. Rewriting the universe of JavaScript-implemented APIs, such as network and disk IO, into a lower-level language leads to huge performance gains. It is also a monumental undertaking.

Bun aims to cover the entire Node/NPM API, and is moving quickly towards that goal. Here’s the Bun project roadmap, where you can get an idea of ​​the scope of the project and how fast it’s moving. Additionally, there is a list of planned features that have not yet been implemented. You’ll notice that Bun includes edge-oriented features and much more. It’s really a complete JavaScript ecosystem built on top of a runtime engine.

Bun is in active development and its developers acknowledge that “it is experimental software.” Currently, the focus is on expanding and stabilizing the JavaScript runtime. The project is currently at version 0.5.5.

Now that we know what Bus is intended for and have an idea of ​​where it is on its growth trajectory, let’s get our hands on Bun!

Install and run a Bun React app

You can install Bun as a native package on any operating system. You can also install it as a global npm package. It might seem a bit strange to install an NPM replacement with NPM, but it sure makes installation easier.

Listing 1. Install Bun with NPM

$ npm install -g bun
$ bun -v
0.5.5

He bun The command is now available on your command line. Let’s use Bun to create a new React app. This is the same as entering: npx create-react-app my-app. If you are familiar with using npx (running on NPM/Node), you’ll notice right away how fast using Bun works. Run the command in Listing 2 to start a new project using the create-react-app libraries

Listing 2. Run create-react-app

$ bun create react ./bun-react
[package.json] Detected React - added "react-refresh"
$ bun install // This happens automatically
[12.00ms] bun install
$ bun bun ./src/index.jsx // this happens automatically
[720.00ms] bun create react

Note that you don’t enter the second two commands; they happen automatically as part of the initial command. You may be surprised to see that the entire command took less than a second. including Installing Node modules.

You can now cd in it bun-react/ directory and start the development server with bun dev. You can then visit the app at local host: 3000where you will see a welcome screen like the one shown in Figure 1.

IDG

If you take a look at the package.json file, you’ll see that it’s the same as otherwise, without adding anything specific to Bun. Bun is doing exactly what NPM would do, but faster.

For a quick non-scientific review, I rm -rfwould be the /mode_modules directory and reinstalled the dependencies with bun install (four milliseconds) versus npm install (two seconds).

Bun for serverless and edge deployments

What you just saw is Bun doing the job of a package manager as well as a script runner. when did you bun devyou were doing the equivalent of npm run dev. The subtlety with Bun is again speed, but that speed has implications for other areas as well. Bun is fast to execute the task because it is fast to start. Most of the time required to run a task with Node/NPM is spent starting the Node process itself.

The fact that Bun starts quickly is an important feature in serverless and edge deployments, where “scaling to zero” is the ideal. That means you want a system that can spawn nodes to meet demand. Then, when that demand subsides, you should cheaply remove the nodes. A big hurdle to such scalability is the speed at which the nodes can spin up. Thus, the ability to quickly launch and run scripts means Bun is ideal for serverless and edge computing environments.

Bun for Next, Svelte and Vue

Bun can do something similar with a Next application, starting with the command: bun create next ./app. For a list of all currently available create commands, type bun create. You’ll notice that there are about a dozen supported templates in Bun .0.5.5.

To handle use cases where a built-in loader is not available, Bun.js includes pluggable loaders. This allows handling files for Svelte or Vue, such as .svelte either .vue. You can learn more about Bun’s custom chargers here.

There is an experimental SvelteKit adapter for running SvelteKit on Bun. This is very much under development, as the Bun API itself is rapidly evolving and SvelteKit depends on those APIs. (The SvelteKit template obtained with bun create doesn’t seem to be working right now.)

Buns and modules stacking

One of Bun’s ambitions is to replace the transpilation phase of construction. This is complex because it deals with many different technologies, from CSS to JSX. These are technologies that are subject to change and therefore complications like tree shaking and minification.

Bun also has to deal with JavaScript module resolution, which the Bun documentation acknowledges is complex. The complexity is overwhelming even to think about, which is what stops most people from trying something like Bun. Rewriting what is already pretty good (Node/NPM) with something even better is a lofty goal.

I’ll refer you back to the Bun roadmap, which includes items related to transpilation, bundling, and module resolution.

bun as server

Bun can run WASM binaries on the server. You can also handle HTTP requests with a built-in API that is similar to a serverless environment. Let’s take a quick look. If we create a file called server.ts and add the code in Listing 3, then we can run it with Bun.

Listing 3. Use Bun as a simple server

export default {
  port: 3000,
  fetch(request: Request) {
    return new Response("Hello InfoWorld");
  }
};

To run echo server, type bun server.ts. If you navigate to local host: 3000, you will see the greeting. This works because if Bun finds a default export object with a get method, it assumes it’s a server. Wrap this in the Bun.serve API. You can see a simple usage of this API in Listing 4. Where applicable, the APIs found in Bun follow web standards, so the request and response objects are the familiar standards (ie Request). Listing 4 uses the Request object to get the fetched url and generate it.

Listing 4. Using the Bun.serve API

Bun.serve({
  fetch(req) {
    return new Response("You visited: " + JSON.stringify(req.url));
  },
});

Note that the Bun Node APIs (NAPIs) are not complete enough to run Express; however, there are a number of similar projects for Bun himself. An example is BunRest.

A new approach to server-side JavaScript

Bun’s roadmap includes many pending tasks, providing an idea of ​​the scope and ambition of this project. Bun really seems to become a one-stop-shop for doing most server-side JavaScript tasks, including everything from build processes to hosting an embedded SQLite instance to running native functions with Bun FFI. of external functions).

Instead of the workflow being: I need to do a JavaScript job, so let me get the runtime and package manager and download the specific tools to maintain a working environment, followed by the tools for the task at question becomes: let’s set up bunk beds and get the tools for the actual job.

It’s also interesting that Bun uses Zig under the hood. Zig is not only a programming language, but also a package manager and a build tool all in one. This is a sensible trend, because in the past we had the goal of creating a general-purpose functional language. That was a big enough goal in itself, and then all the necessary support for development and production was installed afterward.

Nowadays most of us understand that a language will need those things, especially a package manager and a build tool. It makes sense that designers are incorporating them into the language from scratch. From the 10,000 foot view, it looks like we’re looking at a new generation of programming tools that are next-level bootstrap tools and utilities based on previous learnings. Now is a very interesting time to build software.

Do you want to continue learning about Bun? Get started with this list of interesting projects in the Bun.js ecosystem.