Deno is the new Node?

Photo by Markus Spiske on Unsplash

About 3 months ago, Ryan Dahl (the inventor of Node.js) gave a talk in JSConf called “10 Things I Regret About Node.js”, were he regrets several design decisions he took over Node.js. About during the half of his talk, he showed us an experimental prototype called Deno that aimed to fix Node.js problems.

Deno has reached v0.1 and I think that it’s on the right way to replace Node.js in the future.

What are the main issues with Node.js?

Any program can write to the filesystem and the network

This might be a security problem, especially when intalling untrusted packages from npm. The crossenv incident is an example. If crossenvhad not had writing permissions, this would not have happened.

Bad ageing async APIs

Promises were included in 2009 but removed in february 2010 from Node.js. This has provoked that many libraries out there are still using callbacks as their way to manage async code.

The build system (GYP)

Using GYP to build a module that links to a C library is a big pain. In order to have a sane DX you’ll have to use node-gyp (a layer on top of GYP) and maybe other layers (like nan). I’ve tried this by myself with a small project and yes, it’s a pain.

The module system and npm

The main problem here is that the module system isn’t compatible with browsers so our code isn’t fully isomorphic. This is mainly caused by two reasons: storing dependencies in node_modules and having a package.json.

What is Deno?

“Deno is a secure TypeScript runtime built on V8”
Ryan Dahl

As Typescript is a superset of Javascript, it’s also a runtime for Javascript.

Deno is a new project created by Ryan Dahl (the inventor of Node.js) that aims to fix Node.js design mistakes that I’ve mentioned before.

Deno’s top features


Deno by default won’t allow performing delicate actions, like reading environment variables or writing into the file system. We need to pass specific flags

Deno process runs in a “non-privilege” mode by default, and for accessing delicate things like environment variables

All the code runs without filesystem write, environment and network permissions. To allow this we must invoke demo with the --allow-write and --allow-net.

All communications between Deno’s privileged process and v8 are by message passing (previously written in Go, now migrated to Rust). This allows a single auditable point for all communications.

Module system

No package.json, no node_modules. Source files can be imported using a relative path, an absolute path or a fully qualified URL of a source file:

import { test } from ""
import { log } from "./util.ts"

All source files are cached by default. If we need to refresh our dependencies we can use the argument --reload. This is like the browsers’ F5.

TypeScript support out of the box

TypeScript is supported by default in Deno. Yup. No gotchas. Without any config.

Trying out Deno v0.1.4

First, we need to download Deno binary:

$ mkdir deno-test && cd deno-test
$ wget
$ gunzip -c deno_linux_x64.gz > deno
$ chmod u+x deno
$ ./deno --version
deno: 0.1.4
v8: 7.0.247-deno

Now we can create our typescript file and execute it:

$ ./deno myscript.ts
Hello world

We can also try URL imports. The only requirement for this is to have the .ts file extension at the end of the URL.

$ ./deno myimport.ts

When executing the script, it’ll download and cache the module. If we want to refresh this cache, we can invoke Deno with --reload, which is the equivalent to F5 or Ctrl+R.

Here is a more advanced example, using a shallow implementation of the axios library:

The only gotcha is, that VSCode isn’t able to load the typings from the remote, so in the editor we’ll get the following error:

An import path cannot end with a '.ts' extension.

But the code still works and gives the correct output:

./deno --allow-net axios-test.ts
User name: Leanne Graham


There still a long time until Deno reachs a production-ready state, but I think it’s on the right path in order to be a better Javascript runtime than Node.js.

Thanks for reading! 👋👋