The JavaScript language is not the future of JavaScript technology. Webpack and Babel are becoming less and less relevant by the day. Why?

For the bundling, transpiling, and compiling process, languages like as Rust, Go, and even Zig have shown to be more performant than JavaScript. They are not single-threaded, which is advantageous when dealing with large files.

What is the rationale for keeping the ecosystem tools in JavaScript? Those tools are intended to be run on developer computers rather than browsers. Furthermore, JS Developers are not required to debug their internals.

The SWC was one of the first non-JavaScript tooling efforts. Shortly after, esbuild was revealed, and everyone was excited. Because of their performances, both were game changers.

Behind the scenes, the Vite 2.0 project is now leveraging esbuild to provide a performant building experience.

Bun, a new participant in the JavaScript tooling environment, has just emerged. It is intended to speed up the entire JavaScript development process. It comes with everything you need. It not only speeds up compilation and parsing, but it also has its own dependency manager tooling and packaging.

It is not yet ready for production, but the future seems promising for this tool. In this post, we’ll look at this new tool and see how it compares to npm, esbuild, babel, and Webpack.

Overview

Bun, unlike its rivals, is written in Zig rather than Rust or Go. Zig is a general-purpose programming language and toolchain for developing software that is resilient, optimum, and reusable.

Even though it was constructed from the ground up, the creators based their approach on the esbuild project.

The bun tool supports out-of-the-box complicated features such as TypeScript, CSS in Js, and JSX. It still lacks essential functionality such as Source Maps, Minifier, Tree Shaking, and others.

Bun has its own node module resolver implementation, which is a notable feature. It is one of the most visible improvements.

Bun, like Npm and Yarn, will generate certain related lock files. It will form a bun. lockb. There is one minor catch. It will create a binary file rather than a plain text file. Why is it written in binary? For reasons of performance. We will have to cope with the disadvantage of not being able to readily check the changes on the PRs.

This lockfile can only be inspected with the command:

bun install -y

Bun support as today the following loaders: 

Set up

The bun project is not public yet. You would have to join their discord here to get an invitation. Once you join it, all you need to do is navigate to their #invites channel. There you can request the invite through writing on the channel I want bun.

You will get a one time invite for the jarred-sumner/bun repository.

To install bun you need to execute the following commands:

curl -fsSL https://bun.sh/install | bash# Manually add the directory to your $HOME/.bashrc (or similar)
BUN_INSTALL="/home/jgranja/.bun"
PATH="$BUN_INSTALL/bin:$PATH"

To check that it is all working correctly:

bun --version

You will notice that it has not reached the 1.0.0 version yet. As I mentioned previously it is still not production-ready.

Usage

Its usage is quite simple. If you are familiar with yarn or npm it comes pretty much to the same.

To install packages:

bun install

Just like yarn it will use the existing package.json in combination with the lockfile when present.

To add or remove any package:

bun remove react
bun add preact

We can use bun as a runner:

# instead of `npm run clean`
bun run clean# if added to the `scripts` in package.json
bun clean

It does provide some integration with the latest React ecosystems through their create command.

Let’s create a Next.js app:

bun create next ./app
cd app
bun

Let’s create a Create React App:

bun create react ./app
cd app
bun

How to generate the bundled file?

By running bun bun ./path-to.js we generate the node_modules.bun file. It contains all the imported dependencies.

You can inspect the contents by just doing ./node_modules.bun > build.js.

Benchmarks

Let’s run a few benchmarks to understand its speed. Of course, those are approximate measurements and will vary depending on the computer. As this is a tool for developers, I have focused on the most common development tasks:

• starting the development server
• making a change in a file
• installing packages
• building a production distribution
• creating a new web app

For reference, my laptop is rocking an AMD Raizen 7 with 16GB and I’m using Ubuntu 20.04.

I have used a utility that generates random jsx files. You can check here. I have generated a set of 21 random jsx files that I have included in all the created test projects.

1. Bun vs. Babel

This is not really a fair fight but it highlights how fast this tool is compared to what was used traditionally.

2. Creating a Create-React app

We can see a noticeable difference between creating a Create React App through bun or webpack + npm. By using the former there is barely any delay, it takes only 4.4s to get you all set up.

3. Creating a Next.js app

The previous astonishing results are not that impressive. We are used to tools beating up Webpack. Let’s put up a fair fight. Let’s now compare bun with Next.js which uses internally swc.

The differences between both are very noticeable. Especially the difference in processing a file change. On my laptop, it takes only 10ms for bun while it takes over 70ms for SWC.

4. Package Manager

In the module install and manipulation is where bun makes some ground. The other tools are relying on npm or yarn to get the job done. Its performance is around 4x — 100x times faster than npm.

We already saw the huge difference in the 2. Create React App step. However, let’s do a more basic example now. Let’s create a package.json file with the following dependencies:

• [email protected] — 89.5 kB
• [email protected] — 339.1kB
• [email protected] — 6.9 kB

Then we can benchmark how it performs on first install and cached installs. I chose one heavy library like jspdf to make the difference more noticeable.

The time difference is noticeable. It is 4x faster when using the network and way more when packages are resolved from the cache.

5. Vite vs. bun

The esbuild is the real competitor or bun. For this test, I have used Vite which has esbuild internally.

I have used the same code as above to generate the bundles for the three major competitors. It is worth remembering that bun is not recommended for production as it still lacks quite a few features. As impressive as the results are it is to take with a grain of salt.

As well note that the max build time is 5 secs in the worst scenario. It is not unreasonable, the three tools do an awesome job here.

Wrap up

The JavaScript tooling has never looked any better. Even if this tool is not yet production-ready it is awesome to see new competitors. The future of Webpack is unclear and it has many competitors in the JavaScript space and outside of it.

The bun tool is not an all-around tool. It has been built with a specific use case: building websites and webapps. To build libraries, the bun team recommends esbuild or even Rollup.

Nowadays, the focus is still not on production. It is focused on development and compatibility with existing frameworks and toolings.