We don't need deno

Author: LeanCloud Prince

Deno born she took aura - it released in Node.js founder Ryan Dahl's speech " Design Mistakes in the Node ( slide )," Some people say Node.js was getting cold, but I do not think so.

Native TypeScript

In fact, we currently use TypeScript in the "user mode" of the engine without introducing any problems, and it brings a lot of flexibility to users. Considering that TypeScript cannot leave the JavaScript ecosystem-after all, the engine must always support JavaScript; coupled with the fact that TypeScript has different versions and different compilation switches, using TypeScript in the user mode can be said to be the best solution. TypeScirpt will sooner or later become Deno's historical burden.

From a performance point of view, before TypeScript appeared, V8 had already carried out a lot of magic optimization on JavaScript. It can be said that the code produced by JIT is not much worse than other statically typed languages, and it cannot be improved simply by TypeScript. Performance. In addition, I said that the engine still needs to support JavaScript, and the runtime semantics of TypeScript is still JavaScript (TypeScript does not guarantee that the actual type of the object will not be modified at runtime), so the engine cannot switch from the magical optimization of JavaScript. To optimize the type based on TypeScript.

package manager

I always think that NPM is one of the best package managers, which includes saving dependencies in the project directory-when adjusting the dependencies of one project, you don’t have to worry about affecting other projects; each package can specify its own dependencies Versions, allowing multiple versions to coexist-When upgrading a package’s dependencies, other packages will not be affected. Each package can use the new version or continue to use the old version; NPM is responsible for finding and installing packages, while Node.js does With relatively simple protocols to use these packages, they can be upgraded and evolved independently of each other.

It can be seen that NPM ultimately greatly reduces the mental burden of developers. As long as you use it in the correct way, you will rarely encounter problems related to dependency management in other languages. Deno did the opposite. Although Deno also provides some related functions ( deno cache ), you will find that Deno's original intention is still not to perform "dependency management".

Including URLs in the code is a very bad practice (the same goes for Golang). Deno calls it decentralization, but in fact it just re-couples the code that uses the package with the source of the package (now Deno provides a The official agent is , but what is the difference between this and the central warehouse of NPM). The caching mechanism also brings considerable uncertainty: package-lock.json can ensure that the dependencies of each installation are completely consistent, while Deno's lock.json can only check whether the dependencies have changed (if any, refuse to run) . This makes it difficult for developers to control the timing of dependency updates. Deno suggests to put the dependency cache in Git .

built-in permission system

General programming languages have never introduced permission control at the language level, but it is true that the open source community has reported many incidents of malicious code, but Deno’s permission mechanism is quite rough-permission control can only be performed at the process level, I can Boldly predict that we need --allow-all in almost all scenarios, and it does not contribute much to safety.

We need to consider whether the user of Deno is a developer or a user: For users of Deno scripts, of course, the focus is on process-level permissions; for developers, I think they are more concerned with the permissions of third-party packages. The permission system should Take the package as a unit (but there is no concept of a package in Deno), there is also a vm module in Node that can implement sandboxing to a certain extent (but it is very difficult to control).

And speaking of it, we now have a thorough isolation and permission control mechanism like Docker (or the concept of a more extensive container), and the industry has not much demand for the introduction of a set of permission control for programming languages.

isolated ecology

It can be said that the ecology of JavaScript comes from the full competition of user-mode libraries. Deno provides a Standard Library (similar to golang.org/x ) and a full set of development tool chains (fmt, test, doc, lint, bundle) in addition to the Runtime API. While trying to provide an out-of-the-box user experience, it also weakens the third-party ecosystem.

With Node.js and NPM already becoming part of the de facto JavaScript standard, Deno could have had a very good start by being compatible with Node.js or NPM. However, Deno chose to draw a clear line from Node.js, and was compatible with some browser environment APIs (such as prompt or onload).

Deno’s own statement is to follow the existing Web standards to avoid inventing new things, but in fact, these Web standards did not fully consider the runtime outside the browser when they were designed, and Deno actually failed to avoid inventing new things (these new Things are placed in the Deno namespace).

summary

Deno is such a JavaScript Runtime with very distinct personal preferences. It tries to correct some of Node.js's "design mistakes", hopes to give a "JavaScript best practice", and hopes to provide high-quality and out-of-the-box standards. Libraries and tool chains. There will always be people who like or dislike these preferences, but in addition, Deno really lacks a killer feature to allow a "rational" Node.js developer (such as a company) to switch to Deno.

Through single file distribution and process-level permission control, Deno will be more suitable for the development of command-line tools, but it is doubtful whether it can compete with Golang, which has been widely used in command-line tools.

As a Node.js developer, I don't think Deno can replace Node as my main development tool in the future. Deno is more like an invasion of Golang's design philosophy to JavaScript.

Original address: We do not need Deno