I’m sure most of us by this time know what Deno is. For those who don’t know it is a runtime for JavaScript and TypeScript. It is similar to Node.js but yet different, it is created by the same programmer but it is not here to replace Node.js by any means disregarding how alike they may appear.

For the last couple of days I’ve been reading Deno’s documentation, reading blog posts and watching tutorials about Deno and in this post I will try to explain what I’ve learned so far about Deno and also my thoughts about some of its principles.

1. It is secure by default

In Deno, you have to grant your program permissions to perform certain tasks. For example if you have a program that will need network access, you have to run your program with the --allow-net flag or the program will fail. You can check out this page to know more about this.

My thoughts: I like this feature. It is always a mysterious thing for me to know if a given program is accessing my disk or the network internally without my knowledge which left me cautious about using any third-party module especially in sensitive contexts. With this feature I can definitely tell what the program I’m running is accessing. This feature reminds me of the permission prompt we receive on mobile phones when an app is trying to access any of the device’s resources. I remember vividly deleting mobile phone applications immediately delete after opening them for the first time because they are trying to access a resource that I don’t find essential for the app to function normally.

2. It doesn’t save external modules inside your project

This is one of the most controversial features of Deno. In simple words you don’t install a third-party module or keep a packages file (like package.json in Node.js) inside your project. In Deno you import modules like the following:

import { App } from "https://deno.land/x/attain/mod.ts

When you run your program for the first time, the module is downloaded and cached on your desk for future usage. And if you are worried about code editors support for that, I’ve tried the Deno VSCode extension and it is working as what you would expect.

My thoughts: I’m not sure if I like this feature or not. On one hand I don’t like how packages are handled currently in JavaScript with NPM. There are certain problems with the package.json and node_modules philosophy that needs its own post but I have always felt that it is an area with a lot of improvement room. On the other hand I’m not sure how secure/reliable it is to fetch code from a link. I think this is one of the huge changes in the whole industry not only in Deno that we need to experiment with and monitor in production applications before we can label it with good or bad.

3. Supports TypeScript out of the box

You can start writing TypeScript code right away, no need to install ts-node or babel. Just use the .ts extension and Deno runtime will compile the file before running it. You can create .js files and Deno will run them right away.

My thoughts: One thing to note here is that the file extension is essential in import statements. Because in Deno you can write .js or .ts modules, in imports statements you have to explicitly mention the file extension

This will work fine:

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

But this will throw an error:

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

This is different from the situation in Node.js so I assume people will find this laborious initially.

4. Has a built-in test runner

There is a built-in testing runner already implemented in Deno’s namespace. It can be accessed from Deno.test. How does it look?

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

Deno.test("hello world", () => {
  const x = 1 + 2;
  assertEquals(x, 3);
});

My thoughts: I definitely like this feature. Not because the test runner is powerful or because it contains features that don’t exist in other test runners. I like it because it paves the way of standardization in the JavaScript realm. It has been always a problem in the JavaScript community that there is no standard for anything. There is tenths of libraries that do the same thing and all of them are popular. Adding a built-in test runner will -hopefully- make it the standard library to write tests in Deno and then all the efforts will -hopefully- go into improving it. I’m sure that it is not powerful as any other test runner that Node.js has but with time I think it will be.

5. It is browser-compatible

Deno is trying to be as browser-compatible as possible, for example fetch and the global window object are built-in. Also, it supports top-level await.

This line will work fine:

await fetch(url)

without a need for calling an await function inside of an async function but that doesn’t work in all other cases. In this example you have to define the parent function as an async before using await:

const addEntry = async ({ request }) => {
  const body = await request.body()
}

This example is using the Oak third part library

6. Misc

• Deno uses ES Modules, you can use import/export VS require in Node.js
• It has standard modules and third-party modules. The standard modules are built by the core team of Deno are they are responsible for maintaining them. Another step towards standardization in the community.
• Deno has the same letters as Node