大家好，这里是大家的林语冰。
《前端猫猫教》每日 9 点半更新，坚持阅读，自律打卡，每天一次，进步一点。
免责声明
本文属于是语冰的直男翻译了属于是，略有删改，仅供粉丝参考。英文原味版请传送 Deno vs. Node: No One is Ready for the Move。
关于 Deno 的现代设计举不胜举。但 Deno 能对人气最高的 JS 运行时环境 Node “降维打击”吗？
毋庸置疑，Node 是地球上人气最高且用户最多的 JS 运行时环境。但是，Deno 在 2018 的时候引发了一场轰动，开发者如今可以访问具有现代功能的、更安全的框架。
Deno 是由 “Node 之父” Ryan Dahl 引入的。Deno 号称 Node 的继承者，旨在修复 Node 中的某些主要设计缺陷。尽管如此，Deno 的发布引发了许多关于 Deno 是否会取代 Node 的猜测。到目前为止，这还没有任何重大变化。大多数开发者仍然对 Node 感到差强人意。
本期共享的是 —— 为什么 Deno 的采用变得十分缓慢，以及为什么大家仍然更青睐 Node。然后本人会尝试对 Node 和 Deno 进行比较。
Node 是什么鬼物？
Node 是一种人气爆棚的服务器端、开源、跨平台 JS 运行时环境，它基于谷歌的 V8 JS 引擎构建。自 2009 年以来，Node 一直在垄断 Web 开发世界。
Node 主要关注事件驱动（event-driven）的 HTTP 服务器。当涉及到处理请求时，Node 运行一个向系统注册的单线程事件循环，每个传入的请求都会触发一个 JS 回调函数。回调函数能够使用非阻塞 I/O 调用来处理请求。
此外，Node 还可以通过从线程池中生成线程，执行阻塞型或 CPU 密集型任务，从而在 CPU 核心之间分配负载。与大多数通过线程进行扩展的竞争对手框架不同，Node 回调函数筑基的扩展机制可以诉诸最少的内存占用，容纳更多的请求。
Node 是轻量级的，十分适合可扩展、数据密集型、实时 Web App，由于其异步 I/O 和事件驱动架构，这些 App 可以在分布式设备上运行。
Deno 是什么鬼物？
如上所述，Deno 是一个新型 JS 运行时，旨在解决 Node 的设计缺陷，并提供现代化的开发环境。根据“Node 之父”、同时也是“Deno 之父”的说法，Node 具有三大明显缺陷：
- 依赖集中分布、设计不佳的模块系统
- 遗留 API 不稳定
- 缺乏安全性
Deno 据说可以解决这三大缺陷，并提供更好的体验。
Deno 是一个 JS、TS 和 WebAssembly 运行时，具有安全默认值，除非明确启用，否则无法访问文件、网络或环境。Deno 基于 V8 JS 引擎、Rust 和 Tokio 构建。Deno 采用 Web 平台标准，它始终以单个可执行文件进行分发，并具有内置开发工具，提供高效、安全的运行时。Deno 有一组经过审查（audit）的标准模块，确保在 Deno 运行时正常运行。Deno 还支持原生 TS 文件执行，无需进一步配置。
Deno vs Node：主要区别
现在，我们瞄一下 Node vs Deno 之间的正面比较。
第三方包管理
使用 Deno，开发者可以直接从 URL 安装模块，而无需像 npm 这样的集中式注册表。尽管直接从 URL 下载包存在风险，举个栗子，如果托管模块的服务器遭遇裹挟，攻击者可以修改包含恶意功能的代码，Deno 提供了一种通过缓存下载的模块，从而缓解这种风险的方案。模块可以作为第三方库直接导入到脚本中。通过允许脚本从任何公共 URL 运行，Deno 消除了包管理器导入模块的必要性。虽然但是，从第三方导入模块仍然存在风险。package.json 文件和 node_modules 文件夹也被 Deno 删除了。
相比之下，Node 使用 npm 来处理所有包。Node 还拥有庞大的库和包生态系统。
Deno 的模块导入机制比 Node 更灵活，允许我们从任何地方导入代码，包括 GitHub 和我们托管的任何 CDN 或注册表。这使得无缝模块导入无需下载或安装。
API
Node 是在 JS 中引入 Promises 或 async/await 等概念之前诞生的。因此，大多数 API 都被设计为接收错误优先风格的回调函数（error-first callback）。这种方法经常会创建又臭又长的“代码屎山”。虽然 Node 开发者可以使用 async/await 语法，但它们还必须管理向后兼容性，因为 API 经常更改且不稳定。
在 Deno 中，情况完全不同。API 不需要封装在 async 函数中，因为 Deno 已经默认使用 await，并支持最新的 JS 功能。因此，Deno 通过为开发者简化这一过程，促进将 future-based 的 API 绑定到 JS Promise 中。Deno 还旨在与浏览器中运行的 JS 代码使用的 Web 平台 API 兼容。许多人气爆棚的高级 Web API，比如 fetch、Web Storage、Web Workers 和 Broadcast Channel 的支持方式都符合 Web 标准。
安全性
安全性是“Node 之父”孵化 Deno 的主要原因之一。
Deno 在禁止访问文件系统的安全沙箱环境中执行所有代码。Deno 在访问文件系统之前首先请求授权。
要获得许可，我们需要通过命令行参数来获取，这能防止未经开发者同意而删除任何文件。Deno 中的多个命令行标志可以在运行时使用，以便为特定脚本启用特定功能。默认情况下，这些功能处于非活动状态；我们必须为脚本可能需要的任何元素显式设置一个标志。
这些标志包括但不限于：
— allow-env：允许环境访问，从而进行诸如获取和设置环境变量之类的操作。— allow-hrtime：允许高分辨率时间测量。— allow-net：允许网络访问。— allow-read：允许文件系统读取访问。— allow-run：允许运行子进程。— allow-write：允许文件系统写访问。
Node 从不被认为是一个高度安全的框架。举个栗子，Node 不需要授予读取或写入文件系统的访问权限，并且它不是沙盒。因此，任何第三方库都可能因为一点疏忽而造成麻烦。此外，还有标准安全措施来防范 CSRF（跨站点请求伪造）和 XSS（跨站点脚本） 等对 Node 用户有利的威胁。这些机制涉及检查日志、正确管理错误和异常，以及验证用户输入。
因此，尽管已经习惯了安全模块的严格性，Deno 仍然是更安全环境的最佳选择。
TS 支持
TS 是 JS 的超集，使用户能够添加可选的静态类型。Deno 通过利用具有缓存技术的 TS 编译器，支持开箱即用的 TS。因此，Deno 可以编译、类型检查和执行我们的 TS 代码，而无需将其转换为 JS。
尽管 Node 缺乏像 Deno 一样固有的 TS 支持，但由于 TS 包人气爆棚，TS 在 Node 社区中成为了一种众所周知且广泛使用的语言。因此，TS 和 Node 可以轻松快速地运行。如果您已经安装了 Node 和 npm，那么只需运行 npm install -g typescript，即可在您的计算机上全局安装 TS。接下来，运行 tsc --init 创建 TS 配置文件。然后可以使用 TS 编译器 tsc 来编译 .ts 文件。
如果您喜欢 TS，并且更喜欢尝试新颖的框架，Deno 是合适的选择。此外，在 Deno 中使用 TS 进行开发不需要任何额外的配置。
为什么开发者青睐 Node 而不是 Deno？
在我们迄今为止介绍的所有内容中，很明显 Deno 为开发者提供了某些特殊功能，比如强大的支持系统和原生 TS 兼容性。设计策略和其他内置工具的目的旨在为开发者提供高效的运行时环境和积极的体验。
那么，为什么 Deno 还没有取代 Node？正如我们所看到的，相对于 Node，Deno 的采用速度确实很慢。尽管有一个新的现代框架解决了许多设计问题，但开发者仍然更青睐 Node 的原因有很多。
当 Node 最初发布时，我们中的某些“骨灰级玩家”开始使用它，并在实时 App 中使用它。多年来，为了满足软件开发社区的需求，Node 发生了沧桑巨变。Node 现在是使用最广泛的 JS 运行时。由于 Node 广泛使用，我们可以访问由高级开发者组成的一流社区。Node 包系统基于 npm 构建，内容广泛且易于处理。因此，当灵活性和亲密度是我们主要关注的问题时，Node 是最佳选择。
虽然但是，Node 绝非完美无缺，且实际上远非如此。Deno 在各个重要领域都卓有成效，而 Node 仍然落后，特别是在安全性和标准合规性方面。Deno 的单一二进制模式使其比 Node 更具可移植性，并且开放式模块架构可能会成为依赖导入的未来规范。
所以到底是什么阻止开发者切换赛道入坑 Deno？
尽管 Deno 的社区很活跃，但规模仍然很小。Deno 特定的模块十分罕见，并且 Node 兼容层并不总是可靠。如果我们想使用某个第三方库，或者需要求助社区，这可能会让我们处于不利地位。
Deno 的一个明显不足之处是缺乏第三方软件包，而且由于其不成熟，Deno 并没有像 Node 那样在现实世界中得到广泛使用。另一方面，Node 十分模块化。借助 Node 包管理器 npm，我们可以找到许多宝藏第三方库。Node 的人气爆棚主要是因为我们可以通过下载无数的软件包来打磨我们的作品。
此外，Deno 提供的许多功能都可以借助第三方库在 Node 中实现。因此，如果我们只喜欢 Deno 的某个方面，那么我们可能可以使用 Node 完成“图灵等价”的东东，尽管不如 Deno 丝滑。
在 Node 中使用权限的简单性是另一个重要功能。我们可以在平台上快速回收反馈，无需经过各种授权。Node 只需最少的努力即可快速编码，因为它很少请求特定权限。因此，Node 十分适合需要定期更新和大型专家团队的各种动态项目。
因此，考虑到这些因素，我想说大多数开发者对 Node 的发展方向感到差强人意，并且不太可能很快切换赛道入坑 Deno。
与庞大且元气满满的 Node 社区相比，Deno 仍处于乳臭未干的阶段。Deno 尚未在实际生产系统中经过彻底测试，开发者仍在适应这种新型运行时环境。当然，Deno 未来可期，因为它解决了 Node 的重大缺陷，包括但不限于安全性、模块、回调和中心化分发系统。目前，Deno 对于早期采用者来说主要是作为一种新奇事物而感兴趣。逐渐地，支持 Deno 的社区应该能够使其成为 Web 开发的必需品。
写在最后
在比较了 Deno 与 Node 的主要功能之后，我希望您现在可以认识到到 Deno 是一只“潜力股”，并理解为什么开发者采用 Deno 的速度很慢。Deno 无疑会继续吸引越来越多的关注，并且在我看来有着光明的未来。
但作为一名需要按时完成工作的软件开发者，我们知道 Node 最适合目前的开发需求。
本期话题是 —— 你认为 Deno 是一只潜力股吗，以及 Deno 可能在近未来取代 Node 吗？
欢迎在本文下方自由言论，文明共享。谢谢大家的点赞，掰掰~
《前端猫猫教》每日 9 点半更新，坚持阅读，自律打卡，每天一次，进步一点。
