• Deno in 2020
  • Bartek Iwańczuk, Ryan Dahl
  • Translator: @ hylerrix
  • Original publication time/translation time: 20210115/20210122
  • This article belongs to the series of “The Art of Deno Research”. The original translation content will be updated to Deno Chinese official website.

With API stabilization, several large infrastructure reconstructions, and a number of high-profile feature openings, Deno 1.0 was released. In 2020, Deno faces many challenges and changes.

Please fill out this Deno survey and give us feedback to make Deno better in 2021.

Below is Deno’s annual review of 2020.

January: Bye libdeno, hello rusty_V8

Libdeno is a C++ library that makes it easy to bridge the V8 engine and Rust code in Deno. This library is difficult to understand and to develop additional functionality on top of. This led to rusty_V8 in fall 2019. Rusty_v8 is a Rust Crate that provides apis for the V8 engine. In December of that year, rusty_V8 had all the binding conditions necessary to replace libdeno. This work began in late 2019 with a partial rewrite of libdeno using rusty_V8. Because of the increasing test coverage in the Deno code base, we confidently moved forward and completed the work in two weeks. Libdeno was eventually completely replaced and removed in version 0.29.0, and rusty_V8 has since undergone significant refactoring related to binding type security.

Versions released this month: 0.28.0, 0.28.1, 0.29.0, 0.30.0, 0.31.0.

Intensive reading notes:

  • Libdeno: written in C++, originally used as a channel to connect TS/JS to V8.
  • Rusty_v8: an alternative to libdeno, developed in late 2019 to provide a higher quality Rust binding for V8’s C++ API.
  • V8: An open source JavaScript engine for Google. A very large project (over 600,000 lines of C++) typically takes 30 minutes to compile. In addition, V8 relies on Chromium’s custom build system (GN + Ninja), which is not easy to use outside of Chromium.
  • Rust: The Rust language is fast and memory efficient, with no runtime or garbage collector. Rust’s rich type system and ownership model ensures memory safety and thread-safety, eliminating many class errors at compile time.

References:

  • replace libdeno with rusty_v8
  • The long road to rusty_v8
  • Interaction with V8

February: Deno FMT is now built by dprint, deno test subcommand

This month we completely refactored the deno FMT. Until then, deno FMT was a simple subcommand that was just an alias for “deno run”, which eventually pointed to Prettier. This means that after Deno FMT is run for the first time and every time Prettier is upgraded, the user must download the latest version of Prettier. This doesn’t quite fit with Deno’s promise to use built-in tools right out of the box. Prettier, meanwhile, is really slow and has some performance problems.

We were recommended for David Sherret’s DPrint library, a SWC JavaScript parser based on Kang Dong Yun and a code formatting tool written by Rust. Dprint can do the same job as Prettier, but several orders of magnitude faster. After some preliminary calculations, we decided to use Dprint in denO FMT.

Deno Test also has problems downloading modules from the standard library when the command is first run. This led to the addition of the new deno.test () API, and the Deno test CLI subcommand made the test a first-class citizen of Deno.

This month’s release: 0.32.0, 0.33.0, 0.34.0, 0.35.0.

Intensive reading notes:

  • deno fmt: one of Deno’s built-in tools for formatting TypeScript/JavaScript code Early rely onprettier, is now supported by Rust-based dprint with improved speed and performance.
  • deno test: One of deno’s built-in tools to provide basic testing functions right out of the box.
  • Prettier: Node under well-known configurable type code formatting tools, can be in the editor, submit plans or CI, and many other environments to format a variety of language (TS/JS/CSS/HTML/GraphQL YAML/Markdown, etc.), more languages can through community plugin support.
  • Dprint: A code editor that supports defining plug-ins and configurations, built in the Rust language. It is fast and the plugin supports URL or file import (WebAssembly). Supports formatting TS/JS/JSON/C#/VB/Markdown files, while there is a plugin for Prettier It is currently in early active development.
  • SWC is a rust-based JavaScript/TypeScript parser with excellent performance. JavaScript parsers include an implementation specification that dates back to the ESTree project, Common JavaScript parsers developed based on JS include Uglip-JS, Esprima, Acorn, @Babel/Parser (Babylon), Espree, TypeScript; Common JavaScript parsers developed in other languages include Sucrase, SWC, esBuild; Other AST tools include: Recast, Jscodeshift, ASTExplorer, etc.

References:

  • A brief introduction to the various JavaScript parsers
  • Why you should use SWC (and not Babel)

March: V8 debugger, Deno Doc, Deno Upgrade

One of the main obstacles to Deno 1.0 is the lack of Chrome Devtools support. Therefore, we put a lot of effort into increasing support for the V8 debugger and improving the ability to connect to Deno processes using Chrome Devtools.

Two new commands have also been added to the CLI: deno doc and deno Upgrade.

We also experienced huge improvements in the build process. Until then, every build in Deno resulted in V8 being rebuilt at the source level. V8 is a huge C++ project that often takes more than 30 minutes to build. Despite a lot of build caches and more tricks, we’ve never been able to overcome them better. Now, we’ve added the ability for Rusty_V8 to generate and download pre-built static libraries on Github distributions, allowing the Deno build process to bypass V8 builds entirely. This simplifies and speeds up CI building and, more importantly, makes it easier for contributors to build Deno.

Versions released this month: 0.36.0, 0.37.0, 0.37.1, 0.38.0

Intensive reading notes:

  • deno doc: one of the built-in tools to generate relevant JSDoc documents from source code.--jsonFlags can be generated in JSON format or used to generate module documents.
  • deno upgrade: built-in command. You can use this command to upgrade the Deno version.
  • Chrome DevTools: Chrome DevTools is an important debugging tool to assist developers in Web development. DevTools is part of Chromium and can be integrated as a standalone project by containers such as Electron. DevTools is divided into four parts: Debugger front end (integrated by the Chromium kernel layer by default), debugger back end (Chromium/V8/Node.js), debug protocol, message channel (Embedder, Web Socket, Chrome Extensions, USB/ADB Chaeeml).

References:

  • Chrome DevTools debugging technology
  • Get started debugging JavaScript in Chrome DevTools
  • Web debugging techniques in detail

April: Break all apis to build critical stability

This month, in preparation for the 1.0 release, focuses on the API in reviewing the Deno Global. This led to many disruptive changes. We are careful about this: any API that we are not sure about needs to be moved to a position after the “Unstable” flag.

This was an important promise of version 1.0; There will be no disruptive changes to the Deno API marked as stable until 2.0 is released.

This month marks the final stage of the release of Deno named 0.x.y.

Versions released this month: 0.39.0, 0.40.0, 0.41.0, 0.42.0.

Intensive reading notes:

  • Built-in standard library stable API: doc. Deno. Land/builtin/sta…
  • Built-in standard library unstable API: doc. Deno. Land/builtin/uns…
  • The general history of Deno 0.X. Y release: from V0.0.1 on August 18, 2018 to V0.42.0 on April 30, 2020-20, we iterated 82 versions in 621 days. There are 73 versions, starting with v0.34.0, each of which also updates the standard library version.

May: Deno 1.0 is officially released

The following features were removed from the tag earlier this month:

  • JSON imports
  • WASM imports
  • window.location API
  • Rust API for deno crate

The reason for the removal was that we didn’t want to provide the API because JSON/WASM imports lacked support for the underlying specification, or because deno Crate had the additional maintenance burden of the Rust API.

Finally, on May 13, a full two years after Ryan’s original Deno talk, we released 1.0.

On social media, this version is very popular. Our related blog was widely circulated. We also gained a lot of new users and new contributors.

After release we nervously returned to work on the important components of the runtime: dependency analysis in the TypeScript host was rewritten using SWC. This change marks the beginning of our effort to rewrite parts of the TypeScript infrastructure with Rust.

1.0.0-RC1, 1.0.0-rC2, 1.0.0-RC3, 1.0.0, 1.0.1, 1.0.2, 1.0.3

Intensive reading notes:

  • Deno JSON imports: 1.0 was removed before release due to lack of standards, want to import one.jsonThe file can be in there--allow-readIn the case of writingDeno.readTextFile 或 Deno.readTextFileSyncTo implement. This proposal was made and discussed on 21 October 2018 (# 1048).
  • WASM imports: 1.0 was removed before release due to lack of standards. This proposal is made at (# 2552) (# 5609), etc. Esm integration standard for WebAssemblyThe proposal process. That was removedimport './foo.wasm'Is supported, but can still be used through the WebAssembly API.

June: Incremental type checking and deno Lint

One of the most common feedback we received from the community after 1.0 was that TypeScript compilation and type checking were very slow. From there we looked at improving TSC integration to support incremental type checking. After several iterations of trial and error PR, we were able to make the features work and significantly improve development efficiency. Although we managed to speed up type checking by taking advantage of TSC’s incremental API, we still rely on it to emit escaped sources. One of TypeScript’s great design principles is that it’s just JavaScript with additional syntax, so stripping out type information (converting to JavaScript) is relatively easy. So we set the goal of being able to use SWC for migration in Rust while continuing to use TSC for type checking.

After several months of development, in a separate repository, we added the new deno Lint subcommand. This is another project built on top of the SWC JavaScript parser.

This month’s releases: 1.0.4, 1.0.5, 1.1.0, 1.1.0, 1.1.2.

Intensive reading notes:

  • TSC: Represents the TypeScript compiler module, and TypeScript provides TSC commands to compile on the command line.
  • Deno_lint: is a brand new repository built on top of the SWC parser developed by Rust. Works in conjunction with Deno’s built-in TSC.

July: Converts internal runtime code from TypeScript to JavaScript

This month, we made the difficult decision to convert our internal runtime code from TypeScript to JavaScript. Several factors led to this decision: Each build of Deno’s internal runtime code, type checking, pre-snapshot binding, were complex and slow build steps. We have two separate TypeScript compiler hosts. One is deno_typescript Crate only for the build process, and the other is included in the Deno binary. In addition, the entire process had a significant impact on build time: a 2-minute incremental rebuild! By using plain JavaScript, we can greatly simplify the internal build dependencies and overall complexity. Because the actual JavaScript code is generated by the TypeScript compiler as a single file package, we have little control over the type of output code. The ES module is converted to a SystemJS loader that uses the bundle, which adds a lot of code to the final bundle.

This month’s releases: 1.1.3, 1.2.0, 1.2.1, 1.2.2.

Intensive reading notes:

The JavaScript specification includes many built-in features, from mathematical functions to a full-featured regular expression engine. Each newly created V8 context has these functions available from the start. For this to work, the global object (for example, the Window object in the browser) and all the built-in functionality must be set and initialized to V8’s heap when the context is created. It will take quite a long time to do it from scratch.

Fortunately, V8 uses a shortcut to speed things up: Just like defrosting instant pizza, we deserialize the pre-prepared snapshot directly into the heap to get the initialization context. On a normal desktop computer, this can reduce the time to create a context from 40 milliseconds to less than 2 milliseconds. On a normal mobile phone, this could mean the difference between 270 milliseconds and 10 milliseconds.

August: New mirror source site is released

Deno. land/posts/ Regis…

On August 3rd we released a new deno.land/x image source that can be used to integrate with Github using WebHooks. Whenever a module is updated, our system downloads and stores its source code forever, so we can rely on immutable source code links.

Because of some of the off-the-record work that was done while using the Deno infrastructure, we began working to decompose the Deno system into smaller “op Crates” that could be mixed and matched to generate custom V8 runtimes. In August, we took the first step toward this goal with the release of deno_Web Crate, which provides some basic Web apis, such as Event, TextUncoder, and TextDecoder.

This month, the benchmark system was rewritten using Rust, marking the beginning of the humdrum work of reducing the build dependency of the Deno project.

This month’s releases: 1.2.3, 1.3.0, 1.3.1, 1.3.2.

Intensive reading notes:

  • Deno mirror source: Where each version of a registered project is permanently saved to provide trusted URL resources. The domestic image source acceleration service can use x.deno.js.cn.
  • Deno Benchmark system: As part of the Deno continuous integration and test pipeline, to measure certain critical performance at run time. Runtime metrics include execution time, thread count, system call count, maximum memory usage; TypeScript performance metrics include type checking, I/O, HTTP latency, HTTP proxy throughput, and throughput. Size metrics include file size, bundle size, and Cargo dependencies. Visualize data long access address: deno.land/benchmarks.

September: WebSocket API, CSS styles under terminal, file listening, test coverage

This month, we released our biggest feature release since 1.0. For more details, see 1.4.0 Release Documentation.

Another important change is in the version maintenance part of the project. The release schedule is officially changed: instead of monthly releases, new releases are released every six weeks to match Rust and Chrome projects.

This month’s releases: 1.3.3, 1.4.0, 1.4.1, 1.4.2.

Intensive reading notes:

  • WebSocket: A general-purpose computer protocol that provides a full-duplex communication channel over a single TCP connection. The WebSocket protocol was standardized as RFC6455 by the IETF in 2011. WebSocket is different from HTTP.
  • CSS style under terminal: Most modern browsers support the consoleconsole.logDeno, which aims to be as web-compatible as possible, is now working to better support CSS styling under the terminal. The CSS properties supported are as followscolor,background-color,font-weight,font-style,text-decoration-color 和 text-decoration-lineEtc., depending on the ANSI support of the developer terminal.
  • File to monitor: The service automatically restarts during the hot update of version 1.4. This parameter is requireddeno run --watch.
  • Test coverageVersion 1.4 supports obtaining test coverage reports, which are required to be useddeno test --coverage.

October: REPL refurbishment, bundle improvements, default isolatedModules

1.5.0 Release Notes.

The biggest change this month is that the isolatedModules option is enabled by default in the TypeScript compiler host. This setting changes TypeScript’s behavior to ensure that every file can be compiled in isolation (without knowing its type or other modules) by tools other than TSC, such as SWC and Babel. This change had a significant impact on the module ecosystem, making some popular modules unusable until the maintainers tweaked the code to support isolatedModules.

This month we also introduced a new bundle feature in SWC, which is another step toward moving the original TypeScript compiler to Rust.

This month’s release: 1.4.3, 1.4.4, 1.4.5, 1.4.6, 1.5.0, 1.5.1.

Intensive reading notes:

  • isolatedModules: performs additional checks to ensure that separate compilations (such as transpileModule or @babel/plugin transform typescript) are secure. If you set it upisolatedModules, all implementation files must be modules (which means it has some form of import/export). If any file is not a module, an error occurs:'index.ts' cannot be compiled under '--isolatedModules' because it is considered a global script file. Add an import, export, or an empty 'export {}' statement to make it a module.

November: Major overhaul of TSC compiler infrastructure

This month we saw the culmination of Kitson Kelly’s weeks-long rewriting of the compilation pipeline. It further improves TypeScript compilation speed and, most importantly, relieves a lot of technical debt.

Deno_crypto op Crate is also added.

This month’s releases: 1.5.2, 1.5.3, 1.5.4.

Intensive reading notes:

  • Crates. IO/is a package management repository under Rust.

December: self-contained binary files and LSPS

1.6.0 Release Notes.

In December, we released version 1.6 with two milestone features: self-contained binaries and language servers. Deno Compile is one of the expected features of deno’s bug tracker.

Improved development experience for all editors capable of using LSP by providing a built-in language server. It led to a third refurbishment of Vscode_deno, which is still in progress.

This month’s releases: 1.6.0, 1.6.1, 1.6.2, 1.6.3.

Intensive reading notes:

  • Self-contained binaries: Self-contained single binaries allow users to ignore the kernel source code, encapsulation and ready-to-use.
  • LSP language server protocol: red Hat, Microsoft, and Codenvy jointly introduced the editor /IDE and language server protocol, allows different editors/IDES to embed various programming languages, allowing developers to provide corresponding.
  • Vscode_deno: It has undergone more than three major renovations. Now supports TypeScript type checking, quick fixes, hover cards, IntelliSense, and more, which communicates with Deno’s built-in TypeScript. Integration with denO-Lint, with inline diagnostics; Support is also provided for denO FMT code formatting.

2021 outlook

Through 2020, we see a lot of growth in programs and communities. This gives us confidence in Deno’s support going into 2021. Stay tuned for exciting announcements to come!

If you’re interested in contributing to Deno, or just want to see what we’re up to, check out the following:

  • Answer the Deno survey;
  • View Q1 roadmap;
  • Improved IDE support by adding new language server capabilities;
  • Ensure Web compatibility by using the Web platform test suite.

Intensive reading notes:

  • Key questions of Deno questionnaire survey include: How long/how often/what do you use Deno for, what are the reasons that hold you back, what are your strengths/built-in tools that most appeal to you, how likely are you to use Deno in your next project, how do URL imports feel, and how willing are you to recommend Deno to those around you?
  • The Deno 2021 Q1 roadmap includes but does not stop there: 1.7.0 on January 19 (as scheduled), 1.8.0 on March 2, URL import supportdata:Refactoring runtime compiler API, support remote module access token, IIFE Budles, support React 17 JSX, RUsty_V8 ICU, use WPT test built-in Web API, standardized runtime permission API, structure worker clone API, WebGPU support, type definition of Bundles, V8 Fast API under OPS, URL import supportblob:And so on.
  • Web Test Suite: WPT Runner has been added in #8990 to support running Web platform tests, and is currently improving the range of passable tests.

Conclusion the translator

The full text of the translation, and in each chapter made a simple intensive reading notes. What makes this translation different is that the technical difficulty has increased by an order of magnitude. In this paper, there are many professional terms involved, and even those that need to understand the development of Deno features to be translated in place, are solved in the intensive reading process. The idea of a “Deno vocabulary” arose during the translation process and was synchronized to the deno-Tutorial repository.

Deno’s intensive reading series will focus on the official blog, and every translated article will strive for PR integration into the current Deno Chinese website. Welcome to star or follow the public account (@ningowood) on denO-Tutorial repository to receive timely news, and join hands to help denO become better in 2021!