Nate Sales

Adventures in serverside JavaScript: Node.js vs Deno

June 17, 2020

I’ve enjoyed the backend side of web development far more than frontend for a while now. The monotony of CSS combined with the weird type system of JS makes creating a modern frontend quite a chore. Though recently after a conversation with a few friends, I decided to give it another try, this time with React.

React is a JavaScript library for building reusable “components” out of HTML (More specifically JSX, but they’re eventually complied to HTML). Node.js has been the go-to runtime for JS and React for years now. But just a few weeks ago Ryan Dahl (the creator of Node.js) announced v1 a new JS runtime, Deno. Like Node, Deno is based on V8, but brings many notable improvements when it comes to developer experience compared to Node.

One of the big complaints I have with Node is its package manager NPM. There are thousands of seemingly identical packages, a worrying and buggy vulnerability auditor which fails to fix vulnerabilities most of the time, and the ridiculous number of dependencies that NPM decides to install for a relatively simple project. Deno fixes this issue by removing the external package manager altogether, instead using a similar system to Go with simple URI-based import identifiers. Deno handles local caching of the imported libraries and will fetch the resource externally if needed. This also brings the advantage of not using a package.json file which can get a bit unwieldy. Instead, each dependency can be imported from its URL:

import React from "https://dev.jspm.io/react@16.13.1";

Another issue with Node.js is security. Out of the box Node can access all sorts of potentially sensitive OS functions like disk and network access. Deno fixes this as well by executing the code in a secure sandbox and requiring explicit permission from the server before accessing storage, the network, etc. For example to read a file you must pass the --allow-read flag: deno run --allow-read index.js

Deno also comes with some convenient improvements such as TypeScript support out of the box. Of course you can use TS with Node, but Deno works with both JS and TS without installing anything extra.

It’s important to note that Deno 1.0 was released just a few weeks ago at the time of writing, whereas Node has been around for years. As such Deno has far fewer StackOverflow posts and real world bug reports. Even so, development is active and new releases are coming out quite frequently. I’m excited to continue working with and learning about Deno, and look forward to the continued development and improvements over Node that Deno has to offer.