Bun is a new project that aims to be compatible with Node.js but with significantly improved performance. Even less than a month after the public release, people are claiming that both the Node.js and Deno projects are dead.
Test Bun promises Node.js compatibility and faster execution
What does it take to “kill” a software platform? For example, people are still using COBOL, how many predictions are there for the demise of Perl, PHP or Java?
The Bun project claims that it will be compatible with the Node.js platform while offering huge performance benefits. If true, that could make many software developers abandon Node.js. But it will take several years to unfold. Node.js is in a very mature position, and the Bun project has a long way to go before it can completely replace Node.js.
But what happens when Bun is stable and mature enough to run complex applications currently running on Node.js?
I’m interested in evaluating whether Bun can run my application along with Node.js. I’m sure I’m not the only one with these issues.
These claims have attracted a lot of attention. I’ve seen a lot of people on YouTube doing simple performance tests and then they prove that Bun is much faster than Node.js.
Of course, a simple performance test doesn’t prove much. As I’ll say later, it’s a mistake to overemphasize simple tests.
This prompted me to try to run the tests of a complex application on Bun. That said, I’ve developed a static website generator system (Akasha CMS) that I use to create several websites, including techsparx.com and greentransportation.info. Akasha CMS is complex enough to provide good test scenarios. If Bun can successfully run Akasha CMS with higher performance, it will prove the Bun team’s claims. The idea was sound, but the results were flawed.
The purpose of this article is to revisit what I’ve tried and show some more carefully constructed performance tests. In the process, I found some bugs in Bun in the Bun issue queue.
Currently, Bun’s bugs and incomplete functionality make it unusable for running AkashaCMS. But I can use buns for portions. As we’ll see, this shows performance gains in some areas.
What is Bun compared to Node.js
The selling points of the buns are:
If the Bun team can take advantage of these selling points, I expect many in the Node.js/Deno community to turn to Bun.
But from a practical standpoint, Node.js has gone through 12 years of refinements, enhancements, and bug fixes. As we’ll see, Bun has a lot going for it. Any experienced software developer has likely used many different programming tools and platforms in his career. We’ve been reviewing what tools we should be using, and most of us are smart enough to see what the Bun team is making and know that they’re making some really big claims. I really hope these claims are true, but at this stage.
Bun can kill Node.js and/or Deno
There have been claims that Bun will kill the Deno and Node.js projects. The reasoning is what I just said: if Bun can implement all of Node.js with a high degree of compatibility, while maintaining a huge performance advantage, then they are the clear winners.
Because Bun includes the node_modules infrastructure, it has one major advantage over Deno. It’s hard for Deno to leverage the hundreds of thousands of packages available in this way. It’s a valuable resource we’ve built together, and Bun will be able to make the most of it.
For example, you can use npm install to set up the node_modules directory and then use it directly with Bun. The goal is to use a bun install with the same package. json to do the same thing, but more powerfully.
Bun will not be able to quit Node.js immediately. As we can see below, there are many missing features and many bugs that need to be fixed. And all the processes and logistical support needed to be developed to make Bun a self-sustaining project.
How will Node.js developers deal with a faster alternative that is compatible with the existing ecosystem?
The trap of simple performance tests
There are already several videos on YouTube giving Bun his first try. Every video I’ve seen shows them running some simple commands and saying wow, that’s so fast.
There is a well-known fallacy of oversimplified performance testing. Does running a simple script with Bun mean it is much faster than Node.js in a real application? This is the fallacy. Verifying that Bun is actually faster requires more in-depth testing than a few simple examples.
Bun’s existing performance tests
The Bun source tree contains many benchmarks. To run these tests:
I don’t have room to show all the results. But let’s look at the SQLite test:
This particular benchmark runs a SELECT query against an SQLite database. For Node.js, tests use better-sqlite, while deno tests use it.
By contrast, Bun uses its own implementation of SQLite, which is built directly into the Bun source code.
Those are impressive performance differences.
Bun’s incompleteness prevents deeper testing
My goal is to run larger applications to evaluate Bun compatibility and performance. In my case, the app is Akasha CMS, my static site generator for techsparx.com, greentransportation.info, and a few others. Akasha CMS uses Cheerio for server-side DOM processing, it uses different templating engines (mostly EJS and Nunjucks) and more. In other words, this would be a good case for testing Bun’s compatibility with Node.js.
However, there are a lot of compatibility issues:
The akasharer command uses Commander to parse the arguments and doesn’t work because the child_process package doesn’t exist. Commander is a very popular package for writing CLI tools in Node.js. The lack of the built-in child_process package prevents any tools built around Commander from running.
FWIW, the Bun issue queue includes (github.com) a roadmap for Bun that lists many things that haven’t been implemented yet.
I wish to only use Akasha CMS to evaluate Bun. Since this is not possible, the next best thing to do is to select parts of Akasha CMS for evaluation.
Text processing with template engines, performance and compatibility between Bun and Node.js
Akasha cms/akasha cms-perftest for performance testing of Akasha CMS. In the Bench directory, I intend to create some benchmark-like tests for specific features of Akasha CMS.
For example, consider :
The Bun project uses the Mitata benchmark execution framework. To help compare test results using Bun, I also used Mitata.
The first test is to evaluate text replacements in template strings.
The second is some scenarios using the EJS template engine. Both cases take an array of values and format that array in various ways. I have implemented similar code for several template engines as shown in the results below. The two additional tests are:
-Markdown-render, which uses the MarkdownIT package to process markdown. -Cheerio for server-side DOM processing using cheerio, a key feature of AkashaCMS.
The results show these performance differences:
Two points can be deduced from this:
1- I can't implement all scenarios on both Node.js and buns . 2- Cheerio has a significant performance boost test, it means little to others.
For some template engines, the combination of Mitata and that template engine caused segmentation faults. Scripts that only run the template engine without properly running the Mitata code.
In terms of performance, Bun shows a performance boost for scenarios working on both platforms. The increase in Cheerio performance is very interesting.
Chokidar exposes issues
Chokidar is a popular package for scanning directory trees and detecting changes dynamically. In Akasha CMS, it is used to notify when files are changed and to automatically rebuild. It plays a pivotal role and I wonder if there is a difference in execution time between Node.js and Bun for scanning a specific directory.
A test case is this:
This uses Chokidar to scan directories passed via the command line. For my tests, I scanned the node_modules directory to make sure there were a lot of files to scan. Chokidar emits several events based on what is happening in the file system being scanned. The ready event is dispatched when the initial scan is complete. We use this event to close the Chokidar instance and count the time.
This means that it can serve as a performance comparison between Node.js and Bun, but as we will see, Bun cannot run Chokidar.
But for Bun, the test fails:
This means that the Stats object returned by fs. stats does not contain the is Symbolic Link function. This feature has been around since Node.js v10.10.0 and should definitely be there.
As of this writing, Bun 0.1.5 has been released and the is Symbolic Link function now exists.
Unfortunately, Chokidar has a new bug.
In fact, we can verify that it doesn’t exist :
On Node.js it prints a Function object, but on Bun it currently prints undefined.