Deno - Runtime en­vi­ron­ment for JavaScript

Deno is a radically simple runtime en­vi­ron­ment for JavaScript and Type­Script. It offers its users a new, simple way to write JavaScript and Type­Script on the server side. The platform is still at the beginning of its de­vel­op­ment, but it is proving at an early stage that it could replace the tried-and-tested Node.js runtime in the long term. However, the JavaScript developer community must be part of this process.

Some products are loved by the community, even though they are not perfect. The scripting language JavaScript is a good example of this. Despite clear short­com­ings, it is one of the most widely used languages worldwide with countless frame­works and libraries available. Node.js, the pre­de­ces­sor of Deno, is also very popular in the community. With the Deno project, developer Ryan Dahl wanted to take advantage of the Node.js ex­pe­ri­ences while providing a safer and improved platform. Read on to find out more about how Deno works and whether it’s an im­prove­ment over Node.js or not.

Deno is still in its early stages. In­ter­faces, ar­chi­tec­ture, and design decisions have not yet been set in stone, and will certainly change during the course of de­vel­op­ment. As such, a direct com­par­i­son with the afore­men­tioned Node.js is difficult. The developer of both platforms pre­vi­ous­ly created a rough com­par­i­son in the following YouTube video:

Deno and Node are not only similar by name, they also share the same basic principle. They offer a platform for executing JavaScripts outside of browsers, and the pos­si­bil­i­ty of writing server-side JavaScript or Type­Script. To do so, they use various, existing projects, meaning they are not complete self-im­ple­men­ta­tions. For example, the Google V8 engine, which is already in­te­grat­ed into the Chrome and Edge browsers, is used as the standard for executing JavaScript in various en­vi­ron­ments. On the server side, Deno therefore uses V8 like Node.js.

There are sim­i­lar­i­ties, but, in contrast to Node, which is written in C ++, Deno uses the in­no­v­a­tive and much more secure pro­gram­ming language Rust from Mozilla Research. Deno thus enables the direct writing of sta­t­i­cal­ly typed code, which is prac­ti­cal­ly a selling point on its own.

Deno has two functions that lead to a much sim­pli­fied workflow: For one, the runtime en­vi­ron­ment relies on a simple module system in which URLs and modules directly cor­re­spond with one another. In addition, Deno enables Type­Script codes to be executed freely.

More freedom for de­vel­op­ers usually means a higher security risk. Deno is fully developed in terms of security. Scripts are usually run in a sandbox that is separate from the operating system. De­vel­op­ers have limited ability to add more features.

As a com­par­i­son, Deno is much closer to the user ex­pe­ri­ence on the Web. Access to the system is blocked by default, and the user must first allow an ap­pli­ca­tion to access the system, otherwise the two are com­plete­ly isolated from one another. This is com­pa­ra­ble to the behavior of a browser when, for example, a web video con­fer­ence requests access to a computer’s webcam and mi­cro­phone. The resources can only be accessed with the consent of the user. Put simply, Deno behaves like a browser for command line scripts.

Deno also takes up the most important trend in JavaScript de­vel­op­ment: native Type­Script support.

In order to convert and execute the Type­Script code generated with Deno in JavaScript, no ad­di­tion­al step using a compiler is required. Whenever data is exchanged, this happens in packets. As a result, Deno does not need an external package like ts-node, which takes care of the com­pi­la­tion process in Node.js, for example.

When it comes to package man­age­ment, Deno offers some surprises: One of Node’s success factors is the package manager npm. Although npm is part of the GitHub community, and is not an integral part of Node, the com­bi­na­tion is con­sid­ered an un­of­fi­cial standard. Deno, on the other hand, does not need an external package manager, and can basically be con­sid­ered its own package manager. The modular system can resolve packages via file system paths or URLs and directly download the required resources.

Deno is only just getting started. The focus is clearly on security and basic ar­chi­tec­ture. This begins with in­stal­la­tion, which does not run con­ve­nient­ly via an installer package, but only via GitHub, shell scripts, or the package manager of the operating system. To check whether the in­stal­la­tion was suc­cess­ful, the very old-school command deno - version must be entered in the command line. This also gives you an overview of the installed Deno version, and the versions of V8 and Type­Script. If you don’t want to install Deno on a system, you can also set it up and run it in a Docker container.

Once Deno is installed, there are two types of ex­e­cu­tions. The runtime en­vi­ron­ment can either be used in­ter­ac­tive­ly as a shell or with a file as input. The former is useful for smaller ap­pli­ca­tions and for ex­per­i­ment­ing with the Node.js al­ter­na­tive. The latter is the most common use of Deno. The name of a file is trans­ferred to the platform and the user can then begin working with Deno.

Well-known JavaScript keywords such as import, export, promise, etc. are directly available in Deno and do not have to be imported first. In addition to the standards, the platform offers a global object which is why it is simply called Deno. The Deno object forms the basis for every ap­pli­ca­tion. It acts as an interface to the system so that de­vel­op­ers can access the file system and break out of the sandbox, for example. As mentioned pre­vi­ous­ly, these ex­cep­tions must be actively confirmed so that un­de­tect­ed attacks from an ap­pli­ca­tion on the system can be excluded.

Deno offers all standard modules. The community has provided ad­di­tion­al, ex­per­i­men­tal and useful add-on modules that expand its range of functions.

Is or will Deno be better than Node? Developer Ryan Dahl doesn’t doubt that it will. Problems of the past, errors, and com­pro­mis­es are to be ironed out in order to create a modern, stable, and secure platform for server-side JavaScript and Type­Script. The potential is there in any case, es­pe­cial­ly thanks to the step of relying on Mozilla’s Rust pro­gram­ming language and creating a central au­tho­riza­tion system. This can not only be used in­tu­itive­ly, but also prevents an ap­pli­ca­tion from un­in­ten­tion­al­ly breaking out of the sandbox.

The greatly sim­pli­fied workflow still has its dis­ad­van­tages: Deno is not always com­pat­i­ble with existing ecosys­tems. A Node module cannot simply run on Deno or vice versa. However, if the platform continues to prove itself, there will certainly no longer be any serious com­pat­i­bil­i­ty problems in the long term. For example, Deno already has a Node-com­pat­i­ble require function.