Deno.js – The better Node.js?


“Deno is a secure JavaScript and TypeScript runtime built on V8 and was created by Ryan Dahl” What? Ryan Dahl did it again? He created a new language, which claims to overcome the inherent problems and security issues of Node.js. With these announcements alone, it’s worth taking a closer look at Deno.js.

Let’s start with the basics

Under the name Deno, a new project was launched in May 2018 from the feather of Dahl, which aims to become a new runtime environment for JavaScript - more precisely for TypeScript. The new tool is clearly separated from all things commonly associated with Node.js: No package.json, no npm, and no unsecure code out of a sandbox. So it should become a real alternative to Node.js. The current version 0.21.0 is still far away from being perfect and ready for production. But the direction in which the project should go can already be seen.

In detail Deno is built with:

  • The core is written in Rust (Node core is written in C++)
  • Tokio is used for the event loop handling, which is also written in Rust
  • Deno supports both JavaScript and TypeScript out of the box
  • Deno shares only the V8 engine with Node.js, which is known from the Chromium project

Deno Logo

Why should Deno be better than Node.js?


One of Deno’s most important features is the focus on security. What does this mean? Unlike Node, Deno executes the complete code in a sandbox by default, which means that the runtime has no access to the file system, the network, other scripts or the environment variables.

Does this mean I can’t create files or write to files on my system? No, but the system asks us for permission if we want to adapt or create a file. On the first view this could be a little bit bothersome and insistent, but the advantages outweigh the disadvantages. Now we can decide which file or which service has the permission to access the file system or the network.

A short example could look like this: We create a script to write to the file system with a message from the other side. And the environment asks for permission. Of course there is the possibility to set a flag to grant the permission by default or set a flag when we execute the script. But why should we do this?

Create File Permission

Module System

As mentioned early, Deno doesn’t use npm as package manger. But how can we load modules and where are these modules stored? The answers is pretty simple, Deno is just like a browser and loads the modules via a URL.


What? Why? What the f**k?

The reason is also pretty simple: there are varies problems with npm and to prevent them or to create the same mistakes in a new centralized registry the decision was to load the modules via a URL. So now every developer can decide on his own where and how the code should be hosted. For the first time an application is started, the module is downloaded and Deno chaches the code until we tell the service to reload the module. What is meant by “caches the code”? The cache is stored on our local machine as a real file, and we can handle this copy how we like. We could check it into the version control or host the dependencies self. So if we use an external service for dependencies and the external host goes down, our system is still working because we have our own copy in cache.

No package.json? But how do I know which packages in which version my project uses?

The reason behind dismissing the package.json is as follows: In classical Node projects, there are too many reverences where it is stored and which package should be loaded. To solve this there is no manifest or a lock file, that stores the info. But if you are a fan of an overview of your used packages, you can create a sort of a manifest via an “import map”. This is also a JSON-file which includes every used dependencies and our services can load the dependencies via this map file. In my projects I would choose to create a map file, because I like to see on one page which external modules I use.


Deno makes it easy to use TypeScript without the need for any config files, because it is supported out of the box. Still, if we prefer to use good old solid vanilla JavaScript it’s also possible, because Deno can execute plain JavaScript.

Wrapping it up

Deno, is a new runtime environment for both JavaScript and TypeScript out of the box. It is more than an interesting project that has been growing for quite some time and now reached the state that it can be tested by the community. But it still has a (very) long way to go before it’s considered production-ready. It is definitely a fancy new open source project and one to keep an eye on!

What do we wish for the future for Deno:

  • Top-Level async/await handling
  • Serve HTTP more efficiently
  • Better tooling (CLI, Bundling, Linter, etc.)
  • Easy debugging tools



Tobias is Lead Web Developer at and programmer with heart and soul, he loves to bury himself in complex problems and to master them with creative solutions. Frontend, Backend doesn’t matter, he enjoys every task.
If there is no improvement for a web application on the agenda, he likes to learn more about artificial intelligence and machine learning.

We're a team of makers, thinkers, organisers and digital explorers and we're always on the lookout for talented people.

Are you a good fit?