Ryan Dahl, the creator of NodeJS, spent the last year and a half working on his new project, Deno. What is Deno? A new JavaScript runtime tool that is supposed to fix the problems inherent in perfecting NodeJS.

Don’t get me wrong, Node is a great server-side JavaScript runtime tool in my opinion, but also because of the size of its ecosystem and the language it uses. However, Dahl also acknowledged that there are some things that node has very little support for — security, modularity, dependencies, etc.

In his defense, he didn’t expect the platform to grow so fast in such a short time. Also, back in 2009, JavaScript was still a weird little language that everyone looked down on, and many of its features weren’t there yet.

What is Deno? What are its main features

Deno is a secure Typescript runtime tool based on V8 (Google’s JavaScript runtime engine). It is composed of the following:

  • The core of Rust — Deno is written in Rust, just as nodejs is written in c++.
  • Tokio — An asynchronous runtime of the Rust programming language that provides an asynchronous event-driven platform for building fast, reliable and lightweight web applications. Use Rust’s ownership and concurrency model to ensure thread-safety (event loops written in Rust)
  • Typescript – Deno supports JavaScript and Typescript(out of the box)
  • V8 – Google’s JavaScript runtime engine, used in Chrome and Node

Let’s take a look at what Deno offers.

Security (Permission control)

The most important feature of Deno is its focus on security. In contrast to Nodejs, Deno executes code in a sandbox by default, which means the runtime can’t do something:

  • File system access
  • Network access
  • Execute other files
  • Accessing environment variables

Let’s see how the access control system works.

(async() = > {const encoder = new TextEncoder();
  const data = encoder.encode("Hello world\n");

  await Deno.writeFile("hello.txt", data);
  await Deno.writeFile("hello2.txt", data); }) ();Copy the code

This script creates two text files called Hello.txt and hello2.txt, which are filled with Hello Word text. When this code starts executing in the sandbox, it has no access to the file system.

That’s something to watch out for too. We use the Deno namespace, not the FS module, and just like in NodeJS, the Deno namespace provides many basic helper functions. By using namespaces, you also lose browser compatibility, which we’ll discuss later.

When we execute the following command:

deno run write-hello.ts
Copy the code

We will see the following prompt:

⚠️Deno requests write access to "/Users/user/folder/hello.txt". Grant? [a/y/n/d (a = allow always, y = allow once, n = deny once, d = deny always)]
Copy the code

We are prompted for permission control every time we call the sandbox, but only once if we select the Allow always option.

If we select deny, the PermissionDenied error will be thrown and the process will abort and exit because we don’t have any fault tolerance.

If we execute the script with the following command:

deno run --allow-write write-hello.ts
Copy the code

There will be no prompt, and two text files will be created.

The –allow-write flag is available for file systems. There are also –allow-net, –allow-env, and –allow-run, which allow network requests, access to environment variables, and run child processes.

modularity

Deno, like browsers, loads modules through urls, and many people are confused when they first see modules loaded on the server by introducing urls, but the pattern also makes sense.

import { assertEquals } from "https://deno.land/std/testing/asserts.ts";
Copy the code

What’s the advantage of importing reports through urls, you might say. The answer is simple: through urls,Deno packages can be clustered in a central repository, such as NPM, rather than centrally. Something happened not long ago that I won’t elaborate on here.

By importing code through urls, we can let package creators host the code where they want to host it — decentralized. No extra package.json and node_modules.

When we start running a Deno application, it downloads all dependencies and caches them. Once they are cached locally, Deno won’t download them again unless you add the — Reload symbol to the application.

Here are some important questions:

What if there is a package on the site jump?

Since it is no longer managed as a central repository, the site for storing packages may crash for some reason. This is a bad situation for a project in development, and a devastating one for a project already online.

As we mentioned earlier, Deno caches module packages, and since the cache is stored on our local hard disk, Deno’s creators suggested checking it out on our version control system (i.e. Git) and keeping it in the repository. This way, even if the site crashes, the developer still keeps the downloaded version.

Deno stores the cache in the directory specified under the $DENO_DIR environment variable. If we don’t set the variable ourselves, it will be set to the system’s default cache directory. We can set $DENO_DIR somewhere in our local repository and check it into version control.

Do I have to import it through the URL every time?

Always importing files via urls can be extremely complicated or cumbersome, but Deno currently has two options for us. The first option is to re-export the imported module from a local file, like this:

export { test, assertEquals } from "https://deno.land/std/testing/mod.ts";
Copy the code

We named the above file local-test-utils.ts. Now, if we want to use the test or assertEquals function method again, we can simply introduce it like this:

import { test, assertEquals } from "./local-test-utils.ts";
Copy the code

So it’s not a big deal, whether or not you’re using urls. The second option is to create an import map file, more specifically a JSON file:

{
  "imports": {
    "http/": "https://deno.land/std/http/"}}Copy the code

When introducing, introduce like this:

import { serve } from "http/server.ts";
Copy the code

In order for it to work, we have to tell Deno what the importmap file is with the –importmap flag:

deno run --importmap=import_map.json hello_server.ts
Copy the code

What about the version of the package?

Version must be folded provider support, but from the point of the client, it’s just set the version number in the URL, as shown in the following: https://unpkg.com/[email protected]/dist/liltest.js.

Browser compatibility

Deno is designed to be compatible with browsers. Technically, we don’t have to use any build tools (such as WebPack to make our application available in the browser) when using the ES module.

However, tools like Babel convert the code to the ES5 version of JavaScript, so it can run even in older browsers that don’t support all of the language’s latest features. But it also comes at the cost of including a lot of unnecessary code in the final file and bloating the output file.

It’s up to us to decide what our main goals are and make choices accordingly.

TypeScript supports out-of-the-box support

Deno makes iT easy to use TypeScript without any configuration files. It is still possible to write programs in pure JavaScript and execute them using Deno without any trouble.

Abstract

Deno, a new runtime for TypeScript and JavaScript, is an interesting project that has been growing steadily for a long time. But there is still a long way to go before it is considered ready for production.

Because of its decentralized nature, it needs to liberate the JavaScript ecosystem from a centralized package registry, or NPM.

Dahl said he hopes to release version 1.0 by the end of the summer, so if you’re interested in Deno’s future, star it.