What is Deno and it will replace NodeJS?

Deno V1.0.0 is scheduled for release on May 13. Here are some interesting facts that might come into play in determining that fact.

The short answer is that it’s (obviously) too early, but here are a few facts that may play an important role in determining that.

For starters, Deno is the creation of Ryan Dahl, who is also known for creating little things called Node.js. Sound familiar? Does this mean that Deno is actually a de facto replacement for Node, and should we all start planning refactoring? Oh dear! But if you want to learn more, read on!

Let’s start at the beginning

In 2018, Ryan gave a talk on the top 10 things that Node.js thought were wrong, and at the end of the talk, he unveiled Deno, which was a small project at the time, in which he called Node.js V2 to build your content, which was improved and more secure.

Here’s a video of the presentation:

Content of the tubing: www.youtube.com/embed/M3BM9…

Two years later, a date was set: May 13, the official release date for Deno 1.0. A new JavaScript runtime for the back end, not written in C ++ but based on the Tokio platform (which provides the asynchronous runtime required by JavaScript), written in Rust and still running Google’s V8 engine.

But what else is new?

Not only are we talking about a new JavaScript runtime that is fully compatible with current Node.js, but Ryan took the opportunity to add something to Deno that he felt was missing from earlier creations.

Security is integrated

By default, Node.js allows you access to everything, which means you can read and write to the file system, make outgoing requests, access environment variables, and so on. While there are benefits to being a developer with this access, there are security risks if you are not careful when writing your own code.

Therefore, Deno uses command-line arguments to enable or disable access to different security features. Therefore, if you want the script to be able to access the /etc folder, you can do the following:

deno --allow-read=/etc myscript.ts
Copy the code

This way, your code can read anything else from that folder and encounter a security exception. This is similar to how other platforms handle security. If you’re an Android user, there are many applications that have asked you to give them access to different systems inside the phone (such as contacts, phone calls, folders, etc.), and the same concept can be applied here. By using these flags on the command line where the script is executed, you can provide the permissions your code needs.

A more complete standard library

JavaScript has improved its standard library since the first Node release, but it still has a long way to go compared to other languages. Deno also tries to improve on this and claims to have a very complete standard library that allows developers to use official tools to perform basic tasks while only using external libraries (ALA NPM) for complex tasks. In essence, Deno provides, right out of the box, the ability to add color to terminal text, work with external data structures (such as binary, CSV, YAML, etc.), generate UUID and even write WebSockets. There are other more basic modules available, such as file system access, date helper functionality, HTTP-related functionality and much more

Integrated Typescript

You read that right, if you’re a fan of TypeScript, Deno can do what you need, no external tools are required, and the conversion to JavaScript is done in-house by default, so don’t worry.

Although Deno handles a lot of things by default, you can override the configuration with your own tsconfig.json file:

deno run -c tsconfig.json [your-script.ts]
Copy the code

The default configuration is to use strict mode, so any improper encoding practices are immediately warned.

There are no more NPM or node_modules folders

Because everyone and their past has something to say, this is a big problem. Is it too bloated? Are you distributing dependencies in the wrong way? This is definitely one of the most controversial aspects of Node, and Deno has decided to abandon it entirely.

So how does Deno handle dependencies? So far, just allow you to need modules everywhere. In other words, you can simply do this:

import * as log from "https://deno.land/std/log/mod.ts";
Copy the code

It is no longer necessary to have your own centralized repository, but you must be careful to do this because importing modules from third-party sources you cannot control can cause you to open and expose them to the outside world.

In fact, we also lacked our good friend package.json, and now simplify dependency management by including a list of modules and their respective urls in a file called deps.ts. But what about version control? I hear you ask. Well, you can specify the version of the package at the URL, and while it’s not pretty, it works.

A normal deps.ts file might look like this:

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

This will re-export the module, and if you want to change its version, simplify the URL modification accordingly.

Incidentally, the imported code is cached the first time the script is executed until it is run again using the –reload flag.

What else?

Deno also includes other features, such as large tools out of the box, including test runners, debuggers, file monitors, and more. But again, some of these are just apis provided by the language, and you need to write your own tools to use them.

If you’re looking for a solution similar to Nodemon’s, you’ll have to build it yourself, for example, with the file monitor API that Deno.Watchfs provides you. Here’s a 23-line script to solve a similar problem, as follows:

User Caesar2011 released the code as one of its rollbacks, and you can find [the full code] here (github.com/Caesar2011/…

So, will it replace Node.js soon?

To be honest, the title does catch your eye. Some of us started using deno as early as the day of version 0.10 or so, and we used it in production! It’s a little scary to tell you the truth, but we’re doing it because there’s nothing like it around. PHP, Python or even Ruby (not to mention Java or Ruby. NET) is nothing compared to having JavaScript and an asynchronous I/O model on the back end. Over the years, Node (and JavaScript) have evolved to meet industry requirements. Perfect? Oh dear! But, like everything else in life, programming languages aren’t perfect.

Deno is no different, just because right now, this is just an idea and the culmination of about 2 years of work. It has not been tried and tested in a production system. It has not been reviewed or put into weird and unexpected use cases to see how it handles these boundary cases. Until it does, it’s a toy for early adopters. Maybe a year from now, we’ll start listening to companies, sharing their experiences, how they solved the newly discovered shortcomings, and eventually, the community behind it will adapt it to the point where it’s useful. Will it replace Node? Who knows! We will have to wait and see.

So what do you think?

What is Deno and it will replace NodeJS?