Deno: The Official Node.js-Successor?

2020-05-18 12:38 UTC
Deno JavaScript Node.js
Deno: The Official Node.js-Successor?

Why is the announcement of Deno 1.0 possibly very exciting? Are there enough upsides to warrant a switch from Node.js to Deno?

The announcement of 1.0 was done middle of May 2020, but the initial announcement came in a presentation named 10 Things I Regret About Node.js by Ryan Dahl in mid-2018.

Deno is not just a rearrangement of the first two and the last two letters of "Node". It's built on top of more than 11 years of experience from Node.js running in production all over the world, by the original creator of Node.js. So this does not seem like another case of "I don't like how this project is handled, so I'm making my own fork", it's a completely new implementation.

10 Regrets about Node.js

The 10 things Ryan Dahl regretted about Node.js, which he acknowledges are impossible to change now, seem to be large motivators for the creation of Deno. It's worth noting that JavaScript has changed a lot during its 11 years of existence and Node has driven a lot of those changes.

The numbered regrets brought up in the talk were:

  1. Not sticking with promises: Promises allow the usage of async/await and avoids "Callback Hell".
  2. Security: Your linter shouldn't get complete access to your computer and network.
  3. The Build System (GYP): Awful experience for users. It's a non-JSON, Python adaptation of JSON.
  4. package.json: Not a strictly necessary abstraction and doesn't exist on the web. Includes all sorts of unnecessary information.
  5. node_modules: Massively complicates the module resolution. Deviates greatly from browser semantics.
  6. require("module") without the extension ".js": Needlessly less explicit. Module loader has to query the file system at multiple locations.
  7. index.js: Needlessly complicated the module loading system.

It was also mentioned that Deno supports the following things:

  • Unhandled promises should die immediately
  • Support top-level await
  • Browser compatible where functionality overlaps

Introducing Deno

Deno is a runtime for both JavaScript and TypeScript, built on the V8 JavaScript engine and Rust, with the asynchronous runtime Tokio.

The feature highlights, as of version 1.0, are:

Executing JavaScript/TypeScript

Deno being a single executable file, not needing a separate package-manager or package.json-file, an example of a working HTTP server application looks like this:

import { serve } from "https://deno.land/[email protected]/http/server.ts";
for await (const req of serve({ port: 8000 })) {
  req.respond({ body: "Hello World\n" });
}

There is no need to install anything beforehand or add any configuration-files. All you need to run is:

deno run example.js

Since the code is executed in a sandbox, which is secure by default, the explicit access must be granted for the fetching the remote dependency, by adding the flag --allow-net to the command-line.

The remote dependency is cached locally and only reloaded if the script is executed with the flag --reload.

Limitations

Deno 1.0 has some known limitations, which include things like:

  • No automatic compatibility with existing npm-packages
  • HTTP server performance is not as good as Node.js, even if it's not too far away
  • TypeScript performance issues

Since Deno uses ECMAScript modules, which uses import instead of require, any module using require has to be converted.

Summary

I'm surprised at how excited I am about the potential of Deno. For me, to have the creator of Node.js use a decade of learning to start over with a blank slate is what makes this a rare situation of high potential.

Some things I look forward to from Deno are:

  • A fresh take on a JavaScript/TypeScript runtime
  • First Class TypeScript Support
  • Skipping package.json and npm install when you just want to get started fast
  • Promises as default: Avoiding callback hell and mixed concepts between different parts of the code
  • Not having to deal with the node_modules-folder
Comments