Bun: A Hot Take
As predicted last year, a trend is emerging around the creation of custom JavaScript runtimes. At first, it was just browsers. Then there was Narwahl. Then there was Node.js and lesser known runtimes like Vert.x. Today, the world has Cloudflare Workers, Deno, and now Bun.sh.
Bun is a new JavaScript runtime promising greater speed than existing runtimes. The current benchmarks boast impressive comparisons for serving web content, interacting with SQLite, and supporting Foreign Function Interfaces (FFI).
Node.js, Deno, Cloudflare Workers, Chrome, Edge, Opera, and the Brave Browser are all based on the Google V8 JavaScript engine. These runtimes leverage V8 Isolates, which are a single unmodified instance of the V8 JavaScript engine. The engine itself interprets JavaScript code, but functionality is limited to the ECMAScript specification. Most of the capabilities developers are familiar with are actually part of separate libraries bolted onto V8 Isolates. Browsers add Web APIs, which provide familiar functionality like console.log. Node.js adds libuv, which provides the access to the file system (fs). Deno uses Rusty V8 and Tokio, while Cloudflare added their own caching library.
Everybody Likes Speedy Software
Like other JavaScript runtimes, Bun adds its own APIs. Unlike other runtimes, it is built on JavaScriptCore instead of V8. JavaScriptCore is known to start up a little faster than V8, which shaves off latency (a key factor in serverless environments). It’s also written in Zig, a low-level language with manual memory management. By handling memory manually, authors have more control over the performance. The Bun team has spent a lot of time optimizing the runtime using these tools.
Something For Everyone… almost.
A particularly interesting feature of Bun is support for node modules (Common JS/CJS) and ES Modules (imports/ESM). By supporting both of these approaches, Bun developers can use a large ecosystem of existing libraries, regardless of their preferred approach to development. Node.js supports both of these approaches as well, but not simultaneously. Deno only supports ESM. In this regard, Bun advances the JavaScript community by eliminating a painful choice.
Update: Deno now supports npm modules.
Bun also supports TypeScript and JSX out of the box. It contains a native test runner (similar to Jest). It supports an environment file concept (loads .env files into environment variables). It has an alternative to npm, which runs “20X faster” according to the Bun website. There are a lot of features, but many are opinionated.
Personally, I don’t like Jest-style tests. I don’t use JSX. I’m not opposed to TypeScript, but it’s not a part of my everyday work. Bun looks like it is tailored for working with server-side React, which I don’t really find myself doing. Whether you share my opinions or not, Bun is opinionated and I’m proof those opinions aren’t universally held.
A Lost Audience
There is one very notable missing piece for Bun. It doesn’t support Windows.
Contrary to some assumptions, Windows still has the dominant market share for both personal and professional use.
Over the years, macOS and Linux have gained market share, but excluding a major operating system eliminates an enormous part of the market. One of the primary attractions of JavaScript has historically been the fact it is cross-platform.
Bun is new and JavaScriptCore is supported on Windows, so perhaps Bun will support Windows at some point. However; it’s clear the Bun team has its work cut out for them.
It’s possible to make Bun work on Windows, but can it live up to the promises it makes on Windows? Bun relies on fast I/O, which is a function of the operating system. If the same I/O boost cannot be achieved on Windows, then Bun may not be able to keep the promises it makes.
Bun vs Node/Deno
Bun claims to be a drop-in replacement for Node or Deno, but it’s not.
Lack of Windows support takes this out of the running as a drop-in replacement, but there are other factors. Node and Deno can both produce executables (see JavaScript Executables). Deno is embeddable. These differences won’t affect everyone, but they will affect many.
From this author’s perspective, Bun is more aligned with runtimes like Cloudflare Workers. Workers are a closed server-side ecosystem, designed for a particular use. Bun could be used to build a faster server-side JS worker environment where the use cases are restricted to web development or APIs.
Bun could also serve as a build tool for developers. The native support for most development workflow challenges makes it ideally suited for this on operating systems Bun supports.
Should I Use Bun?
Bun is new and has some cool features. The sheer effort that has gone into it is admirable. It is another example of how the JavaScript ecosystem continues to accelerate its evolution. For that reason alone, I will experiment with Bun. There will be use cases where it will be the best choice. However; there are substantial hurdles remaining to determine whether Bun will be able to broadly support the types of needs many JavaScript developers have come to expect from runtimes.
If you’re building your own serverless/worker environment, or if you work with React a lot, Bun may be a really good fit.
When determining if Bun is right for you, you’ll probably want to consider long-term project viability. Open source projects of this scope are demanding of resources, time, and eventually money. Node.js has a firm foothold and reliable support in the market, which took about a decade to establish. Deno has raised $26M across two funding rounds, and operates under the guidance of many original Node developers (including Ryan Dahl). These folks have learned a lot of lessons along their decade-long journey. Cloudflare has a $16.8B market cap. It’s great to see Bun being accepted into the JavaScript ecosystem, but will the project be able to generate enough support to remain viable as an open source effort in a crowding market? Is it too niche? Not niche enough? Time will tell, but Bun is definitely worth keeping an eye on.
Conclusion
I am impressed by the engineering efforts that have gone into Bun. However; I see it following the same path Node.js did, leveraging a lot of early opinions that may fall out of favor rather rapidly.
It’s a very young project, so the sheer fact it is being compared to these other efforts is an accomplishment on its own. Personally, I’ll experiment with Bun and keep an eye open for scenarios where it fits into my development, but I don’t plan on building anything substantial with it until these questions are answered.
UPDATE: August 2022
Bun just announced a new company, called Oven, with a fresh $7M in funding. It’s backed by the usual suspects, including folks like Guillermo Rauch (Vercel)… who also backed Deno. I point this out because both angel and venture capital seem to be jumping into the JavaScript runtime arena. Many VC’s will invest in several (or sometimes all) of the competitors within an industry, in order to increase their chances of one of them going big.
That said, funding will definitely help increase the pace of development for Bun. However; as Nicholas C. Zakas points out, Bun hasn’t yet done anything new or innovative, whereas Deno has.
More content at PlainEnglish.io. Sign up for our free weekly newsletter. Follow us on Twitter, LinkedIn, and Discord.
