Tips: The denO project is currently in a rapid development phase and the source code can be updated at any time, so the code in this article is for illustrative purposes only and does not keep pace with the code in the project. Display code only retain the core, anomaly check and other appropriate deletion.

Recently, Ryan Dahl’s deno has attracted a lot of attention and even caused some bad issues. But what does the Deno hide behind this gorgeous robe? This series of articles on the combination of source code to do a little simple analysis and combing of denO, is also a study notes.

What is deno?

This question is very easy to answer and is clearly defined on deno’s GitHub home page: A Secure TypeScript Runtime on V8, A V8-based TypeScript runtime. Simply looking at the definition, some friends may send out “every word can understand but together do not understand” sigh, but we can use analogy to understand this definition.

On the GitHub page for Node.js, there’s a similar definition: Node.js is a JavaScript runtime built on Chrome’s V8 JavaScript engine. Node.js is a V8 based JavaScript runtime. Deno is similar to Node in that it is a “runtime” and is based on the well-known JS engine V8, but one supports TS and the other JS. For the simplest example, we could write code like this:

// hello.ts
const name: string = "yingying";
console.log(name);
Copy the code

We can then run the hello.ts code file using the deno executable

 $ deno ./hello.ts
 yingying
Copy the code

It’s interesting to note that Node and deno simply switch the alphabetical order of their names, which reinforces their brotherly relationship :).

What are the features of deno?

There are a number of reasons why the creators of Node chose to create a runtime that is similar to Node. In jSConf 2018, Ryan Dahl explained why he designed denO. If you are interested, you can read the PPT for Design Mistakes in Node. Here I just briefly describe and explain the main features of denO.

security

The security mentioned here is not only binary code security, but also IO security, which is easy to be ignored.

In Node, we can build sandbox environments using VMS, and then call methods on the VM to perform operations. In deno, the isolation is more complete, we can only send and receive messages to make system calls, the malicious code is completely isolated in the implementation layer (go, c++) rather than the call layer (ts).

In addition, ts code running in deno will not have network request and file read permission by default, users must manually add –allow-net and –allow-write flags to enable the corresponding permission when running the code, so that it is safer to run third-party code.

Simplified module system

Ryan thinks that the module system of Node is too complicated, and the package.json file contains too much redundant information. Therefore, in denO, the module system chooses to follow the example of Go and references files by URL or relative path, and the file format needs to be specified. Instead of using the Resolve algorithm in Node for file path completion. Files loaded through the network will be cached. The next import will load the cached file directly. While module versioning is achieved by adding semantic version numbers to package names, such as https://unpkg.com/[email protected]/testing.ts, decentralized versioning allows for more fine-grained dependency management.

Facing the TypeScript

There’s no one who doesn’t like TypeScript

In 8102, TypeScript was the undisputed dream language for new project development and old project refactoring, and there could be another article on its merits, so I’ll skip it here. Deno mainly modified some of the TS Compiler hook functions to support the new module lookup strategy. Such as fileExists:

LanguageServiceHost {class TypeScriptHost implements ts.LanguageserviceHost {// One of the hook functions of the TS converter fileExists(fileName: string): Boolean {// const m = resolveModule(fileName, "."); const exists = m ! = null; util.log("fileExist", fileName, exists); return exists; }}Copy the code

The shortage of the deno

Deno itself is said to be “TS Runtime”, but since the runtime engine is based on a JS engine (V8), we need to keep a TS compiler in runtime to automatically translate TS into JS, and then hand it to V8 to execute. This definitely increases startup performance and runtime performance, which can be discussed in Compare Bootstrap Speed with Node.js.

At the same time, we write code with a fair amount of type information, but we have to throw that treasure away when we execute the code. Finally, it was a bit annoying to discreetly JIT V8 to collect what we already knew as a “feedback vector”. If you can have a big rich factory, willing to cooperate with deno to release a TS engine, called V8S or something, using rich static information to do AOT, combined with some V8 JIT optimization, then the speed is no problem to a higher level.

To summarize

This article mainly briefly introduces the positioning, characteristics and shortcomings of denO. Since the project is still in the prototype stage, there are few related introductions. It is suggested that you can refer to GitHub of deno for further understanding. Design Mistakes in Node PPT by Ryan at jSconf

The next post is tentatively about the interaction between gO and JS in deno. I hope I’m not too doggy.