Skip to main content

A word about Bun 💬

· 3 min read
Maël Nison
Maël Nison
Lead Yarn maintainer

I'm sure many of you are curious about our position regarding Bun, the product from Oven, the company behind Bun (we're going in cycles). It's so fast, is there any merits to using Yarn?

First, we feel useful to point out that this sentence isn't particularly new. We heard the same (often from the same people) asking why use Yarn when npm/pnpm/whateverpm have all its features or outspeed it. Answering that is a little tough, because the premise is wrong: other package managers don't have its features12, and the speed differences are at best marginal. They are a good fight, but we believe Yarn ultimately has a unique position that no other package managers emulates today.

Bun is an interesting case, though. It's definitely much faster3. Can Yarn compete? We believe so.

First, remember today's iteration of Yarn was developed over the course of two years by a team already experienced in package managers. Those tools are fickle beasts, and many edge cases loom around4. Bun may be fast, but is it correct? That's something the community will have to figure out over time.

But stability isn't everything: the feature set is an important facet of what makes a tool appealing. The developer experience (which includes the user interface) is another. The governance yet another. Yarn stills fits its niche: a complete tool that empowers its users, advocates for good practices, isn't afraid to explore uncharted territories, and is protected from perverse corporate incentives.

With that said, I believe there's a couple of things we can learn from Bun. Yarn was always intended to be distributed as a unique JS file for extreme portability across Node.js supported architectures. With Corepack now being the preferred install strategy, does it still matter? Should we experiment with native modules for future releases, that Corepack would transparently fetch as needed? Bun proved untapped performances could be exploited.

Of course it's not just a matter of being native - Oven's work follows interesting code patterns, and I'm curious how much of an impact they have on the resulting speed (at the cost of increased complexity, and making contributions harder).

I always fought against the idea that one package manager was enough for every single project out there, Yarn included. Our users are engineers: they have different requirements, different priorities, and different sensibilities. I found Yarn the appropriate tool for my projects, but I'm sure Zoltan is perfectly happy with pnpm and Microsoft with npm.

Will Bun reach some of your hearts? More than likely. Will it be a replacement? I can't imagine that.

Footnotes​

  1. For example the portable shell, the constraints, the patching, ... ↩

  2. Or delegate to Yarn; did you know pnpm's hoisted linker is literally using Yarn as a dependency? ↩

  3. Although not as much as they pretend, which is a bit of a letdown. Marketing corrupts, eh? ↩

  4. Here be dragons. ↩