Deno: A runtime environment for JavaScript and TypeScript

Deno is a radically simple runtime environment for JavaScript and TypeScript. It offers its users a new, simple way to write JavaScript and TypeScript on the server side. The platform is still at the beginning of its development, 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 shortcomings, it is one of the most widely used languages worldwide with countless frameworks and libraries available. Node.js, the predecessor of Deno, is also very popular in the community. With the Deno project, developer Ryan Dahl wanted to take advantage of the Node.js experiences while providing a safer and improved platform. Read on to find out more about how Deno works and whether it’s an improvement over Node.js or not.

Deno is still in its early stages. Interfaces, architecture, and design decisions have not yet been set in stone, and will certainly change during the course of development. As such, a direct comparison with the aforementioned Node.js is difficult. The developer of both platforms previously created a rough comparison 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 possibility of writing server-side JavaScript or TypeScript. To do so, they use various, existing projects, meaning they are not complete self-implementations. For example, the Google V8 engine, which is already integrated into the Chrome and Edge browsers, is used as the standard for executing JavaScript in various environments. On the server side, Deno therefore uses V8 like Node.js.

There are similarities, but, in contrast to Node, which is written in C ++, Deno uses the innovative and much more secure programming language Rust from Mozilla Research. Deno thus enables the direct writing of statically typed code, which is practically a selling point on its own.

Deno has two functions that lead to a much simplified workflow: For one, the runtime environment relies on a simple module system in which URLs and modules directly correspond with one another. In addition, Deno enables TypeScript codes to be executed freely.

More freedom for developers 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. Developers have limited ability to add more features.

As a comparison, Deno is much closer to the user experience on the Web. Access to the system is blocked by default, and the user must first allow an application to access the system, otherwise the two are completely isolated from one another. This is comparable to the behavior of a browser when, for example, a web video conference requests access to a computer’s webcam and microphone. 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 development: native TypeScript support.

In order to convert and execute the TypeScript code generated with Deno in JavaScript, no additional 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 compilation process in Node.js, for example.

When it comes to package management, 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 combination is considered an unofficial standard. Deno, on the other hand, does not need an external package manager, and can basically be considered 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 architecture. This begins with installation, which does not run conveniently via an installer package, but only via GitHub, shell scripts, or the package manager of the operating system. To check whether the installation was successful, 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 executions. The runtime environment can either be used interactively as a shell or with a file as input. The former is useful for smaller applications and for experimenting with the Node.js alternative. The latter is the most common use of Deno. The name of a file is transferred 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 application. It acts as an interface to the system so that developers can access the file system and break out of the sandbox, for example. As mentioned previously, these exceptions must be actively confirmed so that undetected attacks from an application on the system can be excluded.

Deno offers all standard modules. The community has provided additional, experimental 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 compromises are to be ironed out in order to create a modern, stable, and secure platform for server-side JavaScript and TypeScript. The potential is there in any case, especially thanks to the step of relying on Mozilla’s Rust programming language and creating a central authorization system. This can not only be used intuitively, but also prevents an application from unintentionally breaking out of the sandbox.

The greatly simplified workflow still has its disadvantages: Deno is not always compatible with existing ecosystems. 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 compatibility problems in the long term. For example, Deno already has a Node-compatible require function.