【译】Deno 1.0正式发布

本文主要是介绍【译】Deno 1.0正式发布，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

原文链接：deno.land/v1

动态语言是有用的工具。脚本编写使用户可以快速简洁地将复杂的系统连接在一起并表达想法，而不必担心诸如内存管理或构建系统之类的细节。近年来，像 Rust 和 Go 这样的编程语言使生成复杂的原生机器码变得更加容易。这些项目是计算机基础架构中极为重要的发展。但是，我们坚定地认为拥有一个能够解决各种问题领域的强大脚本环境仍然很重要。

JavaScript 是使用最广泛的动态语言，可通过 Web 浏览器在每台设备上运行。大量的程序员精通 JavaScript，并且已经在优化其执行方面投入了大量精力。通过像 ECMA 这样的标准组织，JavaScript 被不断地改进。我们相信 JavaScript 是动态语言工具的自然选择，无论是在浏览器环境中还是作为独立进程。

我们在该领域的最初的成果：Node.js，被证明是一个非常成功的软件平台。人们发现它对于构建 Web 开发工具，构建独立的 Web 服务器以及许多其他用例很有用。但是，Node 是在 2009 年设计的，当时 JavaScript 是一种非常不同的语言。出于必要，Node 不得不去发明一些概念，这些概念后来被标准组织采纳，并以不同的方式添加到语言中。在Design Mistakes in Node演讲中，对此进行了更详细的讨论。由于 Node 拥有大量用户，因此发展该系统既困难又缓慢。

随着 JavaScript 的不断变化以及诸如 TypeScript 之类的新玩意，构建 Node 项目可能会成为一项艰巨的工作，比如管理构建系统和其他繁重的工具使其丢失了动态语言编程的乐趣。此外，NPM 这种中心化的包管理机制，并不符合 Web 的理想。

我们认为 JavaScript 和周围的软件基础架构已经发生了足够的变化，值得进行简化。我们寻求一种可用于多种任务并且有趣高效的脚本环境。

A Web Browser for Command-Line Scripts

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

Deno 试图提供一个独立的工具来快速编写复杂功能的脚本。 Deno 是（并将始终是）单个可执行文件。就像网络浏览器一样，它知道如何获取外部代码。在 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 服务器模块作为依赖项添加到一行中。没有其他配置文件，也不需要 install，只需要：deno run example.js。

与浏览器一样，默认情况下，代码在安全的沙箱中执行。未经允许，Deno 无法访问硬件、打开网络连接或进行任何其他潜在的恶意操作。浏览器提供了用于访问相机和麦克风的 API，但用户必须首先授予权限。 Deno 在终端中提供类似的行为。除非传递--allow-net，否则上面的示例将执行失败。

Deno 不会去偏离标准化的浏览器 JavaScript API。当然，并不是每个浏览器 API 都与 Deno 相关，但无论如何，Deno 都不会偏离标准。

First Class TypeScript Support

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

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

Promises All The Way Down

Node 是在 JavaScript 具有Promises或async/await概念之前设计的。 Node 中EventEmitter就相当于Promises，套接字和HTTP就是基于它实现的。除了async/await的人体工程学优势外，EventEmitter 模式还存在back-pressure问题。以 TCP 套接字为例：套接字在收到传入数据包时将触发data事件。这些data回调将以不受限制的方式发出，使events充满（泛洪）整个进程。由于 Node 继续接收新的数据事件，因此底层 TCP 套接字没有适当的back-pressure，因此远程发送方不知道服务器已超负荷并继续发送数据。为了缓解此问题，我们添加了 pause()方法。这可以解决问题但是需要额外的代码；而且由于泛洪仅在进程非常繁忙时才会出现，因此许多 Node 程序都可能被数据泛洪。结果将导致系统的尾部延迟时间变得很长。

在 Deno 中，套接字仍然是异步的，但是接收新数据需要用户显式调用read()。正确构造接收套接字不需要额外的pause()。这不是 TCP 套接字独有的。系统的最低绑定层从根本上与promises相关联——我们称这些绑定为ops。 Deno 中以某种形式出现的所有回调均来自promises。

Rust 有其自己的类似于promises的抽象，那就是Futures。通过op抽象，Deno 使得将 Rust 的future-basedAPI 绑定到 JavaScript promises 中变得容易。

Rust APIs

我们提供的主要组件是 Deno 命令行界面（CLI）。 CLI 今天发布了 1.0 版本。但是 Deno 并不是一个整体的程序，而是设计为 Rust crates 的集合，以便允许在不同的层中进行集成。

deno_core crate 是 Deno 的精简版。它不依赖于TypeScript或Tokio。它只是提供了我们的Op和资源基础架构。也就是说，它提供了一种将 Rust crates 绑定到 JavaScript promises 的方式。 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 本身存在的许多 bug。

Stability

我们承诺会在 Deno 中维持稳定的 API。 Deno 有很多接口和组件，因此将我们所谓的"stable"公开透明是很重要的。Deno 与操作系统交互的 JavaScript API 都可以在Denonamespace（例如Deno.open()）中找到。我们经过仔细检查，并且不会对它们进行向后不兼容的更改。

尚未稳定的所有功能都隐藏在--unstable命令行标志后面。您可以在此处查看不稳定接口的文档。在后续版本中，其中一些 API 也将变的稳定。

在全局名称空间中，您会找到各种其他对象（例如setTimeout()和fetch()）。我们已经尽力使这些接口与浏览器中的接口保持一致。但是如果发现意外的不兼容性，我们将更正它。毕竟使浏览器标准定义了这些接口，而不是我们。我们发布的所有更正均是 bug 修复，而不是接口更改。如果与浏览器标准 API 不兼容，那么在主要版本发版之前我们会更正它。

Deno 也有许多 Rust API，即deno_core和rusty_v8crates。这些 API 都还没有到达 1.0 的版本。我们将继续对它们进行迭代。

Limitations

重要的是要了解 Deno 不是 Node 的fork——它是一个全新的实现。 Deno 的开发仅两年时间，而 Node 的开发已超过十年。考虑到对 Deno 的兴趣，我们希望它会继续发展和成熟。

对于某些应用程序而言，Deno 可能是当今的不错选择，对于其他应用程序而言则尚未。这将取决于要求。我们希望对这些限制保持透明，以帮助人们在考虑使用 Deno 时做出明智的决定。

Compatibility

不幸的是，许多用户沮丧地发现 Deno 与现有 JavaScript 工具的兼容性问题。通常，Deno 与 Node（NPM）包不兼容。deno.land/std/node/是新出的 Node 兼容层，不过距离完成还要做很多工作。

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

HTTP Server Performance

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

Deno 的 HTTP 服务器是在基于原生 TCP 套接字之上的 TypeScript 中实现的。 Node 的 HTTP 服务器使用 C 语言编写，并作为对 JavaScript 的高级绑定公开。我们一直在遏制将本地 HTTP 服务器绑定添加到 Deno 的冲动，因为我们要优化 TCP 套接字层，也就是 op 接口。

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

TSC Bottleneck

在内部，Deno 使用 Microsoft 的 TypeScript 编译器检查类型并生成 JavaScript。与 V8 解析 JavaScript 所花费的时间相比，它非常慢。在项目的早期，我们曾希望“ V8 快照”在此能够带来重大改进。快照肯定有帮助，但是它仍然缓慢。我们当然认为可以在现有 TypeScript 编译器的基础上进行一些改进，但是对我们来说很显然，最终需要在 Rust 中实现类型检查。这将是一项艰巨的任务并且不会很快被实现。但它可以在开发人员经历的关键路径上提供数量级的性能改进。 TSC 必须移植到 Rust。如果您有兴趣合作解决此问题，请与我们联系。

Plugins / Extensions

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

首发链接：xietian.xyz/2020/05/14/…

联系译者：xietian19941007@gmail.com

这篇关于【译】Deno 1.0正式发布的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！