Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

Why develop Deno?

2025-03-13 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Development >

Share

Shulou(Shulou.com)06/02 Report--

This article mainly explains "Why to develop Deno". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn "Why to develop Deno"!

0. Why develop Deno?

This is a picture I made last week, which introduces the brief history of the development of JavaScript. I just modified it to add annotations for the release time of Node.js and Deno.

Node.js and Deno are non-browser JavaScript runtimes developed by Ryan Dahl in 2009 and 2018 based on the front-end technology of the current year.

Ryan Dahl did not develop deno because of "just for fun" or to replace node. Let's explain it slowly.

1. Currently, deno is just a demo.

I spent the past two days looking at the source code of deno (fortunately, the source code is very small and easy to understand), and looked at all the issue and pr by the way. I don't know how "according to the official introduction, it can be thought of as the next generation of Node".

Since it is a new work by the father of Node.js, Node.js is inseparable from the discussion. And the author replied mischievously:

The main difference is that Node works and Deno does not work:)

* the difference is that Node works, but Deno does not:)

Currently, Deno is just a Demo and doesn't even have a binary distribution. Fortunately, compiling from source code is easier (if you are not using a Windows system).

At the high-level level, Deno provides a V8-to-system API binding as simple as possible. Why use Golang instead of C++, because Golang makes it easier to add new features, such as http2, than Node.

As for why not choose Rust, the author did not answer.

Let's compare the startup performance of the two again. Run separately:

Console.log ('Hello world')

There is still a big difference. After all, deno needs to load a TypeScript compiler. After all, it is a demo version, and I hope to optimize it in the future.

Another idea for performance improvement is that you can use LLVM as a back-end compiler to compile TypeScript code into WebAssembly and run it in V8, or even directly compile the source code into binary code. Ryan Dahl indicates that deno only needs one compiler, and that is TS. But since deno is compatible with browsers, WebAssembly should also be supported.

Deno can cache the compilation results of ts (~ / .deno / cache), so the current focus is on startup speed and initial compilation speed.

Or compile before release, so that deno is out of the original intention of development. Deno is a ts runtime, so you should be able to run ts code directly, and if you compile ts to js ahead of time, deno will fall back to the js runtime.

two。 Should beginners learn Node.js or Deno?

Ryan Dahl's answer to this question is neat:

Use Node. Deno is a prototype / experiment.

Use Node. Deno is just a prototype or experimental product.

As you can see from the introduction, Deno's goal is not to be compatible with Node, but to be compatible with browsers.

Therefore, Deno is not to replace Node.js, nor is it the next generation of Node.js, nor is it to give up npm to rebuild Node ecology. For now, deno is embracing the browser ecology.

I have to say, this is a great goal. Ryan Dahl developed Node.js, and the community built the entire npm ecology. I answered justjavac in another: what exactly is nodejs in the eyes of pure front-end developers? It says, "Node.js is one of the important pillars of front-end engineering."

Although Ryan Dahl later left Node.js for the Golang community, now Ryan Dahl is back, bringing Golang to the JavaScript community, developing Deno, and then embracing the browser ecology. ?

Let's take a look at deno's goals for Web API:

High level

Console √

File/FileList/FileReader/Blob

XMLHttpRequest

WebSocket

Middle level

AudioContext/AudioBuffer

Canvas

It will even include support for webGL and GPU.

3. Architecture of Deno

Parsa Ghadimi draws an architectural diagram of Deno:

The underlying layer uses v8worker2 developed by the author, while event-loop is based on the pub/sub model.

What I'm curious about is that deno uses protobuf instead of Mojo. Since the goal is to be compatible with browsers, but not to use Mojo, but to recreate wheels on protobuf, we can see that Ryan Dahl is the real "wheel". But as can be seen from issue, Ryan Dahl had never heard of Mojo before, but after watching mojo, he still felt that protobuf made the right choice.

Mojo is a new generation of IPC mechanism developed by Google to replace the old Chrome IPC. The current version of Chrome is 67, and Google's plan is to replace all old IPC with mojo in version 75 in 2019.

After all, Mojo's thinking is similar to that of protobuf. After all, it belongs to the Google family. The old IPC system was based on a named pipe (IPC::Channel) between two processes (threads). This pipeline is a queue, and IPC messages between processes are delivered in first-in-first-out order, so there are sequential dependencies between different IPC messages. Mojo, by contrast, creates a separate message pipeline for each interface, ensuring that the IPC of different interfaces is independent. And it is not expensive to create a separate message pipeline for the interface, only a small amount of heap memory needs to be allocated.

The architectural design of Mojo:

We can take a look at the architectural changes since Chrome introduced Mojo.

Before:

After that:

Is it a little bit like micro-service?

Anyone familiar with Java's Spring can clearly see this dependency inversion. Blink was originally the typesetting engine of the browser layer, but it became an intermediate module through Mojo,Blink. The recent popularity of Flutter is also based on the Mojo architecture.

4. TypeScript VS JavaScript

The introduction of deno is a secure TypeScript operating environment. But if we look at the source code, we can see that deno is integrated into a TypeScript compiler, and ry/deno:main.go is in the entry file.

/ It's up to library users to call / / deno.Eval ("deno_main.js", "denoMain ()") func Eval (filename string, code string) {err: = worker.Load (filename, code) exitOnError (err)} / / It's up to library users to call / / deno.Eval ("deno_main.js", "denoMain ()") func Eval (filename string, code string) {err: = worker.Load (filename) Code) exitOnError (err)}

Use the deno_main.js file run with V8. It's JavaScript, not TypeScript.

In the previous analysis, we knew that this would affect the initial startup speed of the deno. What about execution speed? In theory, TypeScript as a statically typed language, compiled JavaScript code will have faster execution speed. I previously mentioned in "Front-end programmers should know something about V8" that one of V8's performance improvements for JavaScript is Type feedback.

When V8 executes a function, it immediately compiles (JIT) based on the arguments passed in to the function (note that they are arguments, not formal parameters, because the formal parameters of JavaScript are untyped):

But when the function is called again with a different type later, V8 performs a Deopt operation.

(the result of previous optimization is removed, which is called "de-optimization")

But if we use TypeScript, all parameters are marked by types, so we can prevent detuning operations from being performed within the V8 engine.

5. Prospect and conjecture of deno performance

Although TypeScript can avoid the de-optimization operation of V8 engine, V8 executes the compiled result of ts. We can see from bytecode or machine code that V8 still generates Type Check code. Before each function call, V8 will check the type of argument. In other words, although TypeScript guarantees the parameter type of the function, V8 cannot determine the parameter type of the function after it is compiled into JavaScript, and can only ensure the parameter type by checking before each call.

Secondly, when V8 encounters a function definition, it does not know the type of parameters, but only after the function is called can V8 judge the type of function and compile the function in real time with Typed. Another contradiction here is that typescript already knows the type of parameter when the function is defined, while V8 optimizes based on the type of argument only when the function is called.

Therefore, there are still many problems in the current architecture of deno, after all, it is only a demo. There are many directions that can be optimized in the future.

V8 is a JavaScript runtime, and if deno is defined as a "secure TypeScript runtime," at least on the current architecture, there is a significant performance penalty. But currently there is no TypeScript runtime, so the next best thing is to put a TypeScript compiler in front of V8.

The execution process goes like this:

Although I have not used TypeScript in the project, basically all the third-party libraries I write in the project provide a d.ts file. At present, the use of TypeScript is still reflected in the development and maintenance process.

One way we can think of is to fork a copy of the V8 source code and then integrate the compilation process. TypeScript also needs a copy of AST when compiling to JavaScript, and then generates js code. V8 executes js code by parse another AST and generates intermediate code (ByteCode) based on AST. If TypeScript can generate the corresponding bytecode directly, it will improve the performance of the runtime.

But Ryan Dahl probably wouldn't do that. But not necessarily, after all, the community has compiled a subset of TypeScript into WebAssembly.

Microsoft's JScript and VBScript were defeated in the competition with JavaScript, but now TypeScript is gaining momentum. While compatibility with the ES specification has hampered the development of TypeScript, it is expected that Microsoft can provide a TS runtime or add support for the TS runtime in the Chakra engine.

At this point, I believe you have a deeper understanding of "Why to develop Deno", might as well come to the actual operation of it! Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Development

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report