Thoughts on Bun

What is Bun?

Primarily, Bun is a JavaScript runtime, just like there is Node.js and Deno. While Node.js has seen amazing adoption almost about everywhere, it also has become a little long in the tooth. Even the creator of Node.js moved on to create Deno.

Mostly Node’s developer experience has been hurt, with the way node_modules are handled, now the module type transition (which seems to be Node’s Python-2-to-3 moment or dare I say period), or the perceived sluggishness setting in even with medium sized projects. “Perceived”, because we are not even in the ballpark of sluggishness of loading a medium sized Java project in Eclipse or NetBeans, mind you. Now that was sluggish.

Good thing a few youngsters haven’t had to experience this, thought Node.js was no good and now gave us Bun. Both Bun and Deno aim to correct a few design decisions in Node.js, though Bun seems to be focused way more on developer experience and how it can contribute to better day-to-day interaction.

To achieve this, Bun is more than just a runtime though. It has a package manager, a test runner and a bundler built in, all contributing to the positive developer experience, while trying to be a drop-in replacement as much as possible. Depending on your tooling, you may not have to change a single line of code, not even in your tests when using Jest. Combine that with a few extra Web APIs that are often used by Node.js developers in a streamlined way and you have a pragmatic, potential winner.

It checks the nerdy boxes

Not everybody will appreciate that Bun uses JavaScriptCore, which is to my knowledge the only tail-call optimising JS engine out there. It will surely allow for additional applications previously not possible, but makes Bun the only fully implemented ES6 environment thus far (aside from Safari and other WebKit browsers).

One of the most publicised features is its ability to run TypeScript directly which lowers the barrier of entry for TypeScript as well. Here Bun and Deno agree that this is the future. I sure hope that one day TypeScript is merely JavaScript with optional types and won’t require a transpiler anymore. I’m Switzerland on the discussion of the typing philosophies and see benefits in both. If anything, I prefer gradual typing.

Another, less known fact is that you can load Rust modules directly as if they were JavaScript modules (internally Bun is using its foreign-function interface). Speaking of JavaScript modules, Bun unifies the import of modules, so you are spared the current module transition pain.

Finally and I’m way too excited about this: it’s mostly written in Zig. If you don’t know Zig, on the surface you can think of Zig is to C what Rust is to C++. This is the first high-profile project to my knowledge that is using Zig ❤️.

Preliminary Thoughts

There are probably some popular features that I missed, but you can read about them in the announcement or watch the announcement. Yes they even did a polished announcement video. 🤯

Now it’s too early to see whether Bun will make a lasting impact in the JavaScript scene, but it will stir the pot for sure and light a fire under the other JS runtimes.

Its lightweight approach both in size and cognitive load is appealing to me. I dropped it into a few projects and sure enough it worked and even in smaller projects the shorter startup time was noticeable. One thing that didn’t work as advertised was the ability to run without installing. It should transparently install all dependencies and run, but failed at some packages. Curiously calling install manually and then running worked totally fine. But hey, it’s 1.0!

As I said, the featherweight size is appealing to me, since I’m currently working on a project that has similar goals of being simpler, smaller in size and lower in cognitive load. A lot of developers will appreciate it for this alone. It might also become a better way to teach JavaScript, since you can skip a lot of complexities of the ecosystem. This also makes it perfectly suited for engineers for whom JavaScript is a secondary environment and they can’t keep up with all developments of two or more language ecosystems.

One of the major downsides is that it currently is not really ready for Windows. The WSL port is a proof of concept at best. The Windows-based development community is pretty vocal about the lack of compatibility and we might see Microsoft contributing the Windows compatibility similar to how they contributed it to Node.js.

Even with all this excitement, you probably shouldn’t drop every Node.js runtime you might have running right now. Bun’s quality may be deceiving. Rather, you should add Bun as an extra environment to your CI, similar to how you’d add an upcoming version of Node.js, to see how your app is reacting. Bun is production-ready, but even the docs still have the following notice:

Bun is still under development. Use it to speed up your development workflows or run simpler production code in resource-constrained environments like serverless functions. We’re working on more complete Node.js compatibility and integration with existing frameworks. Join the Discord and watch the GitHub repository to keep tabs on future releases.

As The New Stack reports, Bun has already been adopted by Vercel, Ruby on Rails and Laravel in some capacity, in addition to some web frameworks already created for Bun specifically. The same article mentions the number of bugs being reported on the project, but that is also a function of this crazy adoption rate. At the time of writing this, roughly 600 bugs have been created since the release of 1.0, 25% of which have already been closed. Nicely done! 👍

I would not hesitate to use it for any kind of internal business app or tool. The built-in SQLite support makes it wonderfully suited for this case, because even in the most Windows-centric IT infrastructures, a Docker container is usually acceptable.

If you’re using JavaScript for scripting, small tools with quick turn-around time, Bun is excellent right now. I also “ported” a small-ish line of business app, literally by just doing bun install and bun run. Everything worked and since it was acceptable risk, we decided to deploy it. So far so good 🤞 . I will happily reach out to Bun by default for projects that require me to resort to JavaScript but it ain’t gonna replace Swift for me for my personal/internal projects.