However, at its conception, NodeJS wasn’t designed to become the mainstream thing it is today. According to its creator, Ryan Dahl, there were some technical decisions that he didn’t think through at the moment.
By now, most programmers know about NodeJs. So, we’re not here to talk about it, but rather its competitors. In recent years, new challengers came into the game with interesting proposals, so we’re going to briefly describe some of their most important features and differences.
Released in May 2018 by Ryan Dahl (the creator of NodeJS), Deno was designed to fix all the major problems of NodeJS and includes other improvements.
Since it was announced, Deno made significant progress and gained major popularity among developers.
Here’s a brief description of some of its key features.
The V8 engine alone is secure, but NodeJS broke that security by allowing the code to access underneath layers like the network or the filesystem.
Deno executes the code in a sandbox by default, so runtime has no access to those features. In order to access them, we will be asked for permissions at execution time, or we can also pass flags to the execution command to grant access for all the operations of a certain type. In both cases, the access is always explicitly granted, and we have full control over permissions.
Decentralized Module Registry
Instead of using a centralized package database like NPM, Deno allows you to request modules by URL as browsers do. So, module developers can host their code wherever they want.
However, and just for ease of use, Deno also offers a hosting service site at https://deno.land/x for third-party modules.
Why decentralized? Well, NPM has faced some serious centralization issues in the past. You can learn about them here and here.
Deno downloads and catches the imported modules. So, if the remote files change or aren’t available at some point, that shouldn’t be a problem for us.
Deno can transpile TypeScript files out of the box without the need for configuration or extra dependencies. This increases efficiency because you have full TypeScript access directly from the start.
ES Modules and browser compatibility
When Node was created, it adopted CommonJS as the module system. It worked very well except for one thing: it wasn’t natively compatible with browsers.
Deno uses standards-compliant ECMAScript modules by default, so we don’t have to use any tool like Webpack to make our application’s browser compatible.
Modern Standardized APIs
Deno includes a series of modern APIs to work with that aren’t included in NodeJS by default.
For example, to send HTTP requests, Deno allows us to use the fetch API, which is simpler than the HTTP or HTTPS libraries that NodeJS commonly offered until v18.
There are other interesting APIs that Deno supports. Here is a list of the available ones.
Built-in test runner
Deno includes a native test runner that can run unit or integration tests faster than using dependencies with NodeJS. Features like these were recently introduced in the latest versions of NodeJS.
The key feature that sets Bun apart from Deno and Node is speed. Bun claims that it is at least 2.5x faster than the other two.
Like Deno, Bun can transpile TypeScript files out of the box. But there’s more to it: it supports JSX and TSX too.
Similar to Deno, Bun includes a series of built-in Web APIs like fetch, WebSocket, or ReadableStream.
Bun has its own centralized package manager that is 4x-80x faster than NPM. Bun uses a compatible NodeJS module resolution algorithm, so we can use NPM packages in it.
Comparing the three environments
At the moment of writing, these are the insights we can compare:
|Latest version||18.8 (stable)||1.25 (stable)||0.1.8 (beta)|
|Years in development||14||4||1|
|Asks for permissions||No||Yes||No|
|TypeScript support||Dependencies and config||Out of the box||Out of the box|
|JSX support||Dependencies and config||Dependencies and config||Out of the box|
|Modules registry||NPM / Centralized||Decentralized||Centralized|
|NPM compatible||Of course||No||Yes|
Which one should we use?
So far, we’ve discussed the benefits and characteristics of each of these new environments. Before answering this question, let’s also take a quick look at the issues of each of them.
First, let’s talk about objectives. Deno’s goal is not to be a NodeJS replacement, but an alternative. Bun, in turn, focuses on being a faster drop-in replacement for Node.
Both Deno and Bun’s TypeScript support look great, but it could be a problem in terms of using newer TS characteristics. In NodeJS, if we want a newer TS version, we can update the dependency. Here, we need to wait for core updates.
Deno’s theoretical browser compatibility could be a decisive factor when choosing the right environment.
One of the biggest caveats of Deno is its ecosystem. Most web packages should work, but others, like those using CommonJS, need to be adapted to work in Deno.
Choosing Bun these days is a hard decision. First, because the product is still in an early stage of development, which lends to a significant number of bugs and compatibility issues with other technologies like NextJS.
Bun’s choice of using Zig as its main development language could make it hard to find contributors and developers with strong Zig skills. So far, Bun looks promising and seems like a technology we should keep an eye on. But in our opinion, it is not ready to use yet.
In Patagonian, we’re always open to trying new things and hearing what the market has to offer. We have extensive experience working with NodeJS and have several projects running and deployed with that technology. We have also implemented certain steps to minimize its shortcomings. We’ll keep an eye on how these new tools evolve over time and what they offer.