What is Deno? The Modern Node.js Alternative

Not many projects have caught my attention like Deno has.

In this article, I’ll do my best to describe simply what Deno is and what sets it apart from Node.js.

Deno? What is Deno?

Deno is a dinosaur. In particular, Deno is this dinosaur.

But wait, there’s more!

If you’re familiar with Node.js, you’ll notice that Deno is essentially Node.js with a few different rules.

It’s supposedly a step up from Node.js.

That begs the question: what was wrong with Node.js in the first place?

What’s wrong with Node.js?

Node.js has been around since 2009 and has blown up to be our main source for JavaScript server-side development.

The person behind Node.js, Ryan Dahl, is also the creator of Deno.

However, as he created Node.js and made the design decisions as to how to structure everything, he realized that Node.js had many shortcomings that include but are not limited to:

Lack of Promises: async APIs age poorly due to the lack of abstraction for async/await
Non-Existent Security: an installed package has complete access to your computer and network
Outdated Build System (GYP): Node is the sole GYP user while the V8 JavaScript Engine and Google’s Chromium browser have switched to GN
Cluttered package.json: there is no need for this module abstraction or bloated information such as license, repository, description, etc.
Complicated node_modules: the module resolution algorithm is over-complicated and deviates greatly from browser semantics
Ambiguous require() Statements: these statements are unnecessarily unspecific by leaving out the .js extension, forcing the module loader to guess what the user intended
Unnecessary index.js: this file complicated the module loading system and was especially unnecessary after package.json came around

These are all issues we could resolve one-by-one, but with Node.js running on millions of computers right now, it’s infeasible to make all these major changes to this JavaScript runtime.

Okay, seriously. What is Deno?

Deno is essentialy Ryan Dahl’s dream of what Node.js should’ve been.

It is a “secure runtime for both JavaScript and TypeScript” that began in 2018.

It was built with V8, Rust, Tokio, with inspirations from Go and Rust in particular.

Fun Fact: Deno is an anagram for Node. It can also stand for Destroy Node.

Here is a list of new features that Deno offers.

Deno has…

More security (no permissions by default)
Built-in tools (test runner, file watcher, bundler, etc.)
No package manager (node_modules, package.json, npm, etc.)
Deep modern JavaScript and TypeScript support (TypeScript is compiled automatically by Deno)
Browser-compatibility (built-in fetch, setInterval, setTimeout, global window object, etc.)
A Promise-based API: async/await support (no callback hell)
Remote script execution
Curated standard modules
ES module support
Sub-process execution using web workers
Native WebAssembly support

While each of these features deserves its own article, the most notable changes to me are these ones below.

No permissions by default

Deno is secure by default.

If I run a Node.js program, it can access anything and everything.

File system
Network
Environment variables
Script execution

If I run a Deno program, it will have no permissions by default. It can’t access any of those systems unless specified by a flag in the CLI.

--allow-all | -A
--allow-env
--allow-hrtime
--allow-read=<whitelist>
--allow-write=<whitelist>
--allow-net=<whitelist>
--allow-plugin
--allow-run

This is especially important because we are constantly running other people’s code when we install npm packages and such. Inside Node.js, theoretically, these packages can do whatever they want on our computer.

For example, suppose we wanted to create a local HTTP server.

// server.ts
import { serve } from "https://deno.land/std/http/server.ts";
const server = serve(":8000");

This script will try to access the network and return an error. To run this script successfully, we can add a flag to our deno command.

deno --allow-net=:8000 server.ts

We can see here that Deno sandboxes all applications by default, thereby making it more secure than Node.js.

Built-In Functionality

There are many tools built into Deno that make the development process easier.

Dependency inspector (deno info): provides information about cache and source files
Bundler (deno bundle): bundle module and dependencies into a single JavaScript file
Installer (deno install): install a Deno module globally, the equivalent of npm install
Test runner (deno test): run tests using the Deno built-in test framework
Type info (deno types): get the Deno TypeScript API reference
Code formatter (deno fmt): format source code using Prettier
Linter (deno lint): linting support for source code
Debugger (--debug): debug support for Chrome Dev tools

This has to be my favorite feature of Deno.

We don’t have to worry about setting up testing, linting and bundling frameworks for our applications. There are standard tools now that we know will integrate nicely with one another.

No package manager

As long as the code we want to use is on some server, we can import “packages” or “modules” directly in the import statement through a URL.

import { serve } from "https://deno.land/std/http/server.ts";

However, whether it’s a URL or a local file, you now need to include the file extension.

In Node.js, we could run either statement below.

import { serve } from "./server";
import { serve } from "./server/index";

In both of these scenarios, Node.js unnecessarily infers what the user wants.

In Deno, there’s no guessing since the file extension is required.

Conclusion

This guide is by no means comprehensive, but is rather a quick overview of the history and purpose of Deno with respect to Node.js.

I’m excited to see the direction Deno takes in the coming years. With such a large Node.js ecosystem right now, it may take a while for Deno to plant itself as a competitor in this space.

I’ll be sure to do more research on Deno and stay up-to-date on its activities, and I encourage you all to do the same!