Deno 1.0 深度解析：下一代 JavaScript 与 TypeScript 运行时

Deno 1.0 发布，以浏览器安全模型、原生 TypeScript 支持和去中心化模块为特色，重塑命令行脚本体验。

背景：为什么还需要新的脚本环境？

动态语言在软件开发中扮演着重要角色：脚本化允许开发者快速、简洁地组合复杂系统，无需操心内存管理或构建系统。近年来 Rust 和 Go 等语言让生成高性能原生代码变得容易，但作者强调，一个能广泛覆盖问题域的强大脚本环境依然不可或缺。

JavaScript 是最广泛使用的动态语言，运行在每一台带有浏览器的设备上。大量程序员精通 JS，其执行优化也投入了巨大努力。通过 ECMA International 这样的标准组织，语言本身得以持续改进。作者认为，无论是在浏览器环境还是独立进程中，JavaScript 都是动态语言工具的自然选择。

Node.js 作为最初的尝试，证明是非常成功的平台。但 Node 设计于 2009 年，那时 JavaScript 与现在大为不同。Node 不得不自创一些概念，后来这些概念被标准组织以不同方式采纳（详见《Design Mistakes in Node》演讲）。由于用户基数庞大，Node 的演化艰难且缓慢。如今 JavaScript 语言变化万千，加上 TypeScript 等新工具，构建 Node 项目常常意味着管理繁重的构建系统，削弱了脚本编程的乐趣。

更根本的是，Node 通过 NPM 仓库集中管理外部库依赖，这与 Web 的去中心化理念不符。作者认为 JavaScript 生态已发生足够大的变化，值得重新做一次简化。他们想要一个有趣且高效、能应对各类任务的脚本环境。

Deno 是什么？

Deno 是一个新的运行时，用于在浏览器之外执行 JavaScript 和 TypeScript。它试图提供一个独立的工具来快速编写复杂功能。Deno 永远是一个独立的可执行文件（single executable file）。它像浏览器一样会从网络获取外部代码——一个文件就能定义任意复杂的行为，而无需任何配置文件或预安装过程，只需 deno run example.js。

示例（启动 HTTP 服务器）：
javascript
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" });
}

这一行 import 就引入了完整的 HTTP 服务器模块，无需任何额外配置。

安全沙箱：浏览器模型用于命令行

Deno 默认在安全沙箱中执行代码。脚本在未获得权限时，无法访问硬盘、打开网络连接或进行其他恶意操作。类似浏览器需要用户授权才能访问摄像头和麦克风，Deno 在终端中提供了类似机制。上面的 HTTP 服务器示例必须加上 --allow-net 命令行参数才能运行。

Deno 坚持不偏离标准化的浏览器 JavaScript API。尽管并非每个浏览器 API 都适用于 Deno，但凡是适用的地方，它就严格按标准实现。

一流的 TypeScript 支持

为了覆盖从一行脚本到复杂服务端逻辑的广泛问题域，Deno 原生支持 TypeScript，无需额外工具。运行时专门为 TypeScript 设计：It provides type checking on the fly, 并且 deno types 命令可以导出 Deno 提供的所有 API 的类型声明。Deno 的标准模块全部用 TypeScript 编写，运行时内部也考虑到了类型擦除后的性能优化。

Promises 贯穿始终：解决背压问题

Node 的设计先于 Promises 和 async/await。Node 的替代品是 EventEmitter，其核心 API（套接字和 HTTP）基于事件模式。除了 async/await 的便利性外，EventEmitter 模式还有背压问题：以 TCP 套接字为例，当收到数据包时触发 data 事件，回调会被无限制地触发，导致进程被事件淹没。由于 Node 会不断接收新的 data 事件，底层 TCP 套接字缺乏适当的背压，远程发送方不知道服务器已过载，持续发送数据。这导致系统尾部延迟差。

为解决此问题，Node 后来加了 pause() 方法，但这需要额外编码，并且因为泛滥问题只在进程繁忙时出现，许多 Node 程序仍可能被数据淹没。

而在 Deno 中，套接字依然是异步的，但接收新数据需要用户显式调用 read()。这样无需额外的暂停语义即可正确构造接收套接字。这不仅适用于 TCP 套接字，Deno 对系统调用的最底层绑定方式（称为 op）也基于 Promises。Deno 中的所有回调都以某种形式起源于 Promises。

Rust 有类似的 promise 抽象（Futures）。通过 op 抽象层，Deno 能轻松地将 Rust 的 Future 绑定为 JavaScript 的 Promise。

Rust 架构：分层设计，可插拔核心

Deno 不是单体程序，而是设计成一组 Rust crate，可在不同层次集成：

• deno_core：非常精简版本的 Deno，不依赖 TypeScript 和 Tokio，只提供 op 和资源基础设施，简单说就是一个把 Rust Future 绑定到 JavaScript Promise 的组织化方式。CLI 完全基于 deno_core 构建
• rusty_v8：提供高质量的 Rust 绑定到 V8 的 C++ API。该 API 尽量与原始 C++ API 对齐，是零成本绑定——你在 Rust 中操作的对象就是 C++ 中操作的对象（对比：之前尝试过的绑定如强制使用 Persistent 句柄）。这个 crate 在 GitHub Actions CI 中提供预构建二进制，也允许用户从源码编译 V8 并调整各种构建配置。所有 V8 源码都塞进了 crate 里。而 rusty_v8 试图提供安全接口，虽未达到 100% 安全，但已经很接近。能安全地跟像 V8 这样复杂的 VM 交互是很了不起的，这帮助发现 Deno 自身许多疑难 bug

稳定性承诺

Deno 承诺保持 API 稳定。但 Deno 有很多接口和组件，因此需要明确“稳定”的含义：

• 只有 Deno 命名空间（如 Deno.open()）里的 API 是作者发明且用于与操作系统交互的，这些 API 经过仔细审查，不会做出不向后兼容的变化
• 所有尚未准备好稳定化的功能都被隐藏在 --unstable 命令行标志后面，默认不启用

这样设计使得大多数用户不需要经常面对破坏性更改，同时新特性可以快速迭代验证。

对 Node.js 的批评与改进

文中多次批评 Node 的历史包袱：

1. 依赖集中: NPM 仓库是集中化的，不符合 Web 去中心化理想，Deno 使用 URL 导入模块
2. 回调地狱和背压问题: EventEmitter 模式不健康，Deno 用 Promise/async-await 解决
3. 构建工具链繁琐: TypeScript 支持需要额外配置，Deno 内置支持

但这些批评是在尊重 Node 贡献的前提下提出的，作者承认 Node 是成功的，只是时代变了，JavaScript 标准升级（如 Promise、async 等）使得重新设计更为合理。

总结与影响

Deno 1.0 的发布是 JavaScript 生态的里程碑事件，它用现代语言特性和系统设计哲学重新定义了服务端运行时。它的安全模型、去中心化模块机制和 Rust 底层设计，让开发者看到了一个新的方向。虽然 Node.js 依然是主流，但 Deno 的取舍必将在未来几年持续影响新项目的架构选择。

原文链接：https://deno.land/v1