Is Bun 'Actually' Faster?

So again, welcome to React Advanced London, and you're here with Devlin Dudula. That's me, and I prepared something for you. It's about bun. Is bun actually faster?

OK. So to give you a little information about me, an overview, so I'm currently based in Oslo, Norway, living here for five years now, originally from Manila, Philippines. And during the pandemic, since I cannot go home, I decided to spend my time writing books and then co-authored some.

And the agenda today would be what is bun? Features of bun, like package manager, test runner, bundler, runtime. We're going to do benchmark, right? But you have to take it with a grain of salt. I'm going to explain why a bit later. And then there will be a demo along the way. Then key takeaways. OK?

It's going to give us a better developer experience, better DX, in short. Going to enjoy the development. The CI will be faster. It's going to run quick, saves us money. And if a bundler is efficient in decreasing the file size of the app, going to have lesser download time or lesser data for your users. That saves money, right? But actually, the direct impact of this to the environment is, it slows down global warming because you have lesser electricity to consume or lesser computers to consume. Because everything is fast.

So why did the creators of bun choose to build it on top of Zig? So Jared, the author, said mainly because of its readability and easy to understand nature of the programming language, which helps him to write a performance code. Here's an example code of Zig. Let's say you want to create a function that calculates the square of a number. But instead of doing it while your program runs, you want to figure it out before your program even starts. And with this comp time, you can tell Zig to calculate the square of a number when the program is compiled, and not when it's running. This means your program already knows the result before it even starts making your code faster and efficient. So by building bun on top of Zig, the creators have made a choice to prioritize performance, stability, and compatibility. And that's exactly what we get with bun, a modern JavaScript runtime that's built for speed and ease of use.

How to install bun? You can install bun by running the command npm install dash g bun. Alternatively, you can download the binary from the official website and follow the installation instructions. Now let's dive into its powerful features. So bun is more than just a JavaScript runtime. It's a comprehensive development toolkit that includes a package manager, bundler, test runner, and runtime. Let's take a closer look at bun's package manager. If you go to bun's website, you can see the result of their benchmark. And of course, as a best practice, you should have a validation about this, or we need to find evidence on how they do this. So bun's package manager is designed to be faster and more efficient than these alternatives. That's their take, while still providing the same level of functionality and compatibility. Benchmarking tools is not simple when you're, for example, measuring how fast a tool is. So that's why most of the time, we don't trust benchmarking because incomplete features of the tooling affects it. Some authors prioritize a feature than the other, and then they're going to be mismatched if you're using different tools because some have features, these specific features, some have not. Different ways of using also scripts, libraries, frameworks, it's going to be specific. Using different flags, they have different flags, right? Different machines also affects it.

Using different flags, they have different flags, right? Different machines also affects it. So, you know, benchmarking might be useless. But we are here to learn how you can run some CLI commands for benchmarking, and what you need to know. Here's how you can do benchmarking on your own using Hyperfine with some flags. You can install this with your Mac, Linux, or Windows with WSL2. And here, we're going to be comparing yarn, the version 4, you have PNPM, NPM, and then bund.

So basically, this is prepare here, this flag prepare means you're going to run a command before we run this install installation. For example, deleting node modules. Warm up means you're going to run it once to get cache and use cache. And then this runs here, dash runs, means how many times you want this to run. Like, for example, 10 or 3. And this is going to take, as you can see here, meaning there will be like 10 yarn install, 10 PNPM install, 10 NPM install, et cetera. And it will just get the average of it. But you can just use one if you want to really do it quickly. I'm going to do demo here. And actually, I've run it already. As you can see, bond, NPM, NPM, here are how long it took for NPM to complete it, bond, NPM, yarn. And then you got this summary. Normally, the one will be the winner here on top and then comparing it to the rest. For example here, bond, one. So it says here bond install run 3.73 times faster than yarn, 3.8 times faster than NPM, and then 4.93 times faster than NPM. What are these libraries? So this is just here, a medium size JavaScript application.

So that's how you going to do it. And this will be actually, this repo is public. You will see it later. And you can check and copy things here. And then I put everything here like how to get started with hyperfine, what tools you need, what should be installed in your machine. So bond, it's fast. But what are the things that we can do with this package manager? I will just show you a few things from bonds package manager. You have this bond install, add, remove, update, link.

You have this global cache, workspaces, lifecycle scripts, overrides and resolutions. So these are just common commands that you will find in package manager.

Now let's move to the test runner part of the bond. I'm going to use again hyperfine. And we're going to test it against vtest and jest. You can see here hyperfine, and do warmup and run them three times each. So that would be for tests. As you can see here, and we have a readme file for you to see what you need first. You might need typings here, by the way. So and these are just the same code. The difference is how do you import them. Because for example, in vtest, we need to import from vtest. I name it apple, so that would be like from vtest. I name it apple, so it would be like it's easy to run and distinguish. So that's going to be for vtest, the apple. Bond for banana here. So you're going to import it. Basically the same test. Orange would be for the jest. And just going to run it. And here, again, hyperfine warmup. I'm just going to wait. And first would be running vtest. Second would be bond test. And then last would be jest here. And we have the summary again, meaning it's already done, finished and says here bond test banana. So we know bond test. Then it says here, we have this 37.77 times faster than vtest and 56.44 faster than jest. But what about this 3.49 and 3.86? These are margin of errors that if you do it 3.49 more, times more, the data might be different by the time.

But what about this 3.49 and 3.86? These are margin of errors that if you do it 3.49 more, times more, the data might be different by the time. So this is just a figure that it can be different results whenever you run these tests. So that would be for test runner part of bond. Let's go back to the slides. So you can do a bunch of things with bond as a test runner. It is fast and has built in jest compatible test runner and tests are executed with the bond runtime and supports these features. You know, writing tests, use what you have learned from jest. Tests are written in JavaScript or TypeScript with a jest-like API. You can describe, test, async. You can also have watch flag for running tests. Lifecycle hooks like before each, after each. You can do set up and tear down anything you want before all, before each, after each, and after all. Create mocks with mock function. Looks like this.

And now for the bundler part. Bundlers also help in framework features. Bundlers enable framework specific features like file system routing, code collocation, and server components through plugins and code transformations. In short, bundling is essential for efficient loading, code compatibility, and framework functionality in modern JavaScript applications. Here, they have their own benchmark, you know, bundling 10 copies of 3.js on scratch with source maps and minification. And this is going to be our own. I'm going to use hyperfine again. We have prepare removing some cache. And this will be like parcel, roll up, ES build, bun, RS build, and then webpack using webpack-cli. And there's so many things here because I need to be explicit with which folder the output will be generated or the dist. So, let's go back to our IDE, our VS code. Going to be here. And it will all, again, give you some details of which one to install. Like parcel, roll up, ES build, bun, RS build, then webpack. Then running this. Hyperfine.

But again, sorry. Before we're going to run it, I'm just going to show you what type of code is here in this main.js. It's just Fibonacci. Very simple. Again, that's why it's hard to trust benchmarking could be depending on who's doing or writing the code. But I'm here again to teach you what tools you would need, what to remember, and we're going to run it.

So, just going to generate two directors here, the dist and out, because different bundlers use different director names. Then I'm going to move it here so you can see. Parcel is done, roll up is done, ES build is done, bun is done, RS build is done, webpack is done. Says here, bun, main.js. Again, bun is a winner here and says it runs 1.00 times faster than ES build. It's almost the same. 10.60 times faster than roll up. 36.63 times faster than RS build. 40 times faster than parcel and then 100 times faster than webpack. Okay.

So, let's take a look what different supports we can get out of the box from bun. This is using CLI or using JavaScript. Like this. And for loaders, these are default loaders both for bonding and also during runtime. You can write your own plugin. For example, something that does CSS extraction, macros and client server code collocation. Right? And in programming, both zigs, comp time, and buns, macro system are designed to perform computations at compile time rather than at runtime. However, they operate in different contexts and are used in very different programming environments. Here's a simple function that returns a random number. And then, you know, here you have to consider macros are indicated using import attribute syntax. If you haven't seen this syntax before, it's a stage 3. The TC39 proposal that lets you attach additional metadata to import statements. And you won't see the code of the random function in the bundle output because it was executed during the bonding. I can do a demo here really quick.

About these macros that I'm talking about. So, we have mat random. And you have this console here, right? And then I have here also again what run. Going to output. And as you can see, comparing it with a export function random that returns mat random. Going to main. You can see it here, right? Going to main. You can see it here, right? The problem is, I think this is heavy. It's still included here. What we're going to do is to include this type macro. See here. And then you have to change something in your TS config file module. Yes, next. Let's go up and look for the module. Let's go up and look for the module. Go back here. Then run it again. So, just going to optimize it for you once you have it. Okay.

I think we're running out of time. So, run time. So, for the run time part of Bonn, Bonn uses the JavaScript core engine developed by Apple for Safari, which outperforms V8, and in most cases, additionally, it's a transpiler runtime built with Zig, resulting to four times faster startup times on Linux compared to Node.js. And there's a few of what you can do in Bonn's runtime. You can execute TypeScript, SX files directly, Bonn automatically processes your ENV files, no need for any library, like .env and a lot more. We don't have a demo here for run time, but you can still go to the public repo of this demo and see the instruction there, how you can do it. I prepared something there, but unfortunately, we don't have time here.

So, key takeaways. Reduces CPU usage and continuous integration. Installing node dependencies is fast, running tests is fast, and bonding is fast. And resources here. Go to Bonn and ZigLang website. And if you want to use also a JavaScript framework using Bonn runtime, you can go to liciajs.com and this demo here, this whole benchmarking. And, yeah, thank you for listening Bonn and simple things that you can do for benchmarking. That's all. Peace out.