What you Need to Know about Deno 1.0

1 the introduction

What is Deno? What is the relationship between Deno and Node? What does Deno have to do with me?

Deno will release 1.0 on 2020-05-13. If you are still wondering, please read Deno 1.0: What You Need to know with me to learn the basics of Deno.

I hope you think with doubt, in the next 10 years, will there be Deno official ecosystem expansion, completely replace Node and then affect the situation of Web ecosystem? You need to learn to think for yourself and hold yourself accountable for the consequences of thinking that will affect your future career.

2 Introduction & Intensive reading

Deno was written by Ryan Dahl, the mastermind behind Nodejs, who once said 10 things I regret about Nodejs. This is why there is a new pit, but Deno is not positioned as a replacement for Nodejs. In terms of overall functionality, Deno has bigger ambitions, which I suspect are to replace the old front and back end development model and make Deno dominate the whole front and back end development process.

Nodejs is written in C++, while Deno is written in Rust with an asynchronous programming framework of choice Tokio, and uses V8 engine to parse Javascript with built-in Ts parsing.

The installation

The Deno supports the following installation modes:

Shell:

curl -fsSL https://deno.land/x/install/install.sh | sh
Copy the code

PowerShell:

iwr https://deno.land/x/install/install.ps1 -useb | iex
Copy the code

Homebrew:

brew install deno
Copy the code

Chocolatey:

choco install deno
Copy the code

The script execution mode is deno Run, which can be likened to Node, but has different functions and supports remote files. In fact, remote dependency is a feature of deno, which is also controversial:

deno run https://deno.land/std/examples/welcome.ts
Copy the code

Remote scripts are allowed to load resources in ts files, which will be discussed later:

import { serve } from "https://deno.land/[email protected]/http/server.ts";
const s = serve({ port: 8000 });
console.log("http://localhost:8000/");
for await (const req of s) {
  req.respond({ body: "Hello World\n" });
}
Copy the code

security

Deno is secure by default. It has no environment, no network access, no file read and write, and no ability to run child processes. So if you run a permission-dependent file directly, you will get an error:

deno run file-needing-to-run-a-subprocess.ts

# error: Uncaught PermissionDenied: access to run a subprocess, run again with the --allow-run flag
Copy the code

Allow-read, –allow-write, –allow-net, and so on:

deno --allow-read=/etc
Copy the code

The preceding command indicates that files in the /etc folder have the read permission.

In addition to calling directly with arguments, calling Bash scripts, you can also run it with Make, or start it with similar drake.

Or use the deno install command to convert the script to a shortcut command:

deno install --allow-net --allow-read -n serve https://deno.land/std/http/file_server.ts
Copy the code

-n stands for –name, and you can rename the script, as in the example above, Serve command is equivalent to deno run – allow – net – allow – read https://deno.land/std/http/file_server.ts.

The standard library

Deno has its own features in the standard library and provides official versions of common functions to ensure availability and stability. Here are some comparisons with the Npm tripartite library:

Deno Module	Description	npm	Equivalents
colors	Adds color to the terminal		chalk, kleur, and colors
datetime	Helps working with the JavaScript Date object
encoding	Adds support for external data scructures like base32, binary, csv, toml and yaml
flags	Helps working with command line arguments		minimist
fs	Helps with manipulation of the file system
http	Allows serving local files over HTTP		http-server
log	Used for creating logs		winston
testing	For unit testing assertion and benchmarking		chai
uuid	UUID generation		uuid
ws	Helps with creating WebSocket client/server		ws

From this point of view, Deno serves as both the operating environment and the base ecology, alleviating the choice difficulty under the Npm ecology. This matter needs to be dialectically viewed: the integration of official packages is very necessary for modules with defined functions, and improves the stability of the underlying library. But Deno ecology also has tripartite libraries, and essentially tripartite libraries and official libraries in the function of no barriers, because the implementation code is similar, the only difference is who can its stability platform, assuming that Microsoft and Deno at the same time based on Npm ecology and Deno ecology official library, are guaranteed to continue to maintain, who do you trust more? Whether the authorities have an advantage depends on their own strength.

Built-in Typescript

TS is built into Deno, so we can run Typescript files with Deno run test. TS without ts-Node. It’s worth noting that Deno also uses the Typescript engine to parse Js internally to be parsed by the V8 engine, so there’s not much change in nature, just a more standardized Deno ecosystem.

With built-in TS support, there is no need to write the tsconfig.json configuration, but you can still customize it:

deno run -c tsconfig.json [file-to-run.ts]
Copy the code

Deno also has TS strict mode turned on by default, so you can think of Deno as a runtime environment for building high quality libraries, based on the existing ecosystem, but with more built-in technology selection, much like Facebook’s Rome but much more thorough.

In fact, from the implementation point of view, we can also write a similar engine like deno Run test.ts based on Javascript ecology, but it is executed by JS driver, and may choose Webpack for compilation, but deno itself is based on Rust implementation. And reimplements a set of module loading standards, arguably reinterpreting the W3C standard specification in a lower-level way, in hopes of addressing various pain points in the Javascript ecosystem.

Support for Web standards

Deno also supports W3C standards, so apis like Fetch and setTimeout can be used directly. If you write the code according to the several functions supported by Deno, you can ensure that the three platforms can run cross-platform on Deno, Node and Web.

While we are still some way from full implementation of all W3C standard specifications, we see a commitment to the Deno compliant specification.

ESModule

Modularity is the highlight of Deno, which uses the official ESModule specification, but reference paths must be suffixed:

import * as log from "https://deno.land/std/log/mod.ts";
import { outputToConsole } from "./view.ts";
Copy the code

Deno does not need to declare dependencies, the code reference path is the dependency declaration, will include the full path and file suffix, also support network resources, can get rid of NPM centralized package management mode, because the path can be any network address.

Package management

For the import * as the log from “https://deno.land/std/log/mod.ts”; This line of code, Deno will download to a cache folder, the user will not be aware of the existence of this folder and the process, that is, there is no node_modules in the Deno environment.

It is also possible to force a cache refresh using deno –reload.

However, the issue of “Deno decentralization” should also be viewed dialectically. Although network sources are cited, the following problems will arise:

1. There is actually a “node_modules”, but the user can’t see it.
2. When the network download speed is put into operation, the first startup is still very slow.
3. In common mode, no lock is requireddeps.tsUse, which will be mentioned later.

Even NPM, which is labeled as a “centralized villain”, also has a decentralized aspect. Because NPM supports private deployment, both speed and stability can be controlled by the company itself. In terms of stability, NPM has an overwhelming advantage.

Three party libraries

Deno also has a third-party library ecosystem, with 221 third-party libraries to date.

Because Deno uses network resources, we can directly reference network resource packages by virtue of THE CDN service provided by Pika:

import * as pkg from "Https://cdn.pika.dev/preact@ ^ 10.3.0";
Copy the code

Although this may seem lightweight, it is still necessary for the company to build its own “Pika” to ensure stability and do global CDN caching.

Say goodbye to the package. The json

The package information under the NPM ecosystem is stored in package.json and includes but is not limited to the following:

• Project meta information.
• Project dependencies and version numbers.
• Dependencies are also classified, for exampledependencies,devDependenciesevenpeerDependencies.
• Mark entry,main 和 moduleAnd for TStypes 与 typingsScaffoldingbinAnd so on.
• NPM scripts.

As standards have been updated, package.json information has become bloated.

For Deno, deps.ts is used to centrally manage dependencies:

export { assert } from "https://deno.land/[email protected]/testing/asserts.ts";
export { green, bold } from "https://deno.land/[email protected]/fmt/colors.ts";
Copy the code

Deps.ts is just a plain file that describes your project’s dependencies exactly so that when you reference assert elsewhere, you can write something like this:

/ / import {assert} from "https://deno.land/[email protected]/testing/asserts.ts".
import { assert } from "./deps.ts";
Copy the code

If you need to lock dependencies, you can declare them using deno –lock=lock.json.

deno doc

The deno doc

command generates documents from files according to JS doc rules and also supports TS syntax, such as the following code:

/** Asynchronously fulfill a response with a file from the local file
 * system. */
export async function send(
  { request, response }: Context,
  path: string,
  options: SendOptions = { root: "" }
): Promise<string | undefined> {
  // ...
}
Copy the code

The following documents are generated:

function send(_: Context, path: string, options: SendOptions): Promise<string | undefined>
Asynchronously fulfill a response with a file from the local file system.
Copy the code

Deno documentation is generated using this command. You can visit the official documentation to see how it works.

Built-in tool chain

The front-end Javascript tool chain is quite chaotic. Although Umi and other frameworks in the industry have been packaged out of the box, Javascript is designed to be directly used in the browser, including the browser’s modular support for independent building tools. The future of Webpack is doomed to extinction.

Deno solves this problem with a built-in toolchain, including:

• Testing: provideddeno testCommand andDeno.test()Test the function.
• Formatting: provides vscode plug-ins.
• Compilation: provideddeno bundleCommand.

It is worth noting, however, that deno Bundle currently provides relatively little capability for the most important aspects of compilation, such as Tree Shaking.

The industry has been trying to improve the construction efficiency with Rust and other languages. For example, @Chen Chengcheng made the @umijs/plugin-esbuild plug-in based on ESbuild to improve Umi construction speed, but in order to prevent the production of build products inconsistent with the default rules of Webpack, Only its minifier function is used.

The same is true for deno. There is no evidence that deno builds are perfect for a WebPack environment, so don’t assume that just because deno released version 1.0 means it’s ready for production.

3 summary

As stated at the end of the article, Deno will be releasing version 1.0, but it is still not a complete replacement for Nodejs. The main reason behind this is the historical compatibility cost, which means that fully supporting the entire Node ecosystem is not only a design issue, but also a manual task that needs to be solved one by one.

Deno’s support for the Web is also refreshing, but it cannot be used in the production environment. In addition to improving the official and tripartite ecology, Deno bundle’s lack of Tree Shaking ability and the building products cannot guarantee the same as the current Webpack. This will result in high migration costs for large applications that require high stability.

The most eye-catching change is the modular part. Relying on complete decentralization is a very good design in the long run, but the infrastructure and ecology have to reach a better level.

Finally, let’s put ourselves in the position of a prognosticator and consider whether Deno will ever catch on:

Deno’s original intention was to make a better Node, but unfortunately, for this level of ecosystem underlying tools, it is as difficult to make a new one and make it popular again as it is to make a new Alibaba and replace the current Alibaba. That is, to do the same thing at different points in time, even if the latter can learn from it, chances are it won’t replicate the previous successful route.

From the point of view of the function of Deno, it solves many pain points of Node, including decentralized management, a bit of the meaning of cloud development, but in 2020, cloud development based on Nodejs and Webpack have come out, to be honest, there is no room for Deno. In terms of functionality, Deno’s ability to parse Javascript in V8 is not revolutionary in terms of performance or functionality, and technological breakthroughs are almost impossible.

Deno’s ideas are certainly more advanced than Node’s, but not ten times better than Node’s, and it’s not going to shake the Node ecosystem, even by the Node authors themselves.

But I could be wrong about all of this.

Close read Deno 1.0 · Issue #248 · dT-fe /weekly

If you’d like to participate in the discussion, pleaseClick here to, with a new theme every week, released on weekends or Mondays. Front end Intensive Reading – Helps you filter the right content.

Pay attention to the front end of intensive reading wechat public account

Copyright Notice: Freely reproduced – Non-commercial – Non-derivative – Remain signed (Creative Commons 3.0 License)