Software

Node.js and Amore test of Bun’s performance- More

Node.js

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.

To Smartphone reviews

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

Node.js and Amore test of Bun's performance- More

Node.js is a platform for running JavaScript applications on the server side. It hit the market in 2009 and made a big statement about how single-threaded, event-driven architectures can provide system performance advantages over often complex thread-based architectures.

Node.js is JavaScript that runs outside the browser. Since 2009, a vast ecosystem of tools and frameworks has grown around Node.js, including various software development tools, web application frameworks, database ORM layers, and even GUI application toolkits.

Bun is similar to Node.js, but different. Node.js is based on Chrome’s V8 engine and written in C++, while Bun is based on Safari’s JavaScript Core and written in Zig. You probably haven’t heard of Zig before you hear about Bun, and neither have I, but Zig claims a lot of advantages over other systems programming languages ​​like C++. Otherwise, Bun aims to implement the Node.js use case, which is designed to support running modern JavaScript outside of a web browser.

To Smartphone reviews

This is not the first attempt to run Node.js on a different JavaScript engine. There was an attempt to run Node.js on Chakra Core ((github.com) GitHub) a few years ago, but it was abandoned when Microsoft removed Chakra Core from Edge.

The selling points of the buns are:

1- Compatibility with Node.js includes direct use Bundles for Node.js (even  native    code bundles). 
2- Huge performance benefits: a) it's written in Zig, instead of C++, it has some advantages; b) under construction on the JavaScript Core engine. This is what the engine is supposed to do Faster than the V8 engine at the heart of Node.js and Deno.
3-It supports direct execution of TypeScript and JSX code.

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:

Bun's existing performance tests1

I don’t have room to show all the results. But let’s look at the SQLite test:

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:

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 :

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:

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:

A test case

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.

Using Node.js:

Node.js

But for Bun, the test fails:

But for Bun

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.

Chokidar has a new bug

In fact, we can verify that it doesn’t exist :

verify that it doesn't exist

On Node.js it prints a Function object, but on Bun it currently prints undefined.

To Similar Topics

To Shopping

To read and download free e-books