Deno vs. Node.js — Here are the most Important Differences

Is Deno the new Node.js? Or is it just a nice alternative? In this article we will go into some important differences and features — have fun!

The history and story behind Deno

Now already treated by some as the next big thing, and come to displace Node.js, both have one origin: Ryan Dahl

Dahl worked on the Node project since 2009, but stepped back from it a few years later. In 2018 he gave the 10 Things I Regret About Node.js talk, in which he also announced Deno — a new JavaScript & TypeScript Runtime.

Funfact: “Deno” is actually an anagram for “Node”.

But should all Node.js developers now fear that Ryan Dahl himself has created the competition and Node will be replaced?

The answer seems to be “No.”, as Dahl presented it in another talk you can find in the link

Source: YouTube

As Dahl himself says in this talk, Deno is still new. At the current time, more precisely in version 1.0.0. Node, on the other hand, is already a bit older — and essentially both have the same purpose.

They are JavaScript Runtimes, so we can use JS outside the browser, e.g. for web servers.

But how things will look like between Deno and Node in a few years, hardly anyone can tell.

Deno and Node under the hood

Node.js is based on C++ uses the V8 engine to execute JavaScript code.

The V8 engine itself, was originally developed for Google Chrome to execute JavaScript in the browser very quickly. Meanwhile even the new Microsoft Edge version is based on V8.

Deno also relies on the V8 engine, but instead of C++, Deno is also based on Rust — a programming language that is supposed to deliver similarly good performance as C++, but also places special emphasis on security: Memory access errors or buffer overflows should be avoided.

And security is one thing — a common criticism of Node.js is that once a node app is running, it can easily access the file system or the network for example.

Deno wants to avoid this by requiring the person running the Deno app to first allow what Deno wants to do.

A good example of this is the following TS code, which we find as a getting-started example on the official Deno website:

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

As you can probably already see, this is a very simple web server, and we would have to execute the whole thing as below:

deno run app.ts 

But here the security measures of Deno intervene, an access to the network was not yet allowed by us, therefore the following message appears:

In order for our app to be allowed to access the network, we must first give it authorization:

deno run --allow-net app.ts 

Now our little web server is running successfully — but the nice thing is that we only gave approval for the network. The app still can’t access the file system just like that, we would have to allow it manually first.

Goodbye NPM, hello ES6 import

Another thing with the security of our app is NPM: Not only does using NPM often result in huge node_modules folders, but there is also the problem with node and security: If we use NPM to install a package for our node app, it can theoretically do something else on the sly.

In the past, there has been a scandal with NPM packages, which, for example, have spied out user data.

Deno does not rely on NPM at all — instead we import our libraries via the URL, as shown already in the code example above.

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

The library we want to use is downloaded with it the first time it is executed and then cached:

This can be seen when we simply copy our code for our web server and store it in a completely different location on our server or PC and execute it again. The libraries do not need to be reloaded.

If you want to read more about the dangers of NPM:

The biggest scandals of NPM

The huge tree of dependencies in the JavaScript world makes development very pleasant. But sometimes it overwhelms an…

medium.com

The window object — also outside the browser

The window object is the parent object in the browser, from which some of the most important functions for JavaScript are derived.

One of them is, for example, fetch. The native alternative to libraries such as Axios unfortunately has no place in Node.js — there you have to find a solution with libraries — but not in Deno.

Because in Deno the window object is available, as you can see here in the documentation: https://deno.land/typedoc/interfaces/window.html

And where window is, we can also use fetch, just like we would in a browser.

Let’s just try this out, and you will see you can run the following code in the browser, but also in a Deno application:

fetch(“https://jsonplaceholder.typicode.com/todos/1")
  .then((response) => response.json())
  .then((json) => console.log(json));

If you want to read more about the window object, check this out:

The Window & Document Object In JavaScript — 7 Useful Things You Can Do With Them

Why not use Vanilla JavaScript again? Here are some cool features with the document & window object that you might not…

medium.com

TypeScript support out of the box

TypeScript is of course a matter of taste, celebrated by many, but also seen by some as unnecessary. But what I can say is that both sides can be happy with Deno — because Deno offers TypeScript support straight out of the box, but of course it also supports classic JavaScript.

You can see this by the fact that you can easily write code with both languages, save it as .ts, or .js and simply execute it as usual with deno run. In my eyes it’s not an absolute game changer compared to Node.js, because you can easily get a TypeScript support there, but it’s definitely a cool thing.