The Problem with Node.js
Ryan Dahl, the creator of Node.js, gave a talk in 2018 called “10 Things I Regret About Node.js.” In this talk he explained what he wished he’d done differently. For those who want to learn more about the initial concepts of Node.js, this is a great talk.
The essential idea behind the creation of Node.js was to focus on programming event-driven HTTP servers. Here are some the things that Ryan Dahl regrets about Node.js:
Promises were introduced as part of the ES6 (ES2015) and landed in Node.js only in February 2015. They’re very important, especially due to the async/await primitives that came up in Node.js in February 2017.
The possible usage of Promises when Node.js was developed would contribute to the eventual standardization of async/await. They’re a necessary abstraction for async/await.
_node_modules_ folder contains libraries downloaded from npm. Every time we start a new project, we need to install new dependencies, and by doing that, our
_node_modules_ folder gets heavier and heavier.
Unfortunately, there’s no way to undo this in Node.js. Dahl said that “it’s impossible to undo now.”
The package.json file is a common file created at the root directory of a Node.js module by running a command. There are a few things that he regrets about package.json, and one of the things is that the package.json file doesn’t allow relative files and URLs to be used when importing—the path defines the version. By doing that, there would be no need to list dependencies.
Here’s how Deno is different from Node.js:
One of the programming languages that has been trending in the development community lately is Rust. This language has been very popular for a lot of factors, such as ensuring that our programs are free from undefined behavior and data races, more memory safety, etc. Rust is a very safe and fast language.
A safer and faster language makes a big difference for Deno—delivering a good performance, without any memory safety issues, undefined behavior, data races, etc.
One of the issues a lot of developers complain about in Node.js is security. The choice of using Rust was not only right for allowing the runtime to be faster and bug-free, but also to improve the security. After an app starts running, it can easily access your file system or your network—this is a very serious security flaw.
Deno solves the security by executing the code in a sandbox. The runtime has no access to your file system or network. Unless you specify that you want to enable or disable access, a module has no file, network or environment access. Instead, you can use command-line arguments to enable or disable different security features or do so programmatically.
For example, if we want to grant read-only access for a file, we could do the following:
deno run --allow-read test.ts
Deno only requires qualified modules names, which means that we should include the extension of the file when importing it. Imported modules are specified as files in Deno.
import main from "./main.ts";
Deno includes a built-in package manager for resource fetching, so there’s no need to use npm (Node Package Manager).
Deno uses the official ECMAScript module standard rather than the CommonJS. Deno uses the
import syntax from ES6 instead of the
Another nice thing about Deno is that you cache all the modules that you download. So, if you download a module, Deno will automatically cache it, and not download it again, only if specified with the reload flag.
We can download Deno using Homebrew on macOS or Linux:
brew install deno
If you’re a Windows user, you use Chocolatey to download Deno, with the following command:
choco install deno
To create a simple example using Deno, let’s create a new folder called
deno, and inside this folder, we will create a file called
Remember, Deno supports TypeScript out of the box. To run our first Deno file, let’s create a simple
const variable and show it in the terminal.
const hello: _string_ = "Hello Deno!"
To run our code, all we need to do is go to the right directory and give it a run command passing the name of the file we just created. In our case, we would do the following:
deno run deno.ts
Node.js Is Not Dead
Once a new framework is released, developers may already think that everybody will migrate to it. That’s not different in the case of Deno. We’re seeing a lot of people already claiming that “Deno is the future, we should abandon Node.js.”
Deno is, in fact, a nice and awesome surprise in the web development world. It brings new concepts, new ideas, new paradigms, and concepts that we should learn, but some people are already claiming the substitution from Node.js to Deno in all their applications.
When you think almost every modern application was built using Node.js, it’s insane to think that people will instantly migrate to Deno. Just imagine how many applications were built using Node.js, how many services and APIs were possible to be created because of Node.js, not even to mention that Node.js has reached a point where it’s really mature and stable, with a huge community behind it.
We should consider both. But, for now, Node.js is a better option without a doubt. It’s stable, more mature, with more features, and the community is way bigger. Deno might be the future, but Node.js will not go away any time soon.