Why did the guy that made Node.js make a new Node.js?

It’s been three years since Ryan Dahl — the same guy behind Node.js — hatched Deno into the world wide web. This opensource and V8 runtime powered serverside has over 80k stars on GitHub, 42k followers on Twitter, and $4.9 million in seed capital from various investors and Mozilla Corporation for its commercialization.

But what exactly is Deno? How is Deno different from Node.js? and will it take over as the new Node.js?

What is Deno?

When Ryan Dahl, the creator of Node.js, released Deno in May 2018 — you can’t help but ask the question: why?

During the 2018 JSConf EU, Dahl admitted that lessons were learned from Node.js, especially in the realms of security, modules, and dependencies. Node.js was initially released in 2008 and the landscape of web development was different from what it is today. These things were not exactly at the forefront of design thinking when Node.js was created and JavaScript was still regarded as a gimmick than an actual and powerful programming language.

Deno is, in essence, the rebirth of Node.js — better, faster, with better security, and all the lessons that Node.js did not have in its 10-year tenure as the foundation of serverside programming for JavaScript.

But what is Deno? In a nutshell, Deno is a serverside engine that lets you write TypeScript code to create your backend.

How is Deno different from Node.js?

When it comes to Deno, it’s easy to see it as another Node.js. But it’s not. Deno is secure by default. This means that unless you explicitly enable it — all files, network, and environment access is locked. This follows the principle of least privilege, meaning that any security leaks that occur are due to the loosing of security protocols rather than not having it tight enough.

Unlike Node.js, Deno restricts access to the file system, network, execution of other scripts, and environment variables by default. For example, if you are building an API, you will need to enable the --allow-net flag in order to open up network connections.

Deno run --allow-net app.ts

Here’s a quick list of the security flags for Deno:

  • --allow-write : flag for file system access
  • --allow-net : flag for network requests
  • --allow-env : flag for access to the environment
  • --allow-run : flag for running subprocesses

Deno also supports TypeScript out of the box, ships as a single executable file and there’s no need to maintain dependencies. Third-party modules are imported directly from the source and then cached the first time it runs, meaning that you can say goodbye to package.json files and package managers.

Here is an example of an app.ts code and how libraries are imported:

import { Application } from "https://deno.land/x/oak/mod.ts";
import router from "./routes.ts";

const HOST = "127.0.0.1";
const PORT = 8080;
const app = new Application();
app.use(router.routes());
app.use(router.allowedMethods());

console.log(`Listening on port ${PORT} ...`);

await app.listen(`${HOST}:${PORT}`);

However, loading the external modules from urls can feel teadious and create issues if the link changes for whatever reason. You’d still need to create a centralized export file so that you can use it in multiple spaces.

For example, if you have the export below located in a file called local-utils :

export { test, assertEquals } from "https://deno.land/std/testing/mod.ts";

You can use it again like this:

import { test, assertEquals } from './local-utils.ts';

Deno also hosts caches releases of open source modules stored on GitHub to ensure uptime and easy-to-remember names that are structured as https://deno.land/x/<moduleNameHere> .

What about speed?

Both Deno and Node.js uses the same Google V8 engine. So when it comes to performance, you are comparing almost the same thing. However, Deno is built on Rust. In contrast, Node.js is built on C++. This may impact performance as the application grows, but due to Deno’s relative infancy, there aren’t any enterprise reports that are readily available for us to compare.

However, Deno does have a benchmark report that is often compared to Node.js that you may find interesting. When it comes to HTTP throughput, Deno comes with lower latency. But overall, Deno and Node.js seem to be almost on par with each other in terms of speed and performance.

Deno and Promises

Promises are now a pillar of serverside development, especially in JavaScript. Unlike Node.js, Deno uses promises at every level possible. This means that all asynchronous methods return Promises by default. So rather than writing long promise nests, you can just use await instead.

Deno also comes with an in-built error failsafe. This means that your application will automatically fail if an API does not contain error handling.

Final question — will Deno replace Node.js?

There’s probably more that I can write about Deno but there’s only so much one can fit into one piece before it goes off tangent.

Node.js is a cornerstone of JavaScript serverside development. It still works, the community is still strong, and it’s not too annoying to use. Deno wasn’t created to replace Node.js. Rather, it was created to provide an alternative solution to Node.js.

So will Deno replace Node.js?

Probably not.

However, as the Deno community and advocacy grows, so will its support and general adoption. Deno is the new kid on the block and by age and design, it will always be easier to use.

Deno is not a fork of Node.

It’s its own implementation based on modern features of JavaScript. Node.js was created during a time when developing JavaScript didn’t have the features and functionalities that we enjoy today.

It’s easy to take for granted things like ES Modules and TypeScript when you’ve been immersed in it long enough. While Node.js still carries the legacies of ye old JavaScript days and its various development quirks, it is also entrenched in startups and enterprises as cornerstone software.

In short, Node.js will continue to stick around with Deno as a potential alternative for startups, solopreneurs, and enterprises to choose from.

The rise of Deno doesn’t necessarily mean the death of Node.js. Rather, it provides healthy competition and encouragement for both Node.js and Deno to get better and easier to use, in addition to new ideas to flourish in the space known as serverside JavaScript.

Share this post