Comparing Node.js and Deno

Preface

If you’ve been following the web development space, you’ve probably heard a lot lately about Deno — a new JavaScript runtime that’s also being considered the successor to Node.js. But what does this mean, do we need the “next Node.js”?

What is Deno?

To understand what's going on, we first need to look at what Deno actually is. As I said before, this is a new JavaScript runtime, which is the environment in which your JS code will be executed. It was originally created by Ryan Dahl, who previously compared Deno to Node.js for us.

Ryan announced Deno in a JSConf EU 2018 talk titled "The 10 Things We Regret About Node.js" . From that piece of information alone, you can tell how things are going. Deno was created from scratch to be the better implementation of Node.js currently available.

But what's wrong with Node.js? How does Deno stack up against its more established cousin?

Comparison with Node.js

Although Deno and Node.js are similar tools that perform similar operations, the differences between them go far beyond just a reversal of names.

Architecture

Let's first take a look at the internals of Deno. Like Node.js, it is based on Chromium's V8 JavaScript engine and uses an event-driven, non-blocking architecture. But the main writing language of the two is different. Node.js is mainly written in C++, with libuv as its asynchronous I/O library, while Deno is written in Rust, and its asynchronous library Tokio is also written in Rust.

We'll have to wait and see how these differences translate into real-world performance. As it stands, according to Deno's benchmark, the difference between the two is indistinguishable, or at least very subtle.

ES modules

As you probably know, the current module system of Node.js is the so-called CommonJS (the one with require()), although ESM (ECMAScript Modules (modules with import and export)) has been an official standard for JS for quite some time, dating back to ES6 introduced in 2015. Of course, Node.js does support ESM, but this feature is currently (v14.xx) marked as experimental, forcing the JS community to still use the CommonJS module system or other bundlers.

This is what Deno is coming with, which only supports ESM modules - a real module system!

Dependency Management

But beyond ESM, Deno brings many more changes to dependency management for Node.js.

Deno takes a completely different approach to dependencies, based on experiences with the npm registry with millions of packages and the black hole of the node_modules directory. Deno does not require a registry or package manager like npm, but instead imports and uses dependencies directly from URLs:

import { serve } from "https://deno.land/[email protected]/http/server.ts";
const s = serve({ port: 8000 });
console.log("http://localhost:8000/");
for await (const req of s) {
    req.respond({ body: "Hello World\n" });
}

The downloaded modules are then stored invisibly somewhere on your computer. Yes, this means no more node_modules!

But wait! There's more... or should I say less, because Deno also gets rid of the one-size-fits-all package.json file that is made now. There is no alternative to the deps.ts file, which acts more like a redirection sort file for all external modules:

export { assert } from "https://deno.land/[email protected]/testing/asserts.ts";
export { green, bold } from "https://deno.land/[email protected]/fmt/colors.ts";

As for the NPM registry, since Deno can now load dependencies from URLs, this is not the same requirement as with Node.js. But if you’re interested in this option, Deno offers its own package hosting.

TypeScript and other features

Yes, you read that right — JavaScript is the primary language used with Deno, with TypeScript also supported. The support is built-in and requires no custom registers or complicated setup.

However, in addition to TS support, Deno has many other useful tools built in. Most of them appear in the form of commands, such as fmt, bundle or doc, which provide functions such as code formatting, packaging and document generation respectively.

API

As for the API, Deno is definitely its own thing. Everything is written in TypeScript and the asynchronous API is based solely on Promises. The core functionality is limited to the bare minimum, while everything else can be found in the standard library.

So on the surface, this all looks good and very promising, but the euphoria immediately fades when you realize that changing all the APIs means converting a Node.js codebase to Deno is much more difficult. Sadly, everything new and better has to come at a price, right?

Safety

Finally, security is one of the most important aspects of Deno. Compared to Node.js, it sandboxes the executed code, allowing access to only selected parts of the system. This means that access to things like disk, network, and subprocesses can be easily restricted by passing the appropriate flags.

So, what does this mean?

So I've just introduced you to some of the features of Deno in a very brief way so that you can get the gist of it all. You can dig deeper if you want (I’ll put some links to great articles at the end of this post).

Let’s get back to the main question of this blog post – what does this mean? Well, mainly because Deno v1 was already released on May 13, 2020 (exactly one year after its initial release). Everyone is now asking if this will be the “next big thing” or if it will replace Node.js entirely.

Personally, I think it's too early to discuss this. Given the size of the project and the expectations of the community, the project, despite being at v1, still has a long way to go to become a viable Node.js replacement. Remember, these technologies (even with all their differences) are still trying to do the same thing and at the same time have to compete with each other. And the fact that Node.js development is not going out of style (e.g. Promise-based FS API variant or ESM experimental support) means we’ll probably live in a world with two JavaScript runtimes for a long time (as if that’s a new thing for JS developers). And keep in mind, I haven’t even mentioned the massive NPM registry and ecosystem, which, while not perfect by any means, still adds a lot of value to Node.js — something Deno doesn’t have yet.

Bottom Line

All in all, Node.js isn’t going anywhere, and if you’re starting a serious project for production, it’s probably best to stick with Node.js, at least for now. That being said, there is nothing (certainly not me) or anyone that can stop you from using Deno, even for serious projects. It certainly seems like the future, but we simply aren’t there yet.

The above is the detailed content of comparing node.js and Deno. For more information about node.js and Deno, please pay attention to other related articles on 123WORDPRESS.COM!