Getting Started with Deno Runtime Tutorial: Alternatives to Node.js

Getting Started with Deno Runtime Tutorial: Alternatives to Node.js

During the few days of vacation, I learned about Deno . It is an alternative to Node.js. With it, Node.js may not be needed in the future.

This article is an initial introduction to Deno, trying to answer why Node.js is not enough, and what can Deno bring us?

The following is largely based on recent presentations by Bert Belder and Ryan Dahl .

Before getting into the subject, let’s talk about how to pronounce the word Deno.

I’ve heard both pronunciations, “Deno” and “Tino”. It seems that the pronunciation of “Tino” should be more appropriate, because Deno’s logo is a dinosaur. The abbreviation for dinosaur (dinosaur) is dino.

Deno was founded by Ryan Dahl in 2017.

Ryan Dahl is also the founder of Node.js, from 2007 until 2012, he later handed over Node.js to other developers, stopped talking, and turned to artificial intelligence.

He never liked the Python language very much. Over time, he wanted to develop an artificial intelligence development framework in the JavaScript language. When he went back and picked up Node.js, he found that the project had deviated from his original intention, and there were some problems that could not be ignored.

First of all, over the past five or six years, the JavaScript language has been reborn, and the ES6 standard has introduced a lot of new syntax features. Among them, the two most influential syntaxes are: Promise interface (and async function) and ES module.

Node.js’ support for both of these new syntaxes is not ideal. Due to historical reasons, Node.js must support callback function (callback), resulting in two ways of writing the asynchronous interface: Promise and callback function; at the same time, Node.js’s own module format CommonJS is incompatible with ES modules, resulting in the delay of full support. ES modules.

Secondly, the logic of Node.js’ module management tool npm is becoming more and more complex; the module installation directory npm_modules is extremely complex and difficult to manage. Node.js also has almost no security measures. As long as users download external modules, they have to let other people’s code run locally and perform various read and write operations.

Third, the functions of Node.js are not complete, resulting in an endless stream of external tools, which makes developers tired: webpack, babel, typescript, eslint, prettier…

For these reasons, Ryan Dahl decided to abandon Node.js and write a replacement from scratch to solve these problems completely. The name deno is a recombination of the letters from Node (Node = no + de), which means “destroy Node.js” (de = destroy, no = Node.js).

Like Node.js, Deno is also a server runtime, but supports multiple languages ​​and can directly run JavaScript, TypeScript and WebAssembly programs.

It has a built-in V8 engine to interpret JavaScript. At the same time, there is also a built-in tsc engine that interprets TypeScript. It is developed using the Rust language, and since Rust natively supports WebAssembly, it can also run WebAssembly directly. Its asynchronous operation does not use the libuv library, but uses the Rust language Tokio library to implement the event loop (event loop).

You might ask, why use Rust instead of C++ (the development language for Node.js)?

The main reason is that Rust provides many ready-made modules, which can save a lot of development time for Deno projects.

Deno itself is a module of Rust. If you want to use the V8 engine in Rust, you can load Deno. It is equivalent to a V8 wrapper layer, providing some low-level APIs to allow you to interact with the V8 engine.

Deno has only one executable file through which all operations are done. It supports cross-platform (Mac, Linux, Windows).

Deno has security controls and scripts don’t have read and write permissions by default. If the script is not authorized to read or write to the file system or network, an error will be reported.

The parameter must be used to explicitly open the permission.

  • --allow-read: Open read permission, you can specify a readable directory, eg --allow-read=/temp.
  • --allow-write: Enable write permission.
  • Allow network communication, you can specify a requestable domain, eg
  • --allow-env: Allows reading environment variables.

Deno supports Web API, which is as consistent as possible with browsers.

It provides the global object window, and supports Web standards such as fetch, webCrypto, and worker, as well as event operation functions such as onload, onunload, and addEventListener.

In addition, all asynchronous operations in Deno always return Promise.

Deno only supports ES modules, which are consistent with the browser’s module loading rules. No npm, no npm_modules directory, no require()commands (ie, no support for CommonJS modules), and no package.jsonfiles required.

All modules are loaded via URL, eg import { bar } from ""(absolute URL) or import { bar } from './foo/bar.ts'(relative URL). Therefore, Deno does not require a centralized module storage system and modules can be loaded from anywhere.

However, after Deno downloads the module, there will still be a general directory that caches the module locally, so it can be used offline.

Since Deno only supports loading modules from URLs, the module loading method of Node.js will be invalid.

import React from "react";
import { Box, Grid } from "@material-ui/core";
import { initializeApp } from "firebase/app";

The above notation is illegal in Deno.

All modules of Deno must be loaded through the entry script, not through the module name, so they must have a script suffix.

Deno natively supports the TypeScript language and can be run directly without explicit transcoding.

Its interior will be judged according to the file suffix name. If it is a .tssuffix name, it will first call the TS compiler to compile it into JavaScript; if it is a .jssuffix name, it will be directly passed to the V8 engine to run.

Deno has built-in functions that developers need, and no external tools are required. There are special commands for packaging, format cleaning, testing, installation, document generation, linting, script compilation into executable files, etc.

Execute deno -hor deno helpto display the subcommands supported by Deno.

  • deno bundle: package scripts and dependencies
  • deno eval: execute code
  • deno fetch: grab dependencies locally
  • deno fmt: Formatting the code
  • deno help: same as -hparameter
  • deno info: show the local dependency cache
  • deno install: install the script as an executable
  • deno repl: enter the REPL environment
  • deno run: run the script
  • deno test: run the test

The installation of Deno can refer to the homepage of the official website , but you can directly go to the release page of the GitHub repository and download the compiled executable file (above).

After downloading Deno, check out the version.

$ deno --version
deno 0.31.0
v8 8.1.108
typescript 3.7.2

Running the command line directly denowill enter the REPL environment.

$ deno
1 2 3

Next, run a TypeScript remote script, this is the example given by the official website .

$ deno run \ \

In the above example, Deno executes the remote script curl.tsand uses this script to crawl the URL However, an error is reported after running, indicating that there is no permission for network communication.

We give Deno network communication permission, and it can be executed smoothly.

$ deno run --allow-net \ \

Now, the latest version of Deno is 0.31. According to the plan, 1.0 should be released in the first half of this year.

Deno is still under intensive development, its functionality is unstable, and it is not recommended for production environments. However, it is already a usable tool, and you can try it out to get familiar with its usage. I believe that the many advantages of the design will give it an advantage over Node.js.