Deno, first approach



Before starting, it is very important to remember that at the time of writing, Deno is still under development. Therefore, any produced code must be considered unstable due to potential unanticipated changes in the API. We will therefore use version 0.21.0 as a basis for the next step.

Finally, it should also be noted that Deno is not intended to replace Node or merge with it.

Introduction & Architecture

Deno is a cross-platform runtime, i.e. a runtime environment, based on Google's V8 engine, developed with the Rust language, and built with Tokio library for the event-loop system.

Node’s problems:

Deno was presented by its creator, Ryan Dahl (@ry) at the European JSConf in June 2018, just 1 month after the first commits.
During this presentation, Dahl exposed ten defects in Node’s architecture (to which he blames himself). In summary:

Finally, the overall negative point is that Node has, over time, unprioritize the I/O event saturation system to the benefit of the module system.

Deno’s solutions:

Dahl then began to work in Deno with the aim of solving most of Node’s problems. To achieve this, the technology is based on a set of rules and paradigms that allow future developments to follow the guideline:

What Deno doest not target (at all):

Le architectural model:


Rust is the language used to encapsulate the V8 engine. It is he who exposes the isolated functionalities through an API that can be used in JavaScript. This link, or binding, called libdeno, is delivered as is, independently of the rest of Deno’s infrastructure, thanks to a Rust module called deno-core (a crate; consumed by the command line, the deno-cli. This crate can be used in your own Rust app if you want to.

The deno-cli is the link between the crate core, the TypeScript compiler (hot compilation and cache of the final code), and Tokyo (an event-loop library).

To summarize, here is a diagram of the execution process:


This library written in Rust gives the language the capability of asynchronous programming and event-oriented programming.
Natively, Rust does not support event loop management, and has, until 2014, used the libuv library to perform its I/O operations asynchronously and cross-platform and thus remedy this flaw.
It should be noted that Node still uses libuv today in its V8 process.

Thus, Tokio became the reference library for all asynchronous event-driven programming in Rust.

From Deno’s point of view, Tokio is therefore in charge of parallelizing all the asynchronous I/O performed by the V8 bindings exposed in the deno-core isolate (as a reminder, deno-core is the standalone Rust crate)


Finally, as mentioned several times earlier, the entire architecture is based on the JavaScript interpretation engine. It is regularly updated to follow the needs of the latest versions of TypeScript, among other things. At the time of writing, the version used by Deno is version 7.9.304 from October 14, 2019.

Ecosystem & First Developments

Installation :

For several versions now, Deno is available via Scoop for Windows, and via Homebrew for OSX.
Installation can also be done manually via cURL under Shell, especially for Linux which only has this solution for the moment, or via iwr under PowerShell for Windows.
In the same philosophy as the code, Deno is delivered as a single executable.

## Shell
curl -fsSL | sh

## PowerShell
iwr -useb | iex

## Scoop
scoop install deno

## Homebrew
brew install deno

Once the installation is complete, launch the command deno to test its proper functioning.


The command-line interface provides a set of integrated features that allow you to remain immersive in Deno’s proprietary development environment. It also and above all allows you to stay in line with standards when you need to offer your library to the community.

Here is a list of the commands currently available:


Now let’s talk about our first program. At the moment, even if the Deno ecosystem itself offers a range of development tools that can be used on the command line, the VSCode extension catalog (or other editor) remains very poor in features.
Don’t expect a complete developer experience during your first lines of code.

Example 1: Grep

This first example is a simple reproduction of grep’s behavior and highlights the import of Deno standard libraries, their usage, as well as the manipulation of files and arguments.

In order to group them, dependencies can be declared in a file conventionally called deps.ts:

import * as path from "";
export { path };
export { green, red, bold } from "";

Then be imported classically into its mod.ts (equivalent to the index.js in Node):

import { path, green, red, bold } from "./deps.ts";

An “http” import from Deno is the retrieval of a web resource at the time of compilation. Deno currently only supports http://, https://, and file:// protocols.

Then, we validate the arguments passed and retrieved directly from the Deno global object:

if (Deno.args.length != 3) {
  if (Deno.args.length > 3) {
    throw new Error("grep: to much args.");
  } else {
    throw new Error("grep: missing args.");
const [, text, filePath] = Deno.args;

Finally, we parse and iterate the file to bring out the lines containing the pattern you are looking for:

try {
  const content = await Deno.readFile(path.resolve(Deno.cwd(), filePath));
  let lineNumber = 1;
  for (const line of new TextDecoder().decode(content).split("\n")) {
    if (line.includes(text)) {
        `${green(`(${lineNumber})`)} ${line.replace(text, red(bold(text)))}`
} catch (error) {
  console.error(`grep: error during process.\n${error}`);

Finally, to launch the application, execute the command deno grep/mod.ts foo grep/test.txt
foo being the pattern, and test.txt a file containing strings.

Exemple 2 : Overkill Gues-A-Number

This second example is a mini game where the goal is to find a number between 0 and 10 from “more” or “less” clues. It highlights the use of a third-party framework, the import of React, and JSX compatibility.

The import of a third party is almost identical to the import of a standard:

import Home from "./page.tsx";
import {
} from "";
import { App, GuessSafeEnum, generate, log } from "./misc.ts";

A .tsx file being imported, React must be used to be able to run the whole thing. The page.tsx file is completed as follows:

import React from "";
import ReactDOMServer from "";

Thanks to the .tsx extension and React, we can use JSX to export a component rendered on the server side for example :

export default (props: HomeProps = {}) => `<!DOCTYPE html>
    <Home {...props} />
    <hr />
    <Debug {...props} />

You can run this example with the command deno guessanumber/mod.ts
Finally, you can find the complete examples on Github or even run them directly from their “raw.githubusercontent” URLs.

Production & Futur

Right now, Deno is not ready-to-prod. The main uses being to create command line tools, background task managers, or web servers (like Node), Deno’s performance is not at the level Dahl wants it to be.
However, it is possible to start experimenting with the development of internal tools such as batch scripts for example.
A real-time benchmark is available on

Comit after comit, the benchmarks are updated and compare Deno’s performance to that of Node on several levels, such as the number of requests per second (which is the first bottleneck blocking production use), maximum latency, input-output interactions, memory consumption, etc.
Deno is already better than Node on a few points and keeps improving over time, hoping to finish first in all the tests performed.


In addition to performance, Deno completes the developer experience with a set of essential features and tools for the release of version 1.0 that can be considered ready for production use.


It is not currently possible to debug or inspect an application; something that can be constraining during development. This major feature is mandatory for version 1.0.
Taking advantage of V8, the debug will rely on the V8InspectorClient and the Chrome Devtools allowing to use the same tools as with any other JavaScript development.

API Stabilization

There are and still are some bugs in the API, either in the TypeScript layer or in the deno-core. These bugs, although minor, are still blocking the good stability of the whole.
Being stable does not only mean having a smooth execution, but also having consistent and uniform entry points. Some functions must therefore be reviewed in terms of their name or even their signatures.

Clear and explicit documentation

The common problem with any project starting in the background - the Deno documentation is still very light and lacks use cases or explanations on specific topics.
The official website is currently being redesigned and will soon be completed.


Decoupled from the first stable release, additions to the CLI will be made, support for adding native functionality (via modules called “ops” crates in Rust) will be provided, as well as, among many other things, ever closer compatibility with the Web world and ECMA standards (e.g. by supporting WebAssembly modules).

Concerning the CLI, here is a non-exhaustive list of the planned functionalities:

Version 1.0 is very close and the fast pace of development has allowed the team to estimate a release for the end of the year or early January.
It is important to remember that Deno remains an open source and community project, and that it is up to the community to help by experimenting with the technology, pushing it to its limits, and providing as much data as possible to the developers.

Community & Contribution

Due to its relatively young age, the Deno community is still small. Nevertheless it is growing every day and many developers from Rust or Node are more and more interested in the technology.
The biggest communities today are Polish (which includes one of the major contributors through Bartek Iwańczuk (@biwanczuk) ), Korean, Chinese or Japanese.
Meetup groups are therefore gradually being created like Deno Poland (@denopoland), or Denoland Korea (@denoland_kr).
France is not to be outdone and already has its first group, Paris Deno (@ParisDeno).
A newsletter is also available on

From a contribution point of view, there is a lot to be done. Pull requests on official repositories are “simple” to do as a list of missing features and bugs is available at In addition, the contribution rules have been written and completed for the occasion.

The TypeScript layer consists of a core, a set of standard deno_std libraries (, and a set of third-party libraries combined into a single directory to simplify URLs (
Contributions made to the standard and the core must respect the rules, but this is not the case for third-party libraries.

Contributions can also be made at the development tool level. Indeed, there is still a lot missing to be comfortable and productive such as VSCode extensions or test libraries equivalent to Jest or fast-check (whether they are ported, “isomorphized”, or rewritten).
Deno needs you, feel free to go ahead and submit your content; many of the libraries offered are ports of existing libraries from Node, Rust, or even Go.

In conclusion, Deno is still in its early stages, but Ryan Dahl is not at his first try.
Thanks to the new features of version 1.0, the usability of TypeScript, the more and more interesting performances, and last but not least, because of the confident and growing community, Deno will undoubtedly become one of the potential trending technologies to capitalize on for 2020/2021.
Stay tuned!