Love it or hate it, the JavaScript tooling landscape is the subject of a lot of chatter yet again.

The latest: Bun. A new JS runtime focused on performance and being all-in-one (runtime, bundler, package manager, transpiler). So think of it like Node.js, plus NPM, plus tsc, plus rollup - but faster.

It makes big claims, such as being 3x faster at server-side rendering React. So, we put it to the test.

What makes Bun fast?

The Bun team attributes their performance to a few things:

• Tons of time spent profiling, benchmarking and optimizing
• Using the Zig language for it's low-level memory control and lack of hidden control flow
• Using JavaScript Core, the engine inside of Safari, instead of V8, the engine inside of Chromium

So, is it faster?

We chose to dig into this specific claim from Bun.sh:

At first look, wow! But then I imagined my Next.js site suddenly being 3x faster... and just frankly found that hard to fathom.

But who knows, so I dug in. The first thing that stood out to me was the source code of the benchmark. To put it shortly... this is not the most "real life" example of a React app to server render.

I don't know about you, but every time I've server rendered React for a real app - theres a lot more going on. A much larger component tree with business logic, libraries, props, state, context, etc.

So I made a more full fledged React app, and decided to run some benchmarks.

Methodology

I created a dashboard app in Mitosis (source). It has a full tree of components, business logic, dependencies, uses props and state and other typical React features.

Mitosis was chosen so that we can generate code for many frameworks to compare their performance in this more "real world" oriented app, as well as variations - such as React vs Preact, CSS vs styled-components, etc.

I created a basic app with Node.js, Deno, and Bun. To more closely attempt to replicate Bun's results, note that we used their custom fork of react-dom/server.

I at first wanted to avoid this, but Jarred (the creator of Bun), made a good case for platform-specific implementations of react-dom/server is already a thing (such as browser vs node specifically), and likely will continue to be. They intend to merge this into React core ultimately, so we will cautiously optimistically assume this is on the horizon.

We then used autocannon to measure the throughput (requests per second) of each runtime server-rendering our React app.

So, what were the results?

Running on my 2.6 GHz 6-Core Intel Core i7, using Bun version 0.1.10, Deno version 1.25.0, Node.js version 16.14.0 my results were:

┌─────────┬──────────────────┬─────┬─────┬─────┬───────┬─────────┐
│ (index) │       name       │ 1%  │ 50% │ 99% │  Avg  │ Std Dev │
├─────────┼──────────────────┼─────┼─────┼─────┼───────┼─────────┤
│    0    │ 'react-ssr-bun'  │ 500 │ 669 │ 718 │ 650.8 │  71.7   │
│    1    │ 'react-ssr-deno' │ 550 │ 600 │ 630 │  601  │  20.89  │
│    2    │ 'react-ssr-node' │ 267 │ 375 │ 394 │ 366.5 │  35.04  │
└─────────┴──────────────────┴─────┴─────┴─────┴───────┴─────────┘

View the full source for the benchmarks (and let me know if you see ways the methodology can improve).

In this, we are seeing Bun handling about 75% more requests per second than Node.js, with Deno falling in between (closer to Bun than Node).

I have to say, I was surprised. Yes, it's not 3x faster - but it is in fact faster by a healthy margin.

So, should I switch to Bun now?

Well, probably not. It is currently in beta and not production ready (with many users reporting that there are notable bugs). But it is likely worth keeping your eyes on.

I have to say, using the Bun CLI in particular feels very snappy.

Installation in particular feels so fast I have to double take to confirm to myself that it actually happened.

To me, this is one of the more exciting areas of Bun, considering how slow even Yarn can be in my experience for medium to large projects.

But, this is just one person's results and opinion. What do you all think?