Earlier at JS Conf Berlin, Ryan Dahl, the father of Nodejs, gave his 10 Things I Regret About Node.js talk and announced his new project Deno. This is Ry’s second public talk, the first being the release of Node.js, and this article will take you through some of the highlights of Ry’s talk.

Part ONE: Nodejs success

Ry believes that Node has done a good job with the I/0, event-driven HTTP server, and mentions Node’s support for some protocols, cross-platform, and NPM ecosystem. And thanked some of the people who have contributed to Node. Ry has always believed that JavaScript is the best dynamic language, and that dynamic languages are perfect for scientific computing. (This may have something to do with how Ry left Node to work on deep learning at Google’s Brain team.)

The second part of the speech: jokes on Nodejs

This section is the climax of the talk, and makes fun of Node 7. A design that RY regrets.

1. Not sticking to promises

Promise is a necessary abstraction of async/await, and the non-persistence of Promise causes many asynchronous apis in later nodes to age badly.

2. Not enough security

V8 itself is a great sandbox environment, but Node’s early design failed to take advantage of this inherent advantage, resulting in easy access to the system and network.

3. Sticking with GYP by mistake

Since Chrome abandoned GYP, leaving Node as the only user of GYP, and Ry felt that there was too much complexity and unnecessary abstraction involved, it would be more reliable to provide a core external function interface rather than having users write C++ extensions to bind V8 themselves. Ry believes that design errors in the build system are Node’s biggest regret.

4. package.json

Package. json becomes the de facto module standard because of the support provided by require. Unfortunately, it acquiesces in package.json and requires (‘ module’) is ambiguous. This leads to confusion when there are local or private dependency libraries. Package. json contains too many redundant descriptions, licenses, repositories, descriptions, etc., and the “module” presented by package.json as a file directory is not necessarily an abstraction.

5. node_module

Added parsing complexity to the module and deviated from browser semantics, but it is now impossible to eliminate.

6. require(‘module’) without extension “.js”

To do this, the module loader has to guess whether it is’.js’ or ‘.json ‘, and it is not semantic for the browser.

7. index.js

It’s actually not necessary to load index.js by default, because you might have index.html… .

The regrets mentioned above are mostly focused on code management rather than the early Ry focus on building high-performance servers. In fact, by the time Ry raised these regrets, it was equivalent to the new generation of JS/TS V8 Runtime prototype -> Deno, whose main goal was to solve the above problems.

Part three: Introduction and expectations of Deno

1. The security

Deno will take advantage of the fact that JS is a security sandbox, allowing untrusted programs to run safely

  • By default, programs are not allowed to access the network or file system directly
  • The -allow-net -allow-write access does not allow extension functions to be tied directly to V8, simplifying the process and making it easier to audit
  • All system calls are done via message passing (Protobuf serialization)
  • Two native functions: send and recv

2. Simplify the module system

  • No attempt will be made to work with existing Node module systems
  • Import only relative/absolute urls, and the import path must provide an extension
  • Remote urls are cached forever after the first load, and resources can only be fetched again if –reload is provided, which can be bypassed by specifying a non-default cache directory

3. Build the TypeScript compiler into the executable

  • Deno has a built-in TS compiler for module parsing and incremental caching of build results
  • Unmodified TS files will not be recompiled
  • Regular JS works just as well
  • Quick startup with V8 Snapshot, not yet designed in prototype (see V8 Snapshot 8 times Faster startup)

4. Single executable file

5. Take advantage of 2018 technology

Use Parcel to compile and package the Node module for bootstrap at runtime.

Provide a powerful infrastructure in native code

  • There are other mechanisms for implementing HTTP that previously were not possible with Node
  • Currently, the non-js part of Deno is written in go, but it hasn’t been fully prototyped yet, and Rust and C++ are good in some ways

6. Other

  • Terminate the program if a failure to capture a Promise error occurs
  • Support top-level await
  • Compatible browsers (when functions overlap)

That’s pretty much what Ry’s talk was about. Although Deno is still not available and has no binary release, the project has racked up over 10,000 stars in just a few days.

Aside:

At present, the engineering of large front-end development, SSR and other capabilities are basically provided by Node, plus some backend services built by using the advantages of Node, have a certain development time, so for JS developers Node in the future for a long period of time is still worth learning a project.

Of course, if Deno has some design you are recognized, then the best way now is to start investing in learning, from learning Go language, learn to Go to see Deno source code, while looking can also mention PR, after reading Deno source API is almost out, You can write demos in TypeScript, and even though Deno is not used in museums, you learn about Go and TypeScript, and contribute to large open source projects….

References:

  • Deno
  • Deno Roadmap
  • Speech video
  • Speech PPT
  • Deno is not the next Generation of Node – JastJavac