My work day usually begins, in addition to a quick update from my colleagues’ lives, with a short survey of what’s new in the IT world. One of the topics I’ve been following over the last few months is the engine/all-in-one JavaScript runtime & toolkit Bun. Ever since the 0.3 version, it’s been talked about everywhere as the vanquisher of NodeJS. Is it really true? In my opinion, only partially.
Bun vs. NodeJS – what are the differences?
Before I start describing Bun, let’s remember what NodeJS actually is. It’s an environment that’s used to create and run modern applications written in JavaScript. It’s written in C and uses the V8 engine (and all its derivatives) to read and translate and it’s used in the Chromium browser. Its main advantage is launching concurrent requests.
Bun is basically something like NodeJS. It’s supposed to serve the same purpose, i.e. to write and translate applications created in JavaScript, but it has more instruments integrated in its base. I’ll come back to those later.
The first difference between Bun and NodeJS is that Bun uses JavaScriptCore as the engine, which is used in Safari. At the moment, I can’t say if it’s better, as its primary designation is smaller, but it’ll certainly show in the future.
Another significant difference is the use of the Zig language, in which the entire Bun is designed. If you’ve never heard of Zig, Rust is maybe more familiar. Zig is basically similar to Rust – designed mainly for security, multi-threaded, modern (but written more traditionally) and fully compatible with C/C++.
What extras does Bun have?
As I mentioned, Bun has some apps and modules built in to help developers streamline their work. I’ll highlight the ones that are most important to me personally:
- TypeScript applications: Bun contains the TypeScript transpiler already in the base, so no setup or debugging is necessary. If you have your own tsconfig.json, you can fine-tune the operation of the transpiler thanks to it, but if the normal settings are enough for you, it isn’t necessary at all. Simply create a file with the .ts or .tsx extension and go ahead.
- Development mode: Amazingly fast -watch mode that instantly translates any application, and -hot mode for quickly rendering changed parts.
- package.json: Full support for package.json file and node_module folder.
- Tests: Bun supports writing tests already in the base. The syntax is compatible with Jest, it runs fast and there’s also support for snapshots.
- Compatibility: Bun is almost completely compatible with applications written for NodeJS. It uses the same JavaScript and the API and a large part of the most commonly used NodeJS commands are also supported. Already there are plenty of tutorials on the Internet on how to migrate or test your apps from NodeJS to Bun. It’s worth a try.
Comparison by practice
I won’t uselessly describe the common tests on the hello-world demo here. I prefer to share my own experience and my feelings tests from practice. I found that:
- Greater performance is noticeable on all fronts – in application launches, tests and especially in the -watch mode in development. Here I would even describe the difference as brutal 🙂
- Already in the base, Bun is prepared for great scalability and parallelism. It can handle 2-3 times more requests than NodeJS in general. However, the question remains as to what the stability will be.
- Due to reduced code and optimization of RAM and performance, BUN doesn’t have a large variance on latency (the delay between the user’s action and the web application’s response to that action). It ranges somewhere between 0.5-10s, while with NodeJS these values are around 0.05-100s.
- Bun uses slightly more RAM, but less CPU than NodeJS. This may be a stumbling block, but there’s still room for further optimizations.
Many large projects already have their test environments or test versions compatible with both NodeJS and Bun. So you practically just have to choose.
Could there be a catch?
I see the problem mainly in the fact that Bun is still new. In the IT world, you often encounter exaggerated enthusiasm for something new and revolutionary, but over time it often fades into dust because of a security problem or because the developers couldn’t be bothered to improve their creation further.
Currently, Bun’s greatest strength is that it’s a small library thanks to which it can work super fast. But this is only version 1.0. In contrast, NodeJS has already gone through 21 large cycles of repairs, improvements and most importantly, constant listening to the community and responding to its requests. Bun doesn’t have that yet – years of experience, failures and mistakes. I wouldn’t like to see this hopeful library gradually slow down due to redundancies or the stacking of fixes.
Who knows, maybe in the future there’ll be another “vanquisher” that’ll stand against both Bun and NodeJS. Nevertheless, I think that the “good old” NodeJS will still be with us in 10 years. After all, even PHP has succumbed to clinical death several times, but one successful restart was enough and the developer community is returning to it again.
