Will Deno replace Node?

Introduction

Deno was introduced for the first time almost 2 years ago. Ryan Dahl, the creator of Node.js gave a speech during JSConf. He was talking about his regrets concerning Node implementation. Apart from that, he also revealed Deno to the world as a solution to the existing difficulties of Node.

So what exactly is Deno?

You can think of it as a successor of Node. It is a runtime for JavaScript and TypeScript developed with Rust. Deno is supposed to solve the problems that Node has.

I would like to show you the main differences between the two and give my personal opinion on how their future will look like.

Basics

Let’s look at an example server app in Deno

and an example server app in Node

You can notice a couple of differences right off the bat. I’ll discuss each category separately.

Security

Deno approaches security differently than Node. Deno is secure by default. Only basic permissions are given when running scripts with Deno. You can’t access the file system, network, or environment unless explicitly enabled. To enable them you need to use flags. F.e. --allow-read or --allow-net.

Our server example uses network permission, so it would fail if we simply tried to run it. We need to run the script explicitly with network permission.

deno run --allow-net mod.js

It adds an extra layer of security when using modules created by other users. In a Node.js app, a linter that you downloaded from the internet can access your file system, which is not necessarily a good thing.

TypeScript

In order to use TypeScript in a Node app, you need to compile TypeScript into JavaScript on your own first and then you can run your built js file against Node. Deno has a built-in TypeScript compiler. It means that you don’t need any other tools except Deno CLI to run a TypeScript project. Deno simply takes care of the compilation process. All you have to do is to change the file extension to .ts and you can use the full potential of TypeScript without the necessity to compile files.

deno run server.ts

Module management

Let’s take a closer look at the first line of the hello-world app.

import { serve } from "https://deno.land/std@0.53.0/http/server.ts";

You can notice a couple of differences here.

First of all, Deno uses ES6 imports rather than CommonJS. Second of all, the modules are being fetched directly from the source rather than from node_modules. JavaScript developers are used to working with package.json files. In case you don’t know it, it’s a file in which you describe all dependencies that your app uses. So you might ask why would anyone get rid of the tool that everyone has got used to.

There are a couple of reasons why the current module management system is not very good.

• node_modules directory is very heavy and you basically need to install dependencies in all projects locally
• node_modules complicates the module resolution algorithm
• package.json contains a lot of unnecessary information like License or Description
• You have to take care of way too many things while adding a new module to your project (adding in package.json, making sure that the dependencies are installed, lockfile included and node_modules excluded) and adding a package shouldn’t be that difficult
• It is difficult to understand for new-comers

Instead of the current module management system, Deno comes up with a new one that is supposed to resolve the existing issues. All of the modules are fetched directly from a source code. Once you run your app, Deno will download the remote code that you depend on. After downloading it once, it will be cached forever for future projects. If something goes wrong and you need to re-download the package, you can use --reload flag.

And that’s all, we don’t need package.json , node_modules , nor lockfiles. Module management as simple as it gets.

Promises

If you use Node.js you can notice that the core modules don’t return Promises on async actions. This is because Node was developed back in the days when Promises weren’t standardized in JavaScript. Deno hopes to fix this issue by creating an environment that depends on Promises rather than callbacks.

This one is pretty straightforward but very important. Promises greatly increase code readability and help us avoid callback hell.

Top-level await

Deno uses the top-level await that is currently a stage 3 proposal, using JavaScript new features to the fullest. Let’s take a look at the piece of code as an example.

for await...of creates a loop iterating over async iterable objects as well as on sync iterables. Deno uses it to receive incoming traffic to the server, but it’s not the only case. For example, if we wanted to listen to the file system events, we would use the same syntax.

Single executable file

Deno ships only a single executable file. This makes starting with Deno much easier, as it takes the role of both runtime and package manager. Ryan Dahl claims that it will always stay this way, meaning no different executables will be introduced to run a Deno app.

So what now? Should I stop using Node?

Well, no. Node.js is definitely too big to be taken over by Deno anytime soon. Deno is very tempting to start using right away, but let’s take a look at some drawbacks.

Modules are not compatible backward

Your favorite libraries still need to be ported to Deno and it might take some time. NPM package registry is very large. It offers solutions for almost anything you can think of, and you can’t use them in your Deno app just yet. You can see the list of modules that are already included in Deno on https://deno.land/x.

Some of the modules are unstable

Deno team states that the API for core modules is mature enough not to introduce any breaking changes. However, there are some less important modules that are not fully stable yet. You need to provide --unstable flag in order to use them. Those modules are likely to have some breaking changes and they haven’t undergone a security review. They are simply not ready to be used in production.

Jobs lists are not there yet

Deno is a very promising new shiny tool for JavaScript developers, but the technology shifts take a lot of time. Node.js has been out there for over a decade, while Deno is at the beginning of its journey. We still need a lot of time before it becomes ready to be used in production environments. There is no reason for companies to shift to Deno rapidly. It still has a long way ahead to gain credibility before job listings are common.

Conclusion

I really like Deno, I hope it grows in maturity and someday soon will be ready to use in production. I believe that it solves many existing problems that Node.js developers have. I also think that it’s a matter of time before Deno overtakes Node.

But

I don’t think that Node is going anywhere anytime soon. We shouldn’t panic by switching technology stacks and rewriting every app from Node to Deno. The successor of Node is still very immature and requires much more to be used in production environments than it is offering now.

I hope to see the future where both Node and Deno co-exist.