In 2018, Ryan Dahl, founder of the Node runtime environment for JavaScript gave a talk at JSConf —10 Things I Regret About Node.js. It’s not often that you hear from the founder of a technology turned paradigm that he regrets some of the major features of his own invention. If you haven’t watched the talk, I highly recommend it. He highlights the deficiencies that exist in Node, some of which we, as developers, consider features.

In the talk he also introduces Deno, a new runtime environment that uses V8 but is built in Rust. At the time, he called it his side project, because Ryan Dahl makes a hobby out of tinkering with entirely new runtime environments. Nevertheless, the introduction of Deno almost immediately spawned a thousand tech articles asking the question: will Deno replace Node?

The short answer is… maybe.

The Five Features I Love In Deno

I spent a long time in the Deno ecosystem while developing an open source tool with a small team of engineers. We contributed to the community in part because we found it exciting. Our tool helps developers identify memory leaks in production level applications. These are the kinds of tools that Node has had for years at this point. By the end of the first release, these were the features that stood out to me that Deno provides.

No package.json and No node_modules

Say goodbye to npm, package.json, and the bulky node_modules folder. If you’re a Node developer, you may be thinking — but aren’t those things features of Node? No, actually npm and package.json were created separate from Node to handle easily sharing application dependencies. In reality, node_modules caused a lot of problems.

For instance, if you write in full-stack JavaScript or TypeScript, say with React and Node, you may have node_modules folders installed all over your computer’s filesystem, many of which contain the exact same modules.

Deno takes a different approach. It aims to mimic the web. It imports modules by pointing to their address on the web. Below is an example of importing the Oak framework (a tool for building RESTful APIs like Express.js) in Deno.

import { Application, Router } from "https://deno.land/x/oak@v11.1.0/mod.ts";

Now, you don’t require the package.json file and you don’t npm install a node_modules folder in your project’s repository. Instead, you can import modules directly from the web into your project in decentralized snippets like this one.

You might be asking yourself — what if the sites containing these modules go down? Not to worry, Deno caches these modules in your computer the first time you run your code. Or, before running, you can ‘deno install’ the modules directly in your terminal. The benefit is that these files are only cached once. This eliminates all that pesky node_modules bloat.

Out-of-the-Box TypeScript

Personally, as a developer that started with Java and C++, I’m a huge fan of TypeScript. So is Ryan Dahl. TypeScript helps you type-check your files and eliminates pesky errors, usually from poorly written code. It does this before you run anything. It’s your check to make sure you are creating your product with the least number of avoidable issues when it reaches production.

Deno provides out-of-the-box TypeScript integration. Node, on the other hand, requires you to import yet another package to deal with TypeScript integration. It also forces you to deal with configuring transpiler tools for that TypeScript. You don’t need to mess with this in Deno. That means you start building TypeScript projects faster in Deno than you would in Node.

If you absolutely loathe TypeScript (I am judging you), then you can also write pure JavaScript in Deno. Deno can also process JavaScript given that TypeScript is just a superset of the language (but seriously, change your mind).

The Standard Library

Don’t even get me started on the standard library provided by Deno. Having a standard library was a huge benefit to our team while creating this project. Being primarily Node developers, we initially started our project using a third-party websocket library to communicate with a GUI frontend that graphed memory statistics from a developer’s application.

Much like Node developers often discover, that open-source module had a lot of bugs and very little documentation. After much fussing over the broken tool, we moved to Deno’s standard websocket library and our problems were instantly solved.

Node aimed to be a minimalist environment, and it succeeded in that to a fault. It has an extremely minimal standard library. Many of the frameworks developers are using every day are open source and are not being updated or maintained. Or, for some of them, those updates are taking unbelievably long (looking at you, Express v5.0). Deno maintaining a small set of standard tools is so important for developers who need modules to be working, documented well, and updated as needed.

No Build Tools

If you’re using Node, there’s a 99% chance you are also using or have used Webpack. I’m just going to say it: Webpack is great… until it’s not. Now, that’s solely from a developing viewpoint — Webpack does so many important things under the hood like creating a dependency graph of your file, transpiling your JSX/TSX, and minifying and uglifying your code.

At the same time, I have banged my head against a wall trying to solve a Webpack error (turned out I needed to switch the order of two of my loaders) and that was not the only time. Webpack is a consistent source of frustration for new and experienced developers alike. Just look at some of these angry posts, (viewer discretion is advised). Or go browse through the 40k+ questions about webpack on Stack Overflow.

When we started working with Deno, we were thrilled to learn that there are no extra build tools required. No Webpack, no Vite, no Babel, no Rollup, no Gulp — nothing but deno compile. In fact, for our GUI we used the Deno Fresh framework which is a zero configuration, zero build step framework for the frontend, which brings us to Deno Deploy.

Deno Deploy

Probably my favorite feature related to Deno, but not directly a part of the environment, is Deno Deploy. Deno Deploy is a way to deploy your applications to the web with literally zero effort.

I’m not joking — try it. You can create a new Github repo, add the Deno Fresh boilerplate with a single terminal command, and deploy at the edge on deno.dev in under ten minutes. Then, all the updates to your Github repo will show up in seconds to [your app name].deno.dev.

There are a lot of other great things about Deno Deploy but even from just a developer experience standpoint, it’s an amazing tool for cutting out unnecessary complexity in deployment.

The Not So Great Parts of Deno

While I really enjoyed the Deno environment, there were some noticeable issues and annoyances, even with the features I highlighted above.

Bugs, Bugs, Bugs

We can’t give them too much flack — Deno is a new tool and its developers have warned the community that some features are unstable. However, there were some very sloppy issues in Deno that didn’t seem to be a fault of a rapidly evolving codebase.

The biggest one for our team was that one of the standard Deno functions, Deno.memoryUsage, returned an incorrectly labelled variable. They reported a value for the resident set size that was actually a number derived from a V8 function that measures the committed heap size. These are very different values, and our team spent days on a tight schedule trying to figure out why the numbers made no sense. We assumed it was us, turns out it was Deno. We submitted this issue ticket that has yet to be resolved.

The Security Features are Annoying

I understand and respect the security decisions made by Ryan Dahl when creating Deno. However, I found it extremely annoying during development that if I forgot an ‘ — allow-read’ or ‘ — allow-net’ flag, Deno would ask me for 50 different read or write permissions in a never ending slew of command prompts. You can build these flags into scripts, which we eventually did. However, in those early stages of development, I found that to be a particularly redundant choice.

The Documentation is Somehow Less Readable than Node’s

I don’t really know how you make documentation worse than Node’s, but Deno did. So forget all that nice gushy stuff I said about Deno’s standard library being so important because, while it is, they still didn’t document any of it well. I’m giving the Deno team credit: it is pretty early on for this environment. But I would also implore them improve their documentation. Developers should not be struggling with the basic syntax of your standard library before hitting any real technical challenges.

Backwards npm Compatibility

This one isn’t included in the good or the bad — for me it’s yet to be decided. One of the biggest criticisms leveled against Deno was that many of the npm libraries were completely inaccessible in a Deno environment. That is a huge problem for transitioning an existing project from Node to Deno. What do you do with all the dependencies? Almost all the articles pointing to Deno’s low adoption had this issue at the forefront.

However, in that video of Ryan Dahl linked at the top of this article, he claimed he would never make Deno backwards compatible with old Node modules. He believed that would just be a remake of Node. Except there’s one problem: he just did. Deno stabilized npm compatibility in the past few months while we were in the midst of creating of our open source tool.

I’m uncertain how to feel about this transition. Deno had a lot of innovative frameworks popping up due in part to the limited availability of any of the older, more familiar frameworks out there. I personally love innovation, and I agree with Ryan Dahl’s comments from his presentation — by establishing backwards compatibility, he made Deno another version of Node.

To be honest, I think it’s more likely that the pressure of Deno forces Node to improve. In fact, Node has already introduced HTTPS imports earlier this year, so those issues with node_modules may not last too long. Since I’m primarily a Node engineer, that’s what I’m hoping for.

I encourage you to try Deno for yourself and see how you like it!

If you want to check out our open source tool, you can find our CLI tool and our GUI on Github, or you can download the tool here. Star us to get all the latest updates and, if you enjoyed this article, follow me for more like this!