Deno is a modern, clean server-side runtime for JavaScript and TypeScript, similar to Node.js but with many improvements focused on security and simplicity. The project was founded by the original creator of Node.js, Ryan Dahl, and is based on the V8 JavaScript engine (similar to Node.js), the Rust programming language and the Tokio event loop written in rust. The new runtime was created with the intent to fix the inherent problems of Node.js, effectively making Deno the Node.js v2.

1. Minimal and secure

The number one reason to adopt Deno is purely for it being security-focused. Code is executed in a sandbox, with a “no permissions” scheme implemented by default. This means that permissions for file, environment and network access have to be enabled explicitly. Although the security improvements may seem insignificant, they are a step up from Node.js. Another feature that Deno guarantees is that it has no dependencies and ships as a single executable.

2. Functionality

Another fundamental aspect Deno aims to improve is productivity and so it has essential utilities built-in. These include:

  • Dependency inspector (deno info)
  • Code formatter (deno fmt)
  • Unit testing (deno test).

With Deno, there is no need to compile TypeScript to JavaScript externally as it supports TypeScript out of the box.

3. Decentralised packages

Although Deno is not compatible with most Node packages, over time Deno may be able to run more Node programs out of the box. Deno can, however, import modules from any location on the web like from a personal webserver, GitHub or a CDN. Deno also does not use package.json in its module resolution algorithm, which can quickly become bloated after a few dependencies are added to a project. Remote code is fetched and cached on first execution and is not updated until the --reload flag is run. This means projects with dependencies cached will work offline. Importing code via URL allows for decentralisation, where package creators can host their code wherever they see fit.

3.1. Standard modules

Deno offers a more complete set of standard modules than Node.js. The Deno standard library, which was inspired by GoLang’s standard library, is audited and guaranteed to work with Deno can be found at https://deno.land/std. It contains tools to work with external data structures, UUIDs, parsing date strings and many more. Adding a simple http server module from the standard library as a dependency to “exampleImport.js” would look like:

1
2
3
4
5

import { serve } from "https://deno.land/std/http/server.ts";
console.log("http://localhost:8000/");
for await (const req of serve({ port: 8000 })) {
  req.respond({ body: "Hello World\n" });
}

Then executing the following command from a terminal:

$ deno run --allow-net exampleImport.js
> http://localhost:8000/

3.2. CDN hosting

This may seem counter intuitive as it acts as a centralised module host, similar to npm. But the advantage comes in using the ES module syntax (ESM), the native module system in JavaScript. Many old browsers do not support ESM but using the compact “import” and “export” syntax results in smaller and faster JavaScript code. The PikaCDN (https://pika.dev) aims to build a web where third-party libraries such as React and Vue can be loaded, cached, and shared across sites.

4. Stability

The Deno project had promised to maintain stable APIs in Deno, preventing too many legacy APIs that must be supported. The JavaScript APIs that were invented to interact with the operating system can be found inside the “Deno” namespace (e.g. Deno.open()) and these have been carefully examined, meaning that no backwards incompatible changes will be made to them. All the other functionality which is currently not ready for stabilisation in v1.0 has can be found hidden behind the --unstable command-line flag. These APIs may become stable as the project matures.

5. Conclusion

Deno is no match for Node.js which has been in development for over a decade with a strong community. However, it is becoming more production ready, and already is for some applications and use cases. In the future, it is likely that Deno will become a solid alternative to Node.js but until then we will have to continue working on projects, taking into account both options. Personally, I feel Deno addresses the problem of network resource optimisation well, instead of relying on more powerful hardware or increased processing power it seeks to make the most of what is available.