What Is Deno? Is It A Replacement For Node.js?

What is Deno Is it a replacement for node.js

If you have used Node.js, but don’t like its packet manager npm or you want a more secure JavaScript runtime environment than Node.js, then deno is there for you. 

What Is Deno?

Deno is a new runtime for JavaScript and TypeScript, created by Ryan Dahl- the creator of Node.js. It is intended to fix the design problems in Node.js. Like Node.js, Deno is essentially a shell around the Google V8 JavaScript engine, even though unlike Node.js it includes the TypeScript compiler in its executable image.

JavaScript And Deno-

According to Dahl, Javascript lacked some features that are useful for Node.js. Some of these are added to JavaScript over the years as a part of the ECMAScript (ES) standard. Javascript has callbacks and events forever, but it can make the code more complicated particularly when you need to chain asynchronous actions. Syntax is more readable with Promises. Promise is a returned object that  represents the eventual completion or failure of asynchronous operation, to which you can attach callbacks. Declaration of a function async simplifies the syntax and allow you to use await in the function to pause in non-blocking way until the promise settles.

At the time of Node.js creation, the de facto standard for JavaScript modules was CommonJS, which npm supports.  Afterward, ECMAScript committee officially support a different standard, ES Modules which jspm supports. ES Modules are supported by Deno.

TypeScript is a typed superset of JavaScript. It compiles to plain JavaScript. TypeScript adds optional types, classes and modules to JavaScript and supports tools for large-scale javascript applications. Deno includes an image of the TypeScript compiler as a part of its runtime. If you pass a TypeScript file to Deno, it will first compile it to JavaScript and after that pass to V8 engine.

Features of Deno-

1. Security (permissions)-

One of the most important features of Deno is- Focus on security. Deno executes the code in a sandbox, means runtime doesn’t have access to- File system, Network, Execution of other scripts, and the environment variables.

How does the permission system works?

(async () => {
 const encoder = new TextEncoder();
 const data = encoder.encode('Hello world\n');
 await Deno.writeFile('hello.txt', data);
 await Deno.writeFile('hello2.txt', data);
})();

According to the above example, script creates two files- hello.txt and hello2.txt with the message Hello world. The code has no access to the file system, as it is being executed in the sandbox. Deno namespace provides many fundamental helper functions. With the use of namespace, we are losing the browser compatibility.

When we run it with execution of- 

deno run write-hello.ts

We are notified with following warning-

⚠️Deno requests write access to "/Users/user/folder/hello.txt". Grant? [a/y/n/d (a = allow always, y = allow once, n = deny once, d = deny always)]

If we select the allow always option, we will get the access only at once. It we will select deny option, it will show the  PermissionDenied message and we will not have any error-handling logic.

Now, if we use the following command to execute the script- 

deno run --allow-write write-hello.ts

Both files are created and there are no prompts.

Beside the –allow-write flag for the file system, there are some other flags are available to enable network requests, access the environment and to run subprocesses and these are –allow-net, –allow-env, and –allow-run respectively.

2. Modules-

Deno, loads modules by URLs.  Most of you will be confused by an import statement with URL like-

import { assertEquals } from "https://deno.land/std/testing/asserts.ts";

With the use of URLs, deno packages can be distributed without a centralized registry such as npm. When we import the code by URL, it is possible for package creators to host their code where they see fit- decentralization at its finest. No extra package.json and node_modules.

At the start of application, deno downloads imported modules and caches them. As they are cached, Deno will not download them until we particularly ask for it with the –reload flag.

Comparing Deno With Node.js-

1. Architecture-

Like Node.js, Deno is based on Chromium’s V8 JavaScript engine and its makes use of event-driven, non-blocking architecture. Both differ in the languages they’re written in. Node.js use C++ with libuv with its I/O library and Deno use rust with Tokio.

2. API-

For API, Deno is its thing. Everything is written with Typescript and async API is based on Promises. Main functionalities are restricted, while other can be found in the Standard Library. From an overview, it looks nice but when you came to know that API changes means hard time converting Node.js codebase to Deno.

3. ES Modules-

Current module system of Node.js is CommonJS, even though the standard for JS has been ESM. Node.js support ESM but this feature is (v14.x.x) marked as experimental, forcing the JS community to use either one or other.

Here come the Deno with spoort of its ESM and ESM-only module.

4. Security-

It is one of the most important points. When compared to Node.js, it sandboxes the execute code and allows access to selected parts of the system. Means access to disk, network and sub-processes can be easily limited by passing the appropriate flags.

5. Dependency Management-

Deno brings changes to dependency management. Deno takes a complete different approach to dependencies. Regardless of having an NPM like registry and package manager, Deno imports and uses dependencies from URLs-

import { serve } from "https://deno.land/std@0.50.0/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" });
}

Then the downloaded modules, are stored on your machine. That means no node_modules anymore!

Deno also gets rid of omnipotent package.json file. There are not alternative to it other than deps.ts file, that acts like a re-directing type of file for external modules:

export { assert } from "https://deno.land/std@v0.39.0/testing/asserts.ts";
export { green, bold } from "https://deno.land/std@v0.39.0/fmt/colors.ts";

For NPM registry, deno can now load dependencies from URLs and is not required with Node.js. If you are interested in such an option, Deno provides its own package hosting.

Final Words-

This is all about the Deno and how it differs from Node.js. If you have any confusion, consult with Solace experts. We have dedicated developers to help you through consultation and development. Connect with Solace and get a free quote for web development. We will be happy to help you.

Related Post