Author: LeanCloud Wangziting
Deno was born with a halo — it was posted in Node.js founder Ryan Dahl’s “Design Mistakes in Node (Slide)” talk, and some people said Node.js was going cold, but I didn’t think so.
The original TypeScript
Currently, we haven’t introduced any problems with using TypeScript in the “user mode” of the engine, and it gives users a lot of flexibility. Consider that TypeScript cannot leave the JavaScript ecosystem — after all, the engine will always support JavaScript; Add to that the fact that TypeScript comes in different versions and has different build switches, and using TypeScript in user mode is probably the best solution. Sooner or later, TypeScirpt will become Deno’s historical liability.
From a performance point of view, V8 did a lot of magic on JavaScript before TypeScript came along, so it’s fair to say that JIT-generated code is no worse than any other statically typed language, and you can’t simply use TypeScript to improve performance. Add to that the fact that the engine will always support JavaScript, and TypeScript’s runtime semantics are still JavaScript (TypeScript doesn’t guarantee that the actual type of an object is not modified at run time), So it’s impossible for the engine to switch from JavaScript magic optimizations to TypeScript based optimizations.
A package manager
I’ve always found NPM to be one of the best package managers available. This includes keeping dependencies in the project directory — you can adjust dependencies for one project without worrying about the impact on other projects; Each package can specify its own version of dependencies, allowing multiple versions to exist — upgrading one package’s dependencies does not affect other packages, and each package can use a new version or continue to use an old version; NPM is responsible for finding and installing packages, while Node.js uses these packages using a relatively simple protocol, and they can evolve independently of each other.
As you can see, NPM ends up being a huge mental drain for developers, and as long as you use it in the right way, you rarely encounter the dependency management issues found in other languages. Deno goes the other way. Although Deno does provide some functionality (Deno Cache), you’ll notice that the intent of Deno is that it doesn’t want to do dependency management.
Including urls in your code is a very bad practice (as is Golang). Deno calls it decentralization, but it’s really just recoupling the code that uses the package with the source of the package (Deno now provides an official proxy, but that’s no different than a central repository for NPM). The caching mechanism also introduces considerable uncertainty: package-lock.json guarantees that dependencies are exactly the same on each installation, whereas Deno’s lock.json only checks for dependencies that have changed (and refuses to run them if they have). This makes it difficult for developers to control the timing of dependency updates, and Deno recommends putting the dependency cache in Git.
Built-in permission system
General purpose programming languages have never introduced permission control at the language level, but it is true that the open source community has reported several instances of malicious code, but Deno’s permission mechanism is rather rough — only at the process level, and I would venture to predict that in almost all scenarios we will need –allow-all, It doesn’t do much for security.
We need to consider whether Deno users are developers or users: users of Deno scripts are concerned with process-level permissions; For developers, I think it’s more important to focus on third-party package permissions. The permissions system should be based on packages (Deno doesn’t have packages anymore). Node also has VM modules that can sandbox to some extent (but it’s very difficult to control).
And having said that now that we have complete isolation and permission control mechanisms like Docker (or the broader concept of containers), there is not much need for programming languages to introduce a set of permission control.
Isolated ecology
You can say that the JavaScript ecology comes from the full competition of user-state class libraries, Deno provides Standard Library (like Golang.org/x) anda full development toolchain (FMT, Test, doc, Lint, bundle) in addition to the Runtime API, while trying to provide an out-of-the-box experience. It also weakens the third-party ecology.
With Node.js and NPM already part of the de facto standard for JavaScript, Deno could have gotten a great start by being compatible with Node.js or NPM. Deno, however, has chosen to steer clear of Node.js and instead is compatible with some of the browser environment’s apis (such as Prompt or OnLoad).
Deno’s own claim is to avoid inventing new things in order to comply with existing Web standards, but in fact those Web standards were not designed with enough Runtime outside the browser in mind, and Deno has not avoided inventing new things (these new things are placed in the Deno namespace).
summary
Deno is a very personal JavaScript Runtime that tries to correct some of node.js’s “design mistakes,” tries to introduce “JavaScript best practices,” and tries to provide a high quality standard library and toolchain out of the box. These preferences will always be liked or disliked, but otherwise Deno really lacks a killer feature that would allow a “rational” Node.js developer (such as a company) to switch to Deno.
Single-file distribution and process-level permission control make Deno more suitable for command-line tools, but it’s doubtful whether it will compete with Golang, which is already widely used for command-line tools.
As a Node.js developer, I don’t see Deno replacing Node as my primary development tool in the future, but rather as an invasion of JavaScript by Golang’s design philosophy.
We don’t need Deno