Moving from Node.js to Deno

The Issue

I still vividly remember a question from my internship with my mentor. He was a Senior responsible for guiding me at that time. When I saw him working, I exclaimed: "Wow, do you code in Java too?". He said nothing, just smiled lightly and continued his work. The programming world was very small for me back then; without knowledge and experience, everything seemed strange. How could one person know so many things? Without enough experience, I was limited in my perspective on matters within my understanding.

As a long-time Node.js developer, I initially loved JavaScript and Node for its freedom. There were no rules; any creativity was welcomed. Yet gradually, I grew to fear the very things I once praised. JavaScript was too simple to become complicated.

A few years ago, I first heard the name Deno. Particularly since it was created by the author of Node - Ryan Dahl, it caught my attention. In a talk about 10 things Ryan regretted doing with Node.js (which I summarized in another post), he always felt remorseful about the popularity of Node.js and hoped to create something that would bring JavaScript back to the path it was meant to follow. Deno was born as a child correcting all the weaknesses of its parent. However, many people seemed indifferent to Deno. There were even many questions from the start about who would actually use Deno in a production environment!?

I was the same; I wasn't really concerned about Deno's existence, more out of curiosity whenever the brand launched a new product. Partly because my work primarily involved Node.js, so why switch to Deno? Even if I were to explore it, I would quickly forget or get bored due to not having any projects to work on. While rebuilding my blog, the name Fresh suddenly appeared and attracted my attention. It encompassed many criteria I needed at that time. Fresh is built on Deno, meaning I needed to understand Deno before I could work with Fresh. But would there be enough time to learn now? Especially when I needed to rebuild the website as quickly as possible.

Thinking that way, I eventually started working on it. It only took a short time to get used to the new syntax and new components. Other than that, essentially, there isn’t much difference between Deno and Node. Therefore, in today’s article, I’ll outline some fundamental concepts in Deno that are similar to Node.js. This will help readers grasp the similarities if they decide to switch to this new tool.

From Node.js to Deno

TypeScript Support by Default

While with Node, we need to integrate TypeScript manually or use a framework that has TypeScript integrated if we don’t want to start from scratch. The characteristic of this approach is that there is always a build step to compile the code into JavaScript for final use. With Deno, we don’t have to struggle anymore as it supports TypeScript by default. This means you can run a .ts file directly with Deno.

# index.ts
const str: string = "Hello World!";
console.log(str);

Then just run:

$ deno run index.ts
Hello World!

Isn’t that wonderful?

Package Management

npm is a very famous package manager that comes with Node. To install any additional dependencies, you just need to use the command npm install, and all packages are downloaded from the website npmjs.com. When downloaded, they are neatly placed in the node_modules folder of the project. This inadvertently makes node_modules become a "black hole" because it is very heavy. Moreover, for as many Node projects there are, there are as many node_modules folders, creating a waste of memory resources.

Deno does not have node_modules or package.json. Deno does not have a specific package manager; instead, it uses a unique import method. For example, if you want to use a package from an online address? It’s very simple.

import { serve } from "https://deno.land/[email protected]/http/server.ts";

Or from any other repository like jsr:

import { camelCase } from "jsr:@luca/cases";

Or even from npm:

import dayjs from "npm:dayjs"

So what does npm install correspond to in Deno? You may not need to care much since with the import syntax as above, every time you run the project with the command deno run, it automatically finds and downloads the packages for you.

Although recently, Deno has been trying to support Node.js, the package management in Deno is gradually becoming similar to Node. Therefore, I emphasize that if you are simply using Deno, you may not even need to care about the npm package manager in Node.

package.json

package.json is an extremely important file in Node. It holds a lot of information related to the project, such as name, version, scripts to start, and dependencies in the dependencies section.

In Deno, we also have a similar file called deno.json. It has a structure similar to Node. An amazing thing is that you don’t even need this configuration file in Deno, and you can still run the project normally.

Module System

Node.js has been around for a long time, at a time when JavaScript did not yet have an official module system. At that time, Node chose CommonJS as the default module system. Later, JavaScript introduced a module called ESM. As a result, Node always has at least two import styles: require, representing CommonJS, and import/export, representing ESM. We cannot use require alongside import/export, although there are many tools to help convert require syntax into import/export or vice versa. This inadvertently makes the code messy and sometimes impossible to decipher the mystery behind this hybrid module system.

Deno fights against this mess. This means you only need to focus on import/export. All packages for Deno use the ESM syntax. There are even repositories like jsr that only allow uploading modules that support ESM to prevent fragmentation of the module system.

Permissions

In Node, you can simply use a single command to start most applications. For example:

$ node index.js

Or with an environment variable along with input parameters:

$ NODE_ENV=production node index.js debug

Deno is not that simple. All permissions are restricted by default. You need to provide permissions when running. These permissions include access to the file system, network access, etc. If you do not grant permissions while the application uses it, you will receive an error message. For example, to grant network access:

$ deno run --allow-net index.ts

Or if you want to "go back" to Node-like behavior and grant all permissions, you just need to:

$ deno run -A index.ts

Integrated Testing Tools

JavaScript lacks any official testing and code formatting tools, which extends to Node.js as well. Although there are many third-party tools that can do this, in general, they are fragmented across different projects based on each developer's preferences and styles.

Deno integrates testing, formatting, and syntax error checking tools by default, eliminating the need to use any third-party tools. This creates consistency across the entire project.

Multithreading

In Node, we are familiar with the names Cluster, Child Process, or Worker Threads, often used for multithreading. While Cluster utilizes multiple CPU cores to clone processes, Child Process or Worker Threads create child processes to enhance processing efficiency and prevent event loop blocking. Deno does not have such features.

Deno tries to adhere to Web APIs; therefore, the alternative solution for multithreading is based on the Service Worker API. The implementation? The web does it that way, and so does Deno. That is the benefit of consolidating everything, and it is also why Deno follows Web APIs to alleviate pressure on developers.

Debugging

Both Node and Deno have the same way to enter debugging mode, which is by adding the --inspect flag.

$ deno run --inspect index.ts

Compatibility with Node.js

Although Deno initially declared that it did not support Node or npm because most packages on it were compatible or used Node APIs. Deno was built from the ground up, unrelated to Node, thus it did not support Node APIs.

Over time, the Deno team recognized this lack of support as an unacceptable shortcoming. Users could not abandon the vast repository from npm, prompting Deno to quickly revert to supporting Node.js. In the latest updates, they announced that Deno could run most npm packages or even use Node APIs within Deno.

For example, fs is a famous module in Node. However, you can still use fs with Deno.

import * as fs from "node:fs";

Conclusion

Above are some notable points to help you envision the picture when moving from Node.js to Deno. Overall, there aren’t too many differences since both use JavaScript or TypeScript. The biggest differences lie in the module system and package management. Once you get accustomed to these two points, you will soon master Deno.

What about you? Have you used Deno in any projects? Are there any noteworthy points when transitioning from Node.js to Deno that weren’t mentioned in this article? Please leave a comment below the article. Thank you!