Deno 1.0正式发布！它能替代 NodeJS 吗？

作者 丨 Deno 团队译者 丨 王强 策划 丨小智

学不动了？不存在的！

动态语言都是很有用的工具。用户可以使用脚本快速简洁地将复杂的系统连接在一起并表达自己的想法，而不必顾虑诸如内存管理或系统构建之类的细节。近年来，像 Rust 和 Go 这样的编程语言让程序员能更轻松地生成复杂的原生代码；这些项目也是计算机基础架构发展历程中极为重要的里程碑。但是，我们认为开发工作中有一个可以应对多种问题领域的强大脚本环境还是非常重要的。

JavaScript 是应用最广泛的动态语言，只需一个 Web 浏览器就能在所有设备上运行。精通 JavaScript 的程序员数不胜数，并且社区已经为了优化 JS 的执行效率而投入了大量资源。在像 ECMA International 这样的标准组织推动下，JS 语言得到了精心而持续的改进。我们相信，无论是在浏览器环境中还是作为独立进程使用，JavaScript 都是动态语言工具链的首选。

我们在这一领域的早期项目 Node.js 被证明是一个非常成功的软件平台。人们发现它能很好地用于构建 Web 开发工具、构建独立的 Web 服务器以及其他许多用例。但是，Node 是在 2009 年设计的，当时的 JavaScript 与今天的语言版本有着明显的区别。出于用户需求考虑，Node 在当时必须发明许多概念，其中很多在后来都被标准组织采纳，并通过各种方式加入了 JS 语言规范。在“Node 中的设计错误”演讲中对这一话题有更具体的讨论。

https://www.youtube.com/watch?v=M3BM9TB-8yA

由于 Node 拥有大量用户，因此系统进化起来既困难又缓慢。

随着 JavaScript 语言的不断变化，以及诸如 TypeScript 之类的新增改进，Node 项目的构建可能会成为一项艰巨的工作，过程中需要管理构建系统和其他需要繁重操作的工具链，结果大大抵消了动态语言脚本的优势。此外，通过 NPM 存储库链接到外部库的机制本质上是中心化的，这不符合 Web 的发展理念。

我们认为 JavaScript 与其周围的软件基础架构已经在改进的道路上走得够远了，应该做一些简化工作了。我们想要寻求一种可用于多种任务的有趣且高效的脚本环境。

用于命令行脚本的 Web 浏览器

Deno 是一个新的运行时，用于在 Web 浏览器之外执行 JavaScript 和 TypeScript。

Deno 试图提供一个独立的工具来快速编写功能复杂的脚本。Deno 是（并将始终是）单个可执行文件。就像 Web 浏览器一样，它知道如何获取外部代码。在 Deno 中，单个文件可以定义任意复杂的行为，而无需其他任何工具。

import { serve } from "https://deno.land/std@0.50.0/http/server.ts";
for await (const req of serve({ port: 8000 })) {
  req.respond({ body: "Hello World\n" });
}

上面的代码段只需一行代码就将一个完整的 HTTP 服务器模块添加为了一个依赖项。没有额外的配置文件，没有预先的安装工作，只需输入 deno run example.js 即可。

与浏览器一样，默认情况下 Deno 中的代码会在安全的沙箱中执行。未经允许，脚本无法访问硬盘驱动器、打开网络连接或进行其他任何可能引入恶意行为的操作。浏览器提供了用于访问相机和麦克风的 API，但用户必须首先授予权限才能启用它们。Deno 在终端中提供了模拟行为。除非提供 --allow-net 命令行标志，否则上述示例将失败。

Deno 是精心设计的，避免偏离标准化的浏览器 JavaScript API。当然，并不是每个浏览器 API 都与 Deno 相关，但只要有 API 和 Deno 有联系，后者都不会偏离标准。

一流的 TypeScript 支持

我们希望 Deno 适用于广泛的问题领域：从小型单行脚本到复杂的服务端业务逻辑都能适用。随着程序变得越来越复杂，具有某种形式的类型检查也成为编程语言越来越重要的特性。TypeScript 是 JavaScript 语言的扩展，允许用户选择提供类型信息。

Deno 无需其他工具即可支持 TypeScript。运行时在设计时就考虑了 TypeScript 的支持。deno types 命令为 Deno 提供的所有内容提供类型声明。Deno 的标准模块全部使用 TypeScript 编写。

Promise 的支持下放到底层

Node 是在 JavaScript 引入 Promise 或 async/await 概念之前设计的。Node 中与 promise 对应的是 EventEmitter，像套接字（socket）和 HTTP 这样的重要 API 则环绕其外。在 async/await 这样的设计优势外，EventEmitter 模式还存在一个背压问题。以 TCP 套接字为例。套接字在收到传入数据包时将发出“数据”事件。这些“数据”回调将以不受限制的方式发出，结果会让事件充斥整个进程。由于 Node 会继续接收新的数据事件，而底层 TCP 套接字没有适当的背压，于是远程发送方不知道服务器已超负荷，还会继续发送数据。为了缓解这个问题，Node 添加了 pause() 方法。这可以解决问题，但是需要额外的代码；而且由于事件泛滥问题只在进程非常繁忙时才会出现，因此许多 Node 程序都可能出现数据洪水的现象。结果是系统的尾部延迟时间变得很长。

在 Deno 中，套接字仍然是异步的，但是接收新数据需要用户显式 read()。正确构造一个接收套接字不需要额外的暂停语义。这不是只针对 TCP 套接字。系统的最低绑定层从根本上绑定了 promise——我们称这些绑定为“ops”。Deno 中的所有回调，无论形式如何，都是来自 promise 的。

Rust 有它自己的类似于 promise 的抽象，称为 Future。通过“op”抽象，Deno 让开发人员可以轻松将 Rust 的基于 future 的 API 绑定到 JavaScript promise 中。

Rust API

我们在 Deno 中提供的主要组件是 Deno 命令行界面（CLI）。CLI 现在是 1.0 版本。但是 Deno 并不是一个单体程序，而是设计为一个 Rust crate 的集合，以实现不同层次的集成。

deno_core crate 是 Deno 的核心骨架。它不依赖于 TypeScript 或 Tokio。它只是提供了我们的 Op 和 Resource 基础架构。换句话说，它提供了一种有组织地将 Rust future 绑定到 JavaScript promise 的方式。CLI 当然完全建立在 deno_core 之上。

rusty_v8 crate 为 V8 的 C++ API 提供了高质量的 Rust 绑定。该 API 试着尽可能与原始 C++ API 匹配。它是零成本绑定：Rust 中公开的对象与你在 C++ 中操作的对象完全相同。（例如，之前针对 Rust V8 绑定的尝试强制使用持久句柄。）这个 crate 提供了在 Github Actions CI 中内置的二进制文件，但它还允许用户从头开始编译 V8 并调整一众构建配置。所有 V8 源代码均在 crate 自身中分发。最后，rusty_v8 尝试成为一个安全的接口。它还不是 100％安全的，但我们正在接近这个目标。能够以安全的方式与像 V8 这样复杂的 VM 交互是非常棒的事情，并且让我们发现了 Deno 本身中存在的许多难以察觉的错误。

稳定性

我们保证在 Deno 中维持一个稳定的 API。Deno 有很多接口和组件，因此明确我们所说的“稳定”的含义是很重要的。我们开发的与操作系统交互的 JavaScript API 都可以在“Deno”命名空间（例如 Deno.open()）中找到。这些 API 已经过仔细检查，我们不会对它们做出向后不兼容的更改。

尚未准备稳定下来的所有功能都隐藏在 --unstable 命令行标志后面。你可以在此处查看不稳定接口的文档：

https://doc.deno.land/https/raw.githubusercontent.com/denoland/deno/master/cli/js/lib.deno.unstable.d.ts

在后续版本中，其中一些 API 也会被稳定下来。

在全局命名空间中，你会找到其他所有对象（例如 setTimeout() 和 fetch()）。我们已经尽力让这些接口与浏览器中的接口保持一致。但是如果发现意外的不兼容问题，我们将发出更正。这些接口不是我们，而是浏览器标准定义的。我们发布的所有更正均是错误修复，而不是接口更改。如果存在与浏览器标准 API 不兼容的问题，则它可以在主要版本发布之前得到更正。

Deno 也有许多 Rust API，比如说 deno_core 和 rusty_v8 crate。这些 API 都还不是 1.0 版本。我们将继续对它们进行迭代。

局限性

重要的是要了解 Deno 并不是 Node 的分支——它是一个全新的实现。Deno 的开发工作只经过了两年时间，而 Node 已经开发了超过十年。考虑到社区对 Deno 的兴趣，我们希望它会继续发展并成熟。

对于某些应用程序而言，Deno 可能是现下一种不错的选择，对于其他应用程序来说 Deno 还不够合适，具体取决于需求。我们希望透明地公开这些局限性，以帮助人们在考虑使用 Deno 时做出明智的决定。

兼容性

不幸的是，许多用户会沮丧地发现 Deno 缺乏与现有 JavaScript 工具的兼容性。Deno 与 Node（NPM）软件包总体来说是不兼容的。在deno.land/std/node/上建立了一个新的兼容性层，但它离完成还很遥远。

https://deno.land/std/node/

尽管 Deno 使用强硬的方法简化了模块系统，但毕竟 Deno 和 Node 是非常相似的系统，有着很接近的目标。随着时间的推移，我们希望 Deno 能够开箱即用地运行越来越多的 Node 程序。

HTTP 服务器性能

我们不断跟踪 Deno 的 HTTP 服务器性能。一个 hello-world 的 Deno HTTP 服务器每秒处理约 25,000 个请求，最大延迟为 1.3 毫秒。一个可比的 Node 程序每秒则处理 34,000 个请求，最大延迟介于 2 到 300 毫秒之间。

Deno 的 HTTP 服务器是在原生 TCP 套接字上面用 TypeScript 实现的。Node 的 HTTP 服务器使用 C 语言编写，并作为 JavaScript 的高级绑定公开。我们一直拒绝将原生 HTTP 服务器绑定添加到 Deno，因为我们要优化 TCP 套接字层，更一般地说是要优化 op 接口。

Deno 是一个不错的异步服务器，每秒 25k 请求足以满足大多数目的。（还不够用的话，那么 JavaScript 可能不是最佳选择。）此外，由于普遍使用 promise（如上所述），我们期望 Deno 一般来说能表现出更好的尾部延迟。综上所述，我们确信这一系统还能有更多的性能优势，并希望在将来的版本中实现这一目标。

TSC 瓶颈

在内部，Deno 使用微软的 TypeScript 编译器检查类型并生成 JavaScript。与 V8 解析 JavaScript 所花费的时间相比，它是非常缓慢的。在项目的早期，我们曾希望“V8 Snapshots”在这里能够带来明显的提升。Snapshots 肯定是有帮助的，但是它还是太慢了。我们当然认为可以在现有 TypeScript 编译器的基础上进行一些改进，但我们知道，显然我们最终需要在 Rust 中实现类型检查。这将是一项艰巨的任务，不会一蹴而就。但它可以在开发体验的关键路径上提供数量级的性能改进。TSC 必须移植到 Rust。如果你有兴趣合作解决这个问题，请与我们联系。

插件 / 扩展

我们有一个新生的插件系统，用于通过自定义操作扩展 Deno 运行时。但这个接口仍在开发中，并已标记为不稳定。因此，访问 Deno 提供的系统之外的原生系统是很困难的。