On May 13, version 1.0 of deno was released, a new Runtime Environment for javascript and typescript created in rust and using v8 as the javascript engine.

but why a new runtime environment for javascript? Well, we already have a runtime environment for javascript outside the browser, which is the js node created by Ryan Dahl in 2009, but this was created without taking into account the evolution that javascript would have as a language in the following years.

Node js

The node js is created in C ++ and uses libuv as a library to handle the asynchronous code, but initially I didn't have a package manager or ways to import modules "require, import", Another problem that not only node js has but also other interpreted languages ​​have, managing and accessing system resources making them less secure than others, We did not have "async await",
"promises" or other resources that are common in today's language. Of course today we have NPM and "require" but these were introduced in an architecture that did not have it planned.

The problem called npm

Everyone who has programmed JavaScript with node js surely knows the node_modules directory where dependencies and development libraries are stored, but the problem is that npm is an external company to node js and
everything is centralized when the Internet and software is intended to be decentralized, It may also happen that you download a library to handle system files and use smaller libraries, it may happen that a code script inside one of these libraries has some malicious purpose.

Another problem of npm is the so-called Dependency Hell which is the complex dependence of libraries on each other, in this post it is better explained. but the Dependency Hell is not a problem of node js but of npm, of course but npm is an indispensable tool to develop with node js it affects you in that we have a directory that depending on the complexity and the number of modules and libraries can reach a lot of space in the disk.

the image above is a representation of gatsby dependencies where each node represents a library and its joins. tool link.

deno

Now deno comes to solve many node js problems, but who is leading this project is not just anybody, it is the same node js creator Ryan Dahl since he is aware of node problems, but node is an already stable project, so decided to start from scratch.

the interesting thing about deno is that it only has approximately 2 years of development, that it is written in rust the Mozilla language and that it does not use libuv but tokyo to handle the asynchronous code. Other interesting things is that it can also execute typescript since it comes with the compiler, it has a strong emphasis on security for resource management since we must explicitly give access to resources such as reading and writing files or to the network using the flags " --allow-net, --allow-read y --allow-write " all this with a modern approach since it does not natively support promises but uses async await for asynchronous events. It does not have node_modules, npm or require since the dependencies are managed by means of a link or links very similar to GO and in place of require this import from ES6, the libraries are supervised by the deno development team so it increases security. another deno feature is the toplevel await, which means this, that the main function that runs all the code in the callstack has already declared async.

deno is an interesting proposal to node js but only time will tell if it is up to it, for now I will be posting more interesting things about deno