Bun 1.0 was released. And again, the JS ecosystem did what they do best – fell up into hype.
I actually have no idea why this happens so much in JS world; maybe it’s a lack of maturity (I mean, Ruby also did the same in the past, then they figured out it’s not always a good idea to throw away everything when a new stuff appears), maybe it’s something else; maybe people are just desperate to have something better in the JS world – who knows?
Anyway, I decided to do some benchmark tests. I was already not impressed, because I did test Bun in the past, but let’s see what happens with this new version:
All these tests are running in my local machine; because I do lots of ClojureScript development, I basically decided to test my own code with it – mostly Orbit and Duck-REPLed. I would love to also test other stuff, like Tango / REPL-Tooling, but these require Electron so Bun will not help me here. My machine is a Core i7-11800H, with sufficient RAM, running Ubuntu 20.04.
So, without further ado, let’s run all tests in Node:
Duck REPLed:
The full suite runs in about 10.9 seconds in Bun. User time was about 6 seconds, System time, 0.6 seconds. That means that the whole command took 10.9 seconds, the time spent in CPU was 6.1 seconds, and the “overhead” that CPU used for I/O was 0.6
In Node, however, the full suite runs in about 8.6 seconds. User time was about 3.4, and System time, 0.2. It basically means that Node.JS handles the CPU 2x faster than Bun, if I understand correctly what User and System time means.
Orbit
Things are even worse for Orbit: Bun runs the test suite in 6.5s (on average, sometimes it took 7s, sometimes 5.6) with User time at 6.5s and System time at 0.23s.
In comparison, Node runs the same suite in about 3.3s, with User time at 3s and System at 0.13s – which in this case, translates to “Node is twice as fast as Bun”.
That would be the end of it, but there’s a catch: I am running these tests with Node 16. In the Orbit project, if I do run my suite in Node 20, it takes 2.9s / 2.7s / 0.11s, which makes things even worse.
Conclusion (is there one?)
There’s much to be said of a tool that’s “better and faster in every way” than other – usually, it’s a lie, or it’s measured by microbenchmarks, or it’s simply wrong. As an example, in the old Ruby days it was known that JRuby was faster than the official C-based Ruby implementation by all benchmarks – unfortunately, when running Rails, it was way slower; the same happened with the old Maglev implementation of Ruby.
Bun makes a lot of bold, and weird claims, for me. On their official release blog post they mention “not needing npx because bunx is 5x faster”. That… may be true, but npx is insanely fast – on my machine, running npx shadow-cljs --help takes literally 350ms to show the help for shadow! Is bunx faster? Sure it is, it runs in 160ms on my machine (again, not 5x faster, but who cares in this case?) but usually, your bottleneck will not be npx – ever! They also mention that you don’t need tsc, but you can “keep for typechecking” – so you’re saying that I can write all my code in Typescript, with all the boilerplate for types, and Bun will read them for me but won’t typecheck – so I can get all the problems with static types without any of the benefits? I fail to see why anyone would want to do that.
It also mentions a lot of other tools, and I ask – which versions of these tools? They all got incompatible with themselves when they bumped their versions, so what does that mean? Will bun support the older config files, or only the new ones? The former, while the right way to do things, contradicts their blog post, which mentions that the problem with Node is that layers and layers of tooling have accumulated on top of each other; the later is a maintenance nightmare – imagine that, if you want to upgrade a library, you also need to upgrade the language – Bun, in this case – and that triggers an update of the Babel config files, and the Bundler files, and the test config files, and that will need changes on the test code… eventually, you are upgrading everything, adding entropy to your system, without any solid ground to say “hey, at least I can guarantee this works” because you had to change everything.
Can you imagine working on something like that? You don’t have to – we already have Rails. Ask anyone how easy is to bump major versions in Rails – and be prepared for tears…