Since its creation, NodeJS has been positioning itself as the chosen runtime environment for JavaScript/TypeScript applications. Mature, well-tested, and with a great community, it’s the preferred choice for today’s JavaScript developers.
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.
Deno
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.
Programmed in Rust and with the V8 JavaScript engine embedded, Deno offers a more secure, modern, and simpler JS runtime than NodeJS.
Here’s a brief description of some of its key features.
Security
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.
TypeScript Support
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.
Bun
Bun is the new guy in town with big dreams. With only a year in development, it was designed as a drop-in replacement for current JavaScript & TypeScript apps and focused on performance. It touts itself as a fast all-in-one solution that includes a bundler, transpiler, and package manager in a single tool.
Performance
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.
Why is it faster? First, because Bun uses JavaScriptCore as the engine, which tends to perform faster than V8. The second and most important reason is that it is written in Zig, a low-level programming language with manual memory management that lets developers have full control over memory.
Transpiler
Like Deno, Bun can transpile TypeScript files out of the box. But there’s more to it: it supports JSX and TSX too.
Web APIs
Similar to Deno, Bun includes a series of built-in Web APIs like fetch, WebSocket, or ReadableStream.
Package manager
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:
| NodeJS | Deno | Bun | |
| GitHub stars | 89k | 85k | 33k |
| Latest version | 18.8 (stable) | 1.25 (stable) | 0.1.8 (beta) |
| JS Engine | V8 | V8 | JavaScriptCore |
| Written in | C++ | Rust | Zig |
| Years in development | 14 | 4 | 1 |
| Sandbox Execution | No | Yes | No |
| 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 |
| Stackoverflow questions | 440,000+ | 700 | 30 |
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.
At the time of writing, NodeJS would probably be the preferred option for most of today’s JavaScript projects. It’s mature, stable, and has a huge ecosystem. But these new competitors are pushing NodeJS and forcing it to adapt to new times. Safe competition is always good.
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.
