The Guide to Deno

JavaScript is the best language for those who want to learn to program, and it really has made a huge impact on people’s lives.

On the other side, Node.js has helped JavaScript take over the world of web development. It has introduced a lot of new developers to the programming world and made it easier to build modern applications, spend less time figuring out how to work with JavaScript properly and build better and more robust applications.

Since the release of Node.js back in 2009, it has really come a long way. With new features and concepts implemented inside Node.js, it’s improved the way we work with JavaScript. But, like any project, it has some things that we wish were better and we could improve.

The Problem with Node.js

Ryan Dahl, the creator of Node.js, gave a talk in 2018 called “10 Things I Regret About Node.js.” In this talk he explained what he wished he’d done differently. For those who want to learn more about the initial concepts of Node.js, this is a great talk.

The essential idea behind the creation of Node.js was to focus on programming event-driven HTTP servers. Here are some the things that Ryan Dahl regrets about Node.js:

1) Promises

Promises were introduced as part of the ES6 (ES2015) and landed in Node.js only in February 2015. They’re very important, especially due to the async/await primitives that came up in Node.js in February 2017.

The possible usage of Promises when Node.js was developed would contribute to the eventual standardization of async/await. They’re a necessary abstraction for async/await.

2) Security

This is an important and highly discussed point about Node.js. It was built on Chrome’s V8 JavaScript engine, which is a very good security sandbox. But we still have some problems with security in Node.js, especially with giving access to packages that shouldn’t have access to our computer and network.

3) node_modules

The _node_modules_ folder contains libraries downloaded from npm. Every time we start a new project, we need to install new dependencies, and by doing that, our _node_modules_ folder gets heavier and heavier.

Unfortunately, there’s no way to undo this in Node.js. Dahl said that “it’s impossible to undo now.”

4) package.json

The package.json file is a common file created at the root directory of a Node.js module by running a command. There are a few things that he regrets about package.json, and one of the things is that the package.json file doesn’t allow relative files and URLs to be used when importing—the path defines the version. By doing that, there would be no need to list dependencies.

He also listed as regrets: the Node.js Build System (GYP), index.js (when you include a directory, it looks for a file called index.js) and the point where you don’t need to include the “.js” extension to require a module, which turns into a mistake because this is not how browser JavaScript works.

Deno

After realizing all the points that he wished could be better in Node.js, Dahl revealed in his 2018 talk that he was creating a new secure JavaScript runtime called Deno.

Deno is a new secure JavaScript and TypeScript runtime released this May 13. It brings a lot of functionalities and JavaScript features, with a more secure and powerful core.

Here’s how Deno is different from Node.js:

Rust

One of the programming languages that has been trending in the development community lately is Rust. This language has been very popular for a lot of factors, such as ensuring that our programs are free from undefined behavior and data races, more memory safety, etc. Rust is a very safe and fast language.

Node.js is based on the V8 engine to execute JavaScript, and the V8 is based on C++. The difference here is that Deno also is based on the V8 engine to execute JavaScript, but is also based on Rust.

A safer and faster language makes a big difference for Deno—delivering a good performance, without any memory safety issues, undefined behavior, data races, etc.

Security

One of the issues a lot of developers complain about in Node.js is security. The choice of using Rust was not only right for allowing the runtime to be faster and bug-free, but also to improve the security. After an app starts running, it can easily access your file system or your network—this is a very serious security flaw.

Deno solves the security by executing the code in a sandbox. The runtime has no access to your file system or network. Unless you specify that you want to enable or disable access, a module has no file, network or environment access. Instead, you can use command-line arguments to enable or disable different security features or do so programmatically.

For example, if we want to grant read-only access for a file, we could do the following:

deno run --allow-read test.ts

TypeScript

Deno is a JavaScript and TypeScript runtime, which means that it brings TypeScript support by default. We can easily use TypeScript anywhere in our code without having to install or transpile anything.

Deno only requires qualified modules names, which means that we should include the extension of the file when importing it. Imported modules are specified as files in Deno.

import main from "./main.ts";

ES6

Deno includes a built-in package manager for resource fetching, so there’s no need to use npm (Node Package Manager).

This can be a huge change in the way we build modern JavaScript applications. Instead of downloading packages from the npm repository, we just pass a URL, and Deno loads for us the dependencies, similar to browsers.

Deno uses the official ECMAScript module standard rather than the CommonJS. Deno uses the import syntax from ES6 instead of the require() standard.

Another nice thing about Deno is that you cache all the modules that you download. So, if you download a module, Deno will automatically cache it, and not download it again, only if specified with the reload flag.

Getting Started

We can download Deno using Homebrew on macOS or Linux:

brew install deno

If you’re a Windows user, you use Chocolatey to download Deno, with the following command:

choco install deno

To create a simple example using Deno, let’s create a new folder called deno, and inside this folder, we will create a file called deno.ts.

Remember, Deno supports TypeScript out of the box. To run our first Deno file, let’s create a simple const variable and show it in the terminal.

const hello: _string_ = "Hello Deno!"
console.log(hello);

To run our code, all we need to do is go to the right directory and give it a run command passing the name of the file we just created. In our case, we would do the following:

deno run deno.ts

Node.js Is Not Dead

Once a new framework is released, developers may already think that everybody will migrate to it. That’s not different in the case of Deno. We’re seeing a lot of people already claiming that “Deno is the future, we should abandon Node.js.”

Deno is, in fact, a nice and awesome surprise in the web development world. It brings new concepts, new ideas, new paradigms, and concepts that we should learn, but some people are already claiming the substitution from Node.js to Deno in all their applications.

When you think almost every modern application was built using Node.js, it’s insane to think that people will instantly migrate to Deno. Just imagine how many applications were built using Node.js, how many services and APIs were possible to be created because of Node.js, not even to mention that Node.js has reached a point where it’s really mature and stable, with a huge community behind it.

We should consider both. But, for now, Node.js is a better option without a doubt. It’s stable, more mature, with more features, and the community is way bigger. Deno might be the future, but Node.js will not go away any time soon.

Conclusion

In this article, we learned more about the new JavaScript runtime called Deno, the differences from Node.js, and how Deno can help us build better applications in the future applying powerful concepts.