Deno - Runtime en­vir­on­ment for JavaS­cript

Deno is a radically simple runtime en­vir­on­ment for JavaS­cript and TypeScript. It offers its users a new, simple way to write JavaS­cript and TypeScript 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 JavaS­cript developer community must be part of this process.

Some products are loved by the community, even though they are not perfect. The scripting language JavaS­cript 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­cessor 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­per­i­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­is­on with the afore­men­tioned Node.js is difficult. The developer of both platforms pre­vi­ously created a rough com­par­is­on 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 JavaS­cripts outside of browsers, and the pos­sib­il­ity of writing server-side JavaS­cript or TypeScript. To do so, they use various, existing projects, meaning they are not complete self-im­ple­ment­a­tions. For example, the Google V8 engine, which is already in­teg­rated into the Chrome and Edge browsers, is used as the standard for executing JavaS­cript in various en­vir­on­ments. On the server side, Deno therefore uses V8 like Node.js.

There are sim­il­ar­it­ies, but, in contrast to Node, which is written in C ++, Deno uses the in­nov­at­ive and much more secure pro­gram­ming language Rust from Mozilla Research. Deno thus enables the direct writing of stat­ic­ally typed code, which is prac­tic­ally a selling point on its own.

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

More freedom for de­velopers 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­velopers have limited ability to add more features.

As a com­par­is­on, Deno is much closer to the user ex­per­i­ence on the Web. Access to the system is blocked by default, and the user must first allow an ap­plic­a­tion to access the system, otherwise the two are com­pletely isolated from one another. This is com­par­able to the behaviour 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 JavaS­cript de­vel­op­ment: native TypeScript support.

In order to convert and execute the TypeScript code generated with Deno in JavaS­cript, 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­pil­a­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­bin­a­tion is con­sidered an un­of­fi­cial standard. Deno, on the other hand, does not need an external package manager, and can basically be con­sidered 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­stall­a­tion, which does not run con­veni­ently via an installer package, but only via GitHub, shell scripts, or the package manager of the operating system. To check whether the in­stall­a­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 TypeScript. 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­vir­on­ment can either be used in­ter­act­ively as a shell or with a file as input. The former is useful for smaller ap­plic­a­tions and for ex­per­i­ment­ing with the Node.js al­tern­at­ive. 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 JavaS­cript 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­plic­a­tion. It acts as an interface to the system so that de­velopers can access the file system and break out of the sandbox, for example. As mentioned pre­vi­ously, these ex­cep­tions must be actively confirmed so that un­detec­ted attacks from an ap­plic­a­tion on the system can be excluded.

Deno offers all standard modules. The community has provided ad­di­tion­al, ex­per­i­ment­al 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­prom­ises are to be ironed out in order to create a modern, stable, and secure platform for server-side JavaS­cript and TypeScript. The potential is there in any case, es­pe­cially thanks to the step of relying on Mozilla’s Rust pro­gram­ming language and creating a central au­thor­isa­tion system. This can not only be used in­tu­it­ively, but also prevents an ap­plic­a­tion from un­in­ten­tion­ally breaking out of the sandbox.

The greatly sim­pli­fied workflow still has its dis­ad­vant­ages: Deno is not always com­pat­ible with existing eco­sys­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­ib­il­ity problems in the long term. For example, Deno already has a Node-com­pat­ible require function.