A Bun in the oven

As a developer you are constantly concerned about the user experience and how the user will interact with your software. And the number one joke made by developers is always: "Forget the user experience, what about the developer experience?". And Bun is the solution for that!

Bun is not package manager, test runner, or runtime. It is all of the above. Bun describes themselves as an all-in-one toolkit for Javascript. So what can it all do? And is it just the next in line of "new and innovative" Javascript hypes that will be unused in two years?

Back to basic

Before we actually start to work with Bun, we are going to check what Bun is actually capable of. As mentioned in the introduction. Bun is not just a package manager, or just a test runner. It is a complete toolkit full of features. Every project or toolkit needs an unique selling point. What is it that makes Bun actually better than all those other options. We already have multiple package managers and we are cautious to add another one to that list.

On the website of Bun we are immediately greeted by their first Unique-Selling-Point (USP). On their homepage they compare the latest and greatest package managers. When installing dependencies for an example app (Remix app) the fastest secondary option is 17x slower (6.44 seconds) compared to Bun (0.36 seconds). So when you are installing your project's packages (new updates, new location or in your CI/CD pipelines) they are way way faster.

This trend continues throughout all the different functionalities. The test runner is 5x faster than Vitest and even 8x faster than Jest + SWC. Besides these toolkit functionalities, Bun is also a runtime.

The runtime

As more in-depth developers might know, Chrome and Node.js are all supported by the V8 engine. Renowned for it's flexibility but also for it's chugging of memory, the V8 engine is very popular. This means that Bun replaces the V8 engine with it's own (high-performant) engine. When using Bun as a runtime for a websocket server, Bun was able to sent more than 1 million messages while serving 32 clients. While Deno was only able to send 512 thousand and Node.js was only able to send 180 thousand messages. That means that Bun is almost 10x faster than Node.js.

A new runtime also means that a lot of features we take for granted have to be reworked. The Bun runtime had to rework the complete fs package (reading and storing files) and importing packages have been reworked. In Javascript / Typescript there where multiple ways and it was always hard figuring out which way the correct one was. In Bun they pulled this straight and used import { x } from "package"; approach.
In their documentation they describe the exact way they read modules / packages. Due to the runtime doing this calculation, current npm packages also still work like they used to do in Node.js.

Bun aims to provide a consistent and predictable module resolution system that just works. Unfortunately it's still quite complex.

Package manager

So the package manager is quicker? Is this the only advantage? Short answer, yes. But that is mostly because the package manager only installs packages. What is there more to improve? Well... A lot. As mentioned in the previous chapter, they improved the module importing system to be easy and in-line with typescript and javascript. So no more confusing on which import to use. It even brings more features like a binary lock file, instead of a yaml / json variant, which makes loading that file way faster, and we know how big those files can become...

Test runner

Also a part of the Bun toolkit is a test runner. With existing Jest syntaxt you can write tests (also DOM tests) for you Bun environment. It includes all the lifecycles hooks that you can expect from Jest and also the "crazy fast" startup times as with the serve command. Even though testing is a whole different subject in relation to the development, and a lot of hobby projects go untested (and big enterprise businesses usually let testing be handeld by a different department that uses external tools). This is still a good improvement and it lowers the bar for hobbists to still test their software. Or even lower the bar for the open-source community where testing is usually a pré.

Watching

A big part of development is an iterative proces. That means that you make a small change, check the result of that change and continously iterate on that. Bun adds a special --watch feature for typescript, so you do not have to watch with two different commands to make your Typescript program working. Also the watching proces is way faster than current watching proces. This makes it almost feel like you are actually directly editing the code that is running in the browser (DevTools) but you actually editing the pre-compiled code.

Conclusion

Bun is a complete new toolkit for Javascript and Typescript developers that can not just improve their development environment but almost make development actually developing software. All the extra's that are required to develop, are made so fast, that they almost do not feel like you need to execute that step. In a bigger environment you can even automate these steps by executing them on certain actions where you, because they are so fast, don't even realise they have executed.

A disadvatage for Bun is it's predecessor, Deno. It also had a lot of hype at the start of its release but after a few months the hype died down and it resulted in Node.js still being the preferred pick for a lot of developers.

Some other resources

This is a small article outlining what Bun is and what it can bring to the Javascript / Typescript environment. But there is way more and using it always brings some more context. I encourage you go and use Bun in a hobby project whenever you can. For some easy starters I have included some introduction video's for you: