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?
Oldest comments (37)
Bun is in beta, so... Have you considered using experimental HTTP server from deno, they're claiming it to become 3x faster? deno.com/blog/v1.25#new-experiment...
Ya! Latest benchmarks use that github.com/BuilderIO/framework-ben.... Note tho that what they optimized was the HTTP server, but this tests the performance of a full application which will mostly be impacted by the other business logic and react components rendering. That said tho Deno moved up a bit from the latest beta server
Sorry, I am still a bit confused. Could you please share results both for Deno 1.25 in normal and experimental mode? If I got you right, using smth like real-world-app shows no performance gain. May be this is due to the fact, that in experimental mode Deno is only capable of http/1.1, which is not important for hello world app... and it still outperform http/2 web server for a full fledged app...
Here are the results before and after - before is on (I believe) Deno 1.24, after is on Deno 1.25 with experimental mode github.com/BuilderIO/framework-ben...
But what I’m trying to say is the server speed is not usually the main bottleneck for a real world application. Most CPU cycles are spent on the business logic of the application, rather than the details of the server implementation
All that said all of the code is open source so you are more than welcome to replicate the results yourself too in any way you like and/or send PRs for feedback and improvements
Deno and Bun are almost twice as fast as Node for your app... with no change in business logic for all cases. So your results do not support the claim, that "Most CPU cycles are spent on the business logic". Is it possible somehow to profile, where main CPU power really goes?
Not ideal for whom? Some of us like that kind of work environment. You act as though there is some ethical code is being violated. Is there a new ethic against hard word and long hours now? I missed that memo.
Thanks for sharing Steve, I will definitely keep an eye on Bun!
It is an awesome tweet for a company which have all chances to influence the future. Same to "There are way easier places to work, but nobody ever changed the world on 40 hours a week""
Well, Brendan Eich changed the world in 10 days with JavaScript.
Agree, but in which direction 😅
Work ethic(s), there’s irony here. It’s not a company, it’s a startup, I’m sure equity is part of the package.
I mean, I am open to any opinions that earn respect. One that attempts to justify corporations demanding free labor is not one of those.
Hi, I tried to create the next.js app with bun last week but it doesn't work correctly. Also after creating next.js app w/ bun, the project is not directly compatible with yarn/npm.
Some may not see it that way and they’ll be the ones to apply. Is it not a good thing that the company disclosed their expectation publicly?
Oven is one person. He’s trying to start a business and setting expectations is perfectly valid. If someone isn’t willing to work long weeks, then surely they won’t work there.
Mandatory overtime isn’t exploitation. Nobody is being forced to work there, and it’s not slave labor. Some devs want the extra money from working overtime.
When it gets stable, deno will switch to webkit javascript core too. very shortly deno will have full npm support. so why not stick with what is stable. And it will get drastic stable speed increases going forward
But I do wish bun the best of luck for quick stability. deno needs this speed improvement too.
No one needs really needs the bun language. doesn’t seem like rust motive for security & stability (took me a while to think about rust over C)
I tend to consider these work practices to be self-destructive (I don't actually have any proof what I say, and just the unethical part of such claims should suffice). I wouldn't put my trust into the long term support of a product made by a company with a self-destructive behaviour.
However, as I'm pretty new to JS runtimes, I didn't knew about Deno, so as this whole post put the spotlight on it, I'll definitely look forward to it!
Some comments may only be visible to logged-in visitors. Sign in to view all comments.