The following is a take on the recent Bun disruption in the Web development ecosystem. It contrasts the benefits that Bun provides with the cons of being an almost solo development product.

https://blog.pragmaticengineer.com/bun-lessons-from-disrupting

Two weeks ago, a JavaScript runtime and toolkit called Bun was released and took the Node.js world by storm. Bun was mostly built by Jared Sumner, a former Stripe engineer, and recipient of the Thiel Fellowship (a grant of $100,000 for young people to drop out of school and build things, founded by venture capitalist, Peter Thiel). Bun has other contributors, but Jared writes the lion’s share of code.

Bun is a backend JavaScript runtime that is an alternative to Node.js and Deno. Its top focus is performance, and according to benchmarks shared in the launch video, around 10x performance increases can be observed when building packages, running code, or handling inbound requests on a server. This theoretically reduces the hardware requirements of applications.

Bun has stirred up the JavaScript space, and adoption has been rapid. Vendors like Vercel and Replit added support for Bun, as did frameworks like Ruby on Rails and Laravel Sail (PHP.) Many developers are giving Bun a go. Of course, it’s early days, but Bun keeps improving rapidly.

But how is Bun so fast? Firstly, performance was the guiding principle, and the team made smart choices to achieve this, and also tradeoffs which need to be kept in mind. Smart choices include using a more performant JavaScript engine than Node does (Bun uses Apple’s JavaScriptCore, while Node uses Google’s V8,) and using the low-level programming language Zig. There’s also a large number of performance-centric optimizations like:

• Using tagged pointers to avoid the overhead of storing extra function pointers
• Additional steps to reduce memory usage by scheduling additional garbage collector executions
• … and many more which all add up

With performance, there are also tradeoffs. For example, in its quest for performance, when running ‘bun install’, Bun doesn’t check the network to ensure that locally cached packages are correct – even when specifying to use the latest version. Doing this would introduce seconds of latency, but also ensure correctness. The npm or pnpm package managers do this additional check and so are slower, though arguably more reliable.

Discovering these edge cases – and making sure they don’t catch you off guard – will surely be a learning curve for developers using Bun, just like with every new framework.

Bun showcases how the ‘innovator’s dilemma’ manifests in a tech ecosystem. The innovator’s dilemma comes from the book of the same title by Clayton Christerenses. The dilemma is this: a large, market-leading company has some motivation to innovate, but also a strong disincentive as well, because innovation risks undermining its existing products.

In the case of the Node ecosystem, Node is the innovator. In 2009, it was revolutionary and the majority of the JavaScript backend development community moved to this ecosystem. Now of course, Node has interest in innovating in all areas, including performance. But it needs to make sure performance improvements don’t break any Node users.

Bun has no such constraint. It begins with a clean state, and can ship something that works for, say, 90% of existing Node projects, and break the remaining 10%. This means it can make decisions which greatly improve performance, which Node doesn’t have the luxury of doing.

If it was not for the innovator’s dilemma there would hardly be any startups taking on large companies, or new frameworks which successfully challenge existing ones.

Bun also reveals the contrast between venture-funded open source and ‘community sweat’-funded open source. Node’s contributors are unpaid, and have been doing all work voluntarily.

I reached out to Yagiz Nizipli, who is the contributor who took on responsibility for performance work on Node. He confirmed Node has no funding, and no collaborator gets paid for their work on it. There are people whose company pays them to maintain Node for their own, company systems — such as IBM paying to maintain Node so that it stays compatible with IBM AIX — a proprietary Unix operating system designed to run on IBM® Power® servers. However, at the end of the day, it’s all volunteers like Yagiz who have been building Node for over a decade, helping it become the dominant JavaScript backend runtime. I tip my hat to all volunteer open source contributors and maintainers — both for Node, and for other projects. If you are one of these people: thank you!

This is in stark contrast to how Bun is funded. The framework is built by a startup called Oven, which has raised more than $7M in funding, which means the company can afford to pay all its contributors a market-rate salary, plus equity in the company.

Clearly, strong funding will create a much more focused team, and Bun contributors work on Bun full-time, while unpaid Node contributors work on Node part-time.

Venture funding comes at a cost, and the bill usually falls due later. There is barely anything to complain about in a startup like Oven paying people to work full-time on an open source framework like Bun. It’s a win for everyone; the community and the developers working on it full time.

In contrast, the goal of a VC investor is a financial return. VCs fund businesses they expect to eventually be worth a lot more than the value of their investment, and to be either sold, or go public. This means that in the mid to long-term, Bun’s funding needs to support a business. For most commercial open source companies, the approach tends to be to offer a managed, dedicated service of the open source software, or to provide additional features on top of it.

This is the approach Vercel is taking with Next.js – where they are the trusted provider to host Next.js apps. In the case of Oven, I assume the plan is to do something similar.

Of course, not all startups succeed, and most startups which fail do so by running out of money. When this happens, the startup shuts down. In the case of a closed source startup, the software is also gone. However, with open source software like Bun, it will not go anywhere even if the business ceases to exist. The project would simply need volunteer contributors, or sponsors who pay contributions.

The license of a project is key to understanding how ‘risky’ it is to use. Bun uses an extremely permissive MIT license that minimizes any risk.

Technological innovation rarely happens in a vacuum; it builds on previous technologies. Node growing into a mature ecosystem is what enabled Bun to now take it by storm, and offer an alternative with superior characteristics – in this case, performance.

Youtuber and tech investor Theo Browne posted the most balanced take I’ve seen so far on what Bun means for the ecosystem. In the video The truth about Bun, he points out the risk of an open source project being dependent on an individual:

“Yagiz is the person on the Node team focused on performance. He is a part-time, unpaid contributor to Node, working really hard to make Node performant enough to be a viable choice (…) He’s the person thanklessly maintaining this thing (…)

For Bun, the majority of code is coming from the person (Jared) who also makes the majority of business decisions [for his company]. You eventually get to the point where these things conflict. Jared’s done an incredible job of managing this thus far: but he’s mostly done this by working absurd amounts of time. That is a risk, and we need to be real about this risk.

At Node, there’s great work going on from hundreds upon hundreds of people to make Node as great as it is. Node survived for more than a decade, because they’ve managed and mitigated these risks really well”

I’m excited to see such innovation in the Node ecosystem, because innovation begets innovation. What Jared and the team have done with Bun is outstanding engineering; they’ve shown it’s possible to push performance far beyond what most engineers would assume to be possible. By building Bun to be so ridiculously fast, they’re getting a ton of warranted interest and early adoption.

But this innovation also helps the wider ecosystem, as maintainers on Node and other package managers also jump to do performance optimizations for their tools, doing so with renewed inspiration.

It will be interesting to see the impact of more venture funding pouring into this space. Node was built by a team of volunteers, becoming an admirable framework, which is ever-improving, even without direct funding. This approach has proved to be sustainable, thanks to the hundreds of involved contributors. While Bun has incredible momentum: will this be enough to make it a sustainable framework and business?