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

Deno compatible browser refers to what, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain for you in detail, people with this need can come to learn, I hope you can gain something.

There is a description in Deno: "Aims to be browser compatible". You can see that Deno is aimed at compatible browsers. So what do you mean by what the compatible browsers here are?

Let me briefly talk about my understanding.

First of all, the compatibility here is certainly not that Deno runs directly on the browser side. Because Deno is a browser-level Runtime.

Many people also misunderstand that compatible browsers mean that Deno will provide "similar UMD writing in Node.js". First of all, let's make it clear that compatibility here does not refer to compatibility at the grammatical level alone, nor does it mean compatibility with ES3 ES5. So don't get the misconception that Node.js and Deno are compatible with babel.

In Deno's Roadmap, the author has already written:

Deno does not aim to be API compatible with Node in any respect. Deno will export a single flat namespace "deno" under which all core functions are defined. We leave it up to users to wrap Deno's namespace to provide some compatibility with Node.

The compatibility here, my understanding is compatible with the browser's API and ecology. (sit and wait to be hit in the face)

An issue "discussion: struct the browser-compatible APIs # 82" discussed this issue earlier, listing some browsers API that you want to be compatible with in issue:

High level

Console ✓

URL ✓

File/FileList/FileReader/Blob

XMLHttpRequest/Fetch

WebSocket

URLSearchParams

Middle level

AudioContext/AudioBuffer

Canvas

Support for setting up GPU for WebGL is also included in the discussion. We can vaguely guess that one of the goals of Deno is to make the code in the browser run directly on Deno.

My view is still that Deno is not the next Node.js. (sit and wait to be hit in the face again)

Deno is a "A secure TypeScript runtime on V8". How to understand a secure V8-based TypeScript runtime.

Browsers can be thought of as secure JavaScript runtimes where all JavaScript code runs in sandboxie (Sandbox). Although the browser is installed on your computer, the JavaScript code running in the browser can come from all over the world, in other words, the browser is running untrusted code, how to ensure that the browser's JavaScript code does not damage your computer system, this is a problem that the browser security mechanism needs to solve. Node.js is not. Like any Web server, Node.js runs trusted code.

Previously, there was a security breach in V8 about escape analysis (Escape Analysis), and Chrome took emergency measures to remove the functions related to escape analysis in the next version. In contrast, Node.js was not affected because the code that Node.js was running was already trusted.

From this point of view, Deno and browser positioning are very similar.

A mistake made by the V8 team slows down the entire Internet

Because we can see a difference between compatible server-side ecology and compatible browser-side ecology:

What runs in the browser is untrusted code.

The server is running trusted code

Let's talk about server ecology from a different perspective.

Many people also have a misunderstanding that the API mentioned above is also fully compatible with Node.js, such as Console, URL, XMLHttpRequest/Fetch, etc., many API have been implemented by Node.js.

When Node.js was developed, there were no API browsers such as File, URL and Buffer, but because Node.js is positioned as a server-side running platform, Node.js refers to other Web servers or server programming languages. For example, the file system (File System) implements a series of POSIX (Portable Operating System Interface, portable operating system interface) compatible functions and functions.

It is also important to note the convergence of Node.js and browsers, such as URL API added by Node.js 7, which is also available in today's mainstream browsers because Node.js also uses the WHATWG URL standard.

The full name of WHATWG is Web Hypertext Application Technology Working Group, the web hypertext application technology working group. This is a fairly "heavyweight" organization, and when the W3C decided to abandon HTML's future focus on XHTML 2.0, WHATWG strongly supported HTML and developed the next generation HTML plan. In the end, WHATWG persuaded the W3C and released HTML5 with it.

Today, with the rapid development of Web, we would like to thank these organizations for their efforts.

So now there is a question: if Node.js, browsers, and Deno all use these standards, will they become the same? will Deno replace Node.js as the next generation of Node.js? Or does Deno become the same platform as Node.js but more difficult to use than Node.js, and eventually be marginalized or abandoned?

No, I won't. Because you can't have both performance and security, for example, API such as File/FileReader/Blob is naturally designed for the browser-side sandboxie environment (many WHATWG standards are designed for browsers). Node.js does not provide the corresponding API, and does not intend to provide it. After all, what we need more in the server-side environment is the file system, so Node.js chose POSIX instead of embracing WHATWG.

Now that I'm talking about this, I'll go a little deeper and go to the bottom to see why Node.js doesn't use Blob and FileReader to read files.

On the browser side, the file usually comes from the network, provided by url, or actively selected by the user from the form. Either way, the browser reads the file and loads the contents of the file into the memory buffer, and JavaScript can manipulate the file through Blob. But instead of implementing these API, Node.js builds Stream modules on top of the file system. Let's take a look at the server-side programming languages such as Java and PHP, which also provide Stream.

If we use Node.js as a Web server, let's compare it horizontally with Nginx. If you use js to develop a static file server, Nginx can easily run over Node.js with tenfold performance.

We can analyze why there is a great difference between the two from the bottom. Here are a few knowledge points:

User space

Kernel space

Process context

Interrupt context

DMA

Zero Copy

In order to consider that the operating system does not allow the user code to operate the hardware directly, in order to ensure the security of the operating system kernel, the space is divided into two parts, one is the kernel space, the other is the user space. The code written by the user runs in user space, and when you need to use the underlying functions, you can enter the kernel through system calls, such as file reading.

When the user process enters the kernel space from the user space through the system call, the system needs to save the context of the user process, and when it returns to the user space from the kernel space again, the system restores this context.

For static servers, this step is roughly as follows:

Call read, and the file is copy to the kernel buffer

The read function returns the file from the kernel buffer copy to the user buffer

Write function call to move the file from the user buffer copy to the kernel socket-related buffer

Data from socket buffer copy to related protocol engine

You can see that the file has been copy 4 times throughout the process.

On the other hand, the underlying layer of Nginx uses sendfile to implement Zero Copy (zero copy).

The whole process becomes:

Sendfile system call, the file is copy to the kernel buffer

From the kernel buffer copy to the socket related buffer in the kernel

From socket-related buffer copy to protocol engine

You can see that there are only three copy times in this process. And there is no switching between user space and kernel space, and there is no need to save and restore the context of the process. In fact, there is room for optimization, because a buffer-to-buffer copy occurs in the kernel. After Linux kernel version 2.4, the DMA module passes data directly from the kernel buffer to the protocol engine.

Although it is called Zero Copy, the data is still copied from disk to memory, which is necessary from the point of view of the operating system. The so-called zero copy means that there is no redundant data in the kernel and the data does not need to be copied in the kernel. With the help of the DMA module, this process does not require CPU participation at all.

In Nginx, only 2 copy of the data copy are required, while Node.js requires 4 times. If Node.js wants to use Zero Copy, there are ways, such as using the functionality of the os module, or directly using the C++ extension.

On the other hand, the performance loss of Node.js involves not only four times of copy and the preservation and recovery of the process context, but also the repeated crossing of boundaries of data and code from C++ to JavaScript.

Let's go back to the browser, for which there is no need for this feature at all. Because the JavaScript code in the browser runs not only in the user space, but also in the sandboxie space.

So instead of guessing what compatible browsers mean here, compare the differences between browsers and servers:

The browser runs untrusted code, and the server runs trusted code

Browsers follow W3/WHATWG and servers follow POSIX

The browser is concerned about the performance of the API layer, and the server is more concerned about the performance of the operating system layer.

Browser capability is limited, server capability is not limited.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

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.