Deno——为什么引起这么大的轰动？

Deno 是什么？

Node.js 比较

再说一遍，为什么会有这种嗡嗡声？

底线

如果您关注 Web 开发领域，最近可能经常听到关于Deno 的消息——这是一个新的JavaScript 运行时，或许可以被视为 Node.js 的精神继承者。但它究竟意味着什么？我们需要“下一个 Node.js”吗？它究竟为何如此受关注？

Deno 是什么？

要理解 Deno 的真正含义，我们首先需要了解一下它到底是什么。正如我之前所说，它是一个新的 JavaScript 运行时，也就是一个执行 JS 代码的环境。它最初是由Ryan Dahl创建的——他之前也为我们带来了Node.js——因此才会被拿来与 Deno 进行比较。

Ryan 在2018 年 JSConf EU 大会上发表了题为“我对 Node.js 感到遗憾的十件事”的演讲，宣布了 Deno 的到来。仅从这部分内容就能看出 Deno 的未来发展方向。Deno 的开发初衷是为了更好地实现Node.js 的现状。

但是 Node.js 到底有什么不好，而 Deno 与它更成熟的兄弟相比又如何呢？

Node.js 比较

尽管 Deno 和 Node.js 是类似的工具，旨在做类似的事情，但它们之间的差异远不止名称的反转。

建筑学

让我们先来了解一下 Deno 的内部结构。与 Node.js 一样，它基于 Chromium 的V8 JavaScript 引擎，并使用事件驱动的非阻塞架构。然而，两者的主要编写语言有所不同。Node.js 主要使用C++ 语言，并使用libuv作为其异步 I/O 库，而 Deno 则使用Rust和Tokio。

这些差异如何转化为实际性能，我们还有待观察。目前，根据Deno 的基准测试，差异难以区分，或者充其量非常微妙。

ES 模块

您可能知道，Node.js 当前的模块系统是所谓的CommonJS（带有 的模块系统require()），尽管 JS 在这方面的官方标准已经是ESM（ECMAScript 模块，带有import和 的模块系统）很长一段时间了，可以追溯到 2015 年ES6export的推出。当然，Node.js 确实支持 ESM，但此功能目前（v14.xx）被标记为实验性的，迫使 JS 社区仍然使用其中一个（或捆绑器）。

这就是 Deno 的用武之地，它凭借 ESM 和仅 ESM 模块支持而大放异彩。终于——一个真正的全面模块系统！

依赖管理

但除了 ESM 之外，Deno 还为我们所知的 Node.js依赖管理带来了更多变化。

Deno借鉴了百万级NPM 软件包注册表和类似黑洞的node_modules目录的经验，采取了一种完全不同的依赖关系处理方法。Deno 不再使用类似 NPM 的注册表和包管理器，而是直接从 URL 导入和使用依赖项：

import { serve } from "https://deno.land/std@0.50.0/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" });
}

下载的模块会被存储在你电脑的某个地方，不被人发现。没错，以后node_modules再也不用了！

等等！还有更多……或者应该说更少，因为 Deno 也摆脱了现在万能的package.json文件。除了一个文件之外，没有其他成熟的替代方案deps.ts，它的作用更像是所有外部模块的重定向文件：

export { assert } from "https://deno.land/std@v0.39.0/testing/asserts.ts";
export { green, bold } from "https://deno.land/std@v0.39.0/fmt/colors.ts";

至于 NPM 注册表，由于 Deno 现在可以从 URL 加载依赖项，因此不像 Node.js 那样需要它。不过，如果你对这样的选项感兴趣， Deno 确实提供了自己的包托管服务。

TypeScript 和其他功能

是的，你没看错——TypeScript紧随JavaScript 之后，后者是 Deno 的主要语言。它内置了对 JavaScript 的支持，无需任何自定义寄存器或复杂的设置。

除了 TS 支持之外，Deno 还内置了许多其他实用工具。它们大多以不同的命令形式出现，例如fmt、bundle或 ，doc分别提供代码格式化、打包和文档生成等功能。

API

至于 API，Deno 无疑是自成一派的。所有内容均使用 TypeScript 编写，异步 API 完全基于Promises。核心功能被限制在最低限度，而其他所有内容都可以在标准库中找到。

所以，从理论上讲，一切都看起来非常好，前景光明，但当你意识到所有 API 的更改意味着将 Node.js 代码库转换为 Deno 会更加困难时，这种喜悦感就会立刻消失。可惜的是，一切新的、更好的东西都必须付出代价，不是吗？

安全

最后，Deno 最重要的方面之一是安全性。与 Node.js 相比，Deno 对执行的代码进行了沙盒处理，仅允许访问系统的选定部分。这意味着，通过传递适当的标志，可以轻松限制对磁盘、网络和子进程等内容的访问。

再说一遍，为什么会有这种嗡嗡声？

所以，我刚刚非常简要地向你描述了 Deno 的一些功能，以便你能够大致了解它的含义。正如我所说，关于这个主题已经有很多文章，如果你愿意，可以深入了解（我会在本文末尾链接一些不错的文章）。

但是，让我们暂时回到这篇博文的核心问题——为什么会引起如此大的关注？主要是因为Deno v1计划于2020 年 5 月 13 日发布（或者说已经发布，取决于你何时阅读本文），距离它首次发布正好两年。现在，每个人都在问，这是否会成为“下一个大事件”，或者它是否会完全取代 Node.js。

我个人认为现在下结论还为时过早。尽管该项目已经是 v1 版本，但考虑到其规模和社区的期望，它距离成为 Node.js 的可行替代品还有很长的路要走。请记住，这些技术（即使存在所有差异）仍然旨在做同一件事，并且必须相互竞争。事实上，Node.js 的开发也并不陈旧（例如基于 Promise 的 FS API变体或 ESM 实验性支持），这意味着我们很可能会在相当长的一段时间内生活在这个双重 JS 运行时的世界中（就好像它对 JS 开发者来说是什么新鲜事一样😅）。请记住，我甚至没有提到庞大的 NPM 注册表和生态系统，尽管它们并不完美，但仍然为 Node.js 增添了巨大的价值——这是 Deno 目前根本不具备的优势。

底线

所以，总结一下，Node.js 不会消失，如果你正在启动任何用于生产的严肃项目，那么坚持使用它很可能是更好的选择……至少目前如此。话虽如此，没有任何人（当然包括我）能够阻止你体验 Deno，甚至用它来开发严肃的项目。它看起来确实像是未来，但我们还没有真正进入。

感谢您阅读这篇文章！如果您喜欢，欢迎在Twitter、Facebook或 Dev.to 上关注我，获取更多最新内容。感谢您的关注！

Deno 资源：

• Deno 1.0
• Deno 手册：Deno 的简明介绍
• Deno 1.0：你需要知道什么
• 🎉 Deno：1.0 正式定于 5 月 13 日发布！功能回顾