When Node.js debuted back in 2009, everyone was thrilled about the possibility it can offer. And I must say Node kept its promises.

We now have a universe-level ecosystem based on node which spans from server runtime to client-side toolchain as well.

Even node's original creator Ryan Dahl tried to build something better than node in his Deno. But after 4 years of its first release, we're yet to (about to?) see some notable momentum around it (yes, there's a brand new Deno fresh framework).

The main reason I believe why other runtimes couldn't topple the node's position is that nowadays Node.js isn't just a JavaScript runtime. Instead, it's tightly coupled with almost every JavaScript-based framework and toolchains.

Let me explain what I mean and our current problems in the JavaScript ecosystem.

A Node.js server-side application or SPA client-side application nowadays has bundling, transpiling and task runners integrated with them. What are these anyway?

Bundling

JavaScript doesn't compile to binary. So in an actual project, where it may have a couple of hundreds of files or more, files need to be deployed as JavaScript files to the server or served to the browser.

The problem is: these files have spaces, new lines, etc. And individual file sizes can be unnecessarily huge (I am talking about kilobytes).

More of that, if we serve individual JS files to the browser, then the browser will fetch each file individually and it would take a huge time to load all of the required files.

Remember, depending on the browser, they can load max 6–10 files concurrently from the server. So imagine, if we have 300 separate files, then the browser needs to initiate the file fetching call 50 times (at least) just to load all of the files, then it can start the execution.

Yeah, I know, it would be overwhelming.

We all know a JavaScript runtime (or browser engine) doesn't need those many extra spaces in the code. So we had different types of solutions to optimize. If we merge all files into a big one and minify them, then it would be a massive gain.

A bundler is a software/package which converts the dev codes/files into minified and merged (bundled) output files. Most of the time these output files will have unique names so the browser will never face the caching problem and can serve always the new files.

In our current JavaScript ecosystem, we have multiple bundlers (Webpack, Rollup, Vite, Esbuild, etc.) and more are coming regularly.

So, as a developer, we often get confused about which to choose and more importantly how to integrate that bundler with the project. It is a tough decision for each project.

Transpiling

The need for type safety is always very important in a project.

Some languages tried to solve it with the expense of extra time to convert from other languages to JavaScript before execution.

This process is called transpiling. And again, we have multiple choices in the JavaScript ecosystem for transpiling.

Babel, TypeScript, CoffeeScript, etc are transpiler examples, and choosing them for a new project is always a hard decision.

Task runner

Another part we have in modern JavaScript server side and client side projects is a task runner.

A task runner is a tool that manipulates the source files or runs commands and does a variety of tasks including but not limited to minification, compilation, unit testing, linting, etc. repetitive tasks. And again, we have multiple options notably Grunt and Gulp.

The problems of maintaining a big project

The changing speed of the JavaScript landscape is very fast. It becomes a nightmare when a package becomes obsolete/not maintained or has breaking changes which will cause unnecessary overhead in the maintenance. The main reason I found is the disconnection between the packages.

For example, suppose Package A introduces a new breaking change and uses the latest version of Package B. But in our project, we need to upgrade Package A for whatever reason, but if Package B is upgraded then it will break our software in production. So dev teams need to allocate extra time in up-gradation (remember time equals money) without focusing on the business needs. This is a common scenario and I hope we all can relate to this.

Bun tries to solve these overheads in a single complete package which is needed by modern JavaScript projects.

Bun: A new kid in the town with a huge promise

Quote from https://bun.sh website:

Bundle, transpile, install and run JavaScript & TypeScript projects — all in Bun. Bun is a new JavaScript runtime with a native bundler, transpiler, task runner and npm client built-in.

So, if I understand correctly, by using Bun, we don't have to worry about the problems I mentioned earlier in this article. But what makes Bun special?

Again quote from bun.sh site:

Bun is a modern JavaScript runtime like Node or Deno. It was built from scratch to focus on three main things:

- Start fast (it has the edge in mind).

- New levels of performance (extending JavaScriptCore, the engine).

- Being a great and complete tool (bundler, transpiler, package manager).

The current state of bun is quite promising.

If our project is not that complex and does not use many external node libraries, the bun runtime is supposed to work automatically in the place of the node runtime — especially, in the microservice architecture, where projects are smaller and independent from each other.

Or for the client-side projects (React, Next, etc.), I believe we can just drop it in or can integrate bun without much change.

Another quote from the site:

Bun is designed as a drop-in replacement for your current JavaScript & TypeScript apps or scripts — on your local computer, server or on the edge. Bun natively implements hundreds of Node.js and Web APIs, including ~90% of Node-API functions (native modules), fs, path, Buffer and more.

The goal of Bun is to run most of the worlds JavaScript outside of browsers, bringing performance and complexity enhancements to your future infrastructure, as well as developer productivity through better, simpler tooling.

For the rest of the features and explanations can see on the website https://bun.sh

My experiments and thoughts

Bun is branding itself in two aspects.

The first one is a All-in-one solution:

The second one is Faster JavaScript runtime than Node and Deno:

However, in the real world, there are more aspects than being fast because a handful of websites requires continuous hundreds of requests per second. So, to make it ready for mass adaptation, there are more features needed in Bun.

Mature server frameworks

Even after 10+ years of the first release, ExpressJS is still the most used server framework in the Node.js ecosystem.

Being ultrafast and low memory footprint are not the only criteria to be used in a real-world project. So, if ExpressJS (or Fastify) is not supported by Bun, we may not see enough usage in the future.

At least I would not recommend using any shiny new frameworks for real-world projects. I have checked and tested by myself (at the time of writing this article) that Fastify and ExpressJS are not yet supported by Bun. Hoping to hear something good soon.

Database drivers

Bun website shows the comparison using the Sqlite database. But in the real world, we see Postgres, MongoDB, etc. are dominant in Node.js ecosystem along with other RDBMS and NoSQL databases. Each of these databases has its own Node.js drivers so that devs don't need to worry about integrating databases into the project.

Below are my experiments and the errors.

Installing packages were fine

I could use bun add package_name without a problem and could install the express, fastify and mongodb packages.

MongoDB with Bun Code:

const db = require("mongodb");
console.log(db)

Here's the error we got:

error: Cannot find package "dgram" from "bun:wrap"

ExpressJS with Bun Code

const express = require('express');
console.log(express)

Error:

error: Cannot find module "./util.inspect" from "/Users/foyzul/fk/buns/blank-app-01/node_modules/object-inspect/index.js"

Fastify with Bun Code:

const fastify = require('fastify');
console.log(fastify);

Error:

TypeError: undefined is not an object (evaluating 'process.stderr.fd')

In the next article, I will show you my exploration of the current bun templates and will also share my takeaways. Thanks for reading.