Table of contents
Preface
Bun V1 has just been released, and it's on fire! 🔥
The overwhelming number of articles written about it, along with the buzz on Twitter, clearly indicate its current popularity.
The benchmarks are extraordinary, and it outperforms, well, everything! Here are just a few of the benchmarks:
As you can see, Bun is incredibly fast! ✈️ If you're curious about how it achieves these remarkable speeds, the secret lies in the technology used to create Bun.
It's written in Zig and powered by JavaScriptCore. I don't consider myself knowledgeable enough to discuss Zig in depth, so I'll leave that to more experienced individuals!
If you want to learn more about Zig you can check out Zig in 100 Seconds by Fireship:
Primeagen has created numerous videos discussing Zig, as well as articles related to the topic. Here's a brief summary of his perspective on it:
https://youtu.be/wxx5_Xaw7zU?si=aXdN_bnDmHebUwzk&t=1058
And when it comes to JavaScriptCore here is a sentence pulled out of Bun docs that describes what it is:
Under the hood Bun uses the JavaScriptCore engine, which is developed by Apple for Safari. In most cases, the startup and running performance is faster than V8, the engine used by Node.js and Chromium-based browsers. Its transpiler and runtime are written in Zig, a modern, high-performance language. On Linux, this translates into startup times 4x faster than Node.js.
Zig is fast, which makes Bun fast too, JavaScriptCore is faster in most cases than v8, which makes it even faster. It outperforms Node.js and Deno in many scenarios and it has some amazing benchmarks. Did you know that Bun can run over 250 tests FASTER than Jest can print its version number !?
Alright, so from all the things I have listed you might be thinking:
"This guy sounds like he's loving bun, why the article?"
Well, let's jump into the dark side of my experience with Bun v1.0.
Support
I should also preface this section by mentioning that I am a big fan of Linux OS, and I would love to switch. However, as of the time of writing this article, the support for applications and ease of use is just not there yet for me to feel comfortable switching. I use my desktop PC for games and personal tasks, and my wife uses it for her own needs. Additionally, macOS is not really well-known for its gaming capabilities.
My biggest pain point is the fact that Bun does not support Windows!
I know I could spin up VMs with a Linux OS, connect via SSH and work like that, or I could spin up a docker image or do a million other things to get a compatible working environment, I have worked for companies that had to use this approach and I optimized it to the point of being able to start up my working environment in under a few minutes but that is not the point, the point is that Bun should work with one of the most popular OS in the world!
And before you start saying stuff like:
Oh, who cares about Windows? Why don't you just use Linux or macOS?
Let me share something with you:
Windows is still the dominant desktop OS, but the dominance varies by region and it has gradually lost market share to other desktop operating systems (not just to mobile) with the slide very noticeable in the US, where macOS usage has more than quadrupled from Jan. 2009 to Dec. 2020 to 30.62%
If you want to read more OS usage stats you can do so by clicking here!
Even though macOS is popular in America, that doesn't make it popular in the whole world, I know that aliens always invade the US but we exist too!
The whole process of installing Bun on Windows looks like the following:
Install and set up WSL (which has gotten easier over the years but was a real pain before)
Install a Linux distro of choice from the marketplace (I went with Ubuntu)
Set up everything (create su etc.)
Run the
sudo apt install unzipcommand in your new terminal (which is not even listed anywhere on Bun docs, it is a simple thing if you know Linux but if you don't you would probably be stuck here googling on how to fix thisRun curl -fsSL https://bun.sh/install | bash after that.
Run
source /home/-username-/.bashrc
Alright, that seems pretty simple, right? Well, imagine telling someone who is just getting into development and really wants to try out Bun to do all of that. It would probably take them a day, if not more!
And also, how about telling that fresh graduate who just joined your company that you decided to switch to Bun and he needs to do all of this to have it up and running!
Performance
Alright, so you don't mind the entire setup process and believe it's manageable? Getting Bun to work on Windows isn't the biggest issue! The performance and usage are!
Disclaimer:
After publishing the articles many people pointed out that I was using the /mnt drive which is known to have issues and be very slow and that it's a known limitation of WSL. Most of the comments told me to try running it on the "~" path to see the real speed on Windows (you can find the related docs here: https://learn.microsoft.com/en-us/windows/wsl/setup/environment#file-storage)
So I went and created another repo in the Ubuntu distribution I was using and I added those results below as well!
Another thing I would like to point out that I really did not know about this which highlights another issue, most people who would like to try out Bun on their system will probably not know about this either because it's inside of WSL docs and if you want to use npm install/yarn install you don't have to know the internals of Windows WSL.
After getting it up I was so excited to try it out! I went into a project that has around 50-60 dependencies (including dev ones) and ran bun install, here are the results:
Disclaimer: This was using the Windows filesystem path which made it slower
It took 7.8 MINUTES to install the dependencies!!!
So, I usually work with Remix and I decided to try out building a brand new Remix app just to see how fast it would be so I ran bun x create-remix to get my Remix app running and the following happened:
After I entered the path the terminal froze, and I thought Okay, this might be some weird one-off thing it's just a simple select, it can't be Bun, I ran the command 2 more times and it froze in the same place!
Alright so I decided to try out a different approach, I ran bun x create-remix bun-app so the name of the app is already specified and that did the trick and I managed to get through it!
Awesome, now let's run bun install inside of the app and see how long it takes!
Disclaimer: This benchmark was also using the Windows path
Almost 3 minutes for a fresh project with almost no dependencies! 🤕🤕
Well, as many have pointed out I made a mistake here that I used the /mnt folder which is known to be slow so I created another repository inside the WSL Ubuntu filesystem because that is much faster on Windows!
Here are the results of that:
The path of the above:
PS Microsoft.PowerShell.Core\FileSystem::\wsl.localhost\Ubuntu\home\alle00\test
So as you can see, even with me using the correct path inside the Linux Distro it takes over 2 minutes to run bun install. Just to highlight the difference, running npm install took roughly between 5-10 seconds on both the Linux and Windows file paths.
Okay, but at least I can run my Remix App, right? RIGHT? WRONG!
Okay, so I can't run my Remix App, I guess I can try bootstrapping a Next.js app and see how that compares!
So, I ran bun x create-next-app bun-next-app to bypass the weird issue that occurs when you don't specify the name immediately. As soon as I reached the part where it asked if I wanted to use ESLint, BOOM, the process froze, and I was stuck once more! As of writing this, I am unable to bootstrap Next.js at all, and while I can bootstrap Remix, I cannot run it!
Okay, it's probably the fact that I'm running it with bun x, let's try using bunx which is the Bun equivalent of npx, let's try running bunx create-remix now!
Oh... so it doesn't even exist on Windows... well, okay, let me try something else then, the test runner, that's also what made me excited!!!
import { expect, test } from "bun:test";
test("2 + 2", () => {
expect(2 + 2).toBe(4);
});
test("2 + 3", () => {
expect(2 + 3).toBe(5);
});
I added the above code into the Remix bun-app that I created earlier just so I can test how it works and what happened. It broke, right? WRONG!
The test runner actually works on Windows! Although I can't say I thoroughly tested it. Check this performance out:
It ran and finished almost instantly, finally! The performance I was after the whole time! This was amazing to see!
But even this has a caveat, if you're using TS it complains that the types are missing, If you're running on WSL you can install it but if you're not you can't add bun as a dev dependency to your project so you would have to add @ts-ignore everywhere to get it to work without complaints from TS.
Due to the fact I can't run my application using Bun I can't really test and play around with their SQLite and web sockets or anything else at the moment so I can't write much about it. But I would assume it also has issues on Windows.
Adoption
The reason I highlight the poor Windows performance is for a very simple reason, adoption. One of the biggest selling points of Bun is the fact that it's a drop-in replacement for Node, but at the current time of writing it only supports 2 out of 3 systems Node supports. I get that macOS and Linux are very popular in the US and are growing in popularity in the world but bear with me here as I explain why Windows is important.
I come from a very poor country where owning a Mac is too expensive for 90% of people, most of them go for "value for money" and that is never anything that Apple sells.
Almost all IT Companies in my country go for Windows machines and laptops because they are just cheaper and give you better value for money and you can buy a laptop with better specs than a really good Mac for half the price.
Now imagine that you want to adopt Bun in one of those companies that have hundreds of employees running on Windows, You would have to first educate them on either WSL or Linux OS or VMs to get them to have a usable Bun environment. I am in no way saying those are bad things to know and learn but let's be realistic, Why would any company spend their time and resources to adopt it when they can just use something that's a bit slower but super simple to use like npm, yarn, Vitest etc?
What I am trying to point out is that it is possible to get a relatively working Bun env setup on Windows but it's not by any means easy or stable. Yes, I can set it up because I am passionate about Bun and don't mind installing WSL, or even dual booting a Linux distro with Windows or using a VM with HyperV or any other means. But I believe that that is too much to ask for anyone who is on Windows and just wants to go through the day, do their work and clock out!
Conclusion
Maybe I came off as not liking Bun v1 but that is not the case, I am REALLY excited about the future of the project and I want to see it succeed but as of writing it is completely unusable on Windows.
This was all written to demonstrate a clear issue that is not talked about in the dev community regarding Bun in good spirit, hoping the team behind it will be able to fix it soon.
I am looking forward to the day I get to be cool and run my 800 project tests in under 5s and install my dependencies in a few seconds, but today is not that day!
I would love to hear what you guys think about this, Feel free to comment and share your opinions, I would love to hear them!
Thank you
If you've reached the end you're a champ! I hope you liked my article.
If you wish to support me follow me on Twitter here:
or if you want to follow my work you can do so on GitHub:
And you can also sign up for the newsletter to get notified whenever I publish something new!