关于javascript:为什么我认为-Deno-是一个迈向错误方向的-JavaScript-运行时

• 原文地址：Why I Believe Deno is a Step in the Wrong Direction for JavaScript Runtime Environments
• 原文作者：Mehul Mohan
• 原文公布工夫：2020-05-14
• 译者：hylerrix
• 备注：本文遵循 freeCodeCamp 翻译标准，同时本文会收录在《Deno 钻研之术》的翻译篇中。

译者序

在为《Deno 钻研之术》引入第一篇翻译文章的时候，就看到了这篇文章，那时还感觉驾驭不了，就重点先写了若干篇入门级别的 Deno 文章。

转瞬到 2021 年，从《Deno 双周刊》第一期持续开启新的一年的 Deno 之旅，于是就回想起了本文，感觉能够通过好好浏览本文及相干后，从另一个角度理解 Deno，翻译就开始了。

相比后面对文章的间接翻译外，本文有很多想要记笔记的中央（甚至“大开眼界”的中央），因而独特地开拓本文的“译者序”篇章，来梳理一下原文及其相干视频到底针对 Deno 的另一面，都讲了什么。

也正如原文所说，这注定是一篇有争议的文章，从文章中引入的两个视频中的点踩数都微微大于点赞数、其评论区都充斥着“炽热”的探讨就能看出多个观点的冲撞。原文也存在些适度批评的中央，然而不障碍下方译文开始后一比一地还原原作者想要表白的观点！

所以，原作者 Mehul 在原文以及两个视频中到底想要说 Deno 为什么没那么好？其观点大抵梳理如下：

留神：如果想先看原文的话能够跳过浏览并在之后来看这份简略的总结。

• Deno 和 Node 的确有 竞争关系，因为你必须在你的下个我的项目中作出抉择。
• Deno 当初所做的 成绩并不是很多，大多个性都能够在 Node 生态中较好地解决掉。
• URL import 还是一场劫难。NPM 中曾经有很多明星我的项目“居然只有一行代码”、“暗中偷窃用户数据”、“注入挖矿代码”、“兼容性呈现问题导致很多上游库受影响”等问题，URL import 自身并不能解决这些问题，更没有一个像 Node 一样强健的社区来保障受人信赖的依赖库，也就不会有更多的开发者违心退出到 Deno 生态中。
• 因为 TypeScript 是 JavaScript 的超集，齐全能够抉择跳过类型验证，此时举荐老手在 Deno 上间接应用 TypeScript 编程坑会很大，很可能会呈现一堆 any 类型。在经常性的调试报错下，TypeScript 的学习老本也较高，很容易写出低质量代码。
• TypeScript 并不是间接在 Deno 上跑的，其实还是变成了 JavaScript 来跑，何必肯定要集成到 Deno 中呢？
• 平安 是一个很难的事件，Deno 宣传本人的“平安沙箱”注定要承当很大的责任。Deno 平安沙箱也没有必要，齐全能够用 Docker 等容器或虚拟化技术来反对。同时，真正想搞破坏的脚本也会找到本人的形式来躲避平安问题。
• 以过后版本下的 deno --allow-run 运行主过程从而开启的子过程能轻松冲破平安沙箱的验证来取得更多权限为例，发现 Deno 的“平安沙箱”并没有所说的那么平安。
• Deno 没有必要 集成太多工具链（代码格式化、测试工具、TypeScript 等等）于一体，让各种第三方工具链来一起共建生态的同时，保障 Deno 自身的专一性并提供更敌对的插件反对会很好。
• Node 的异步模型 并没有被淘汰，promise 和事件侦听器模型也没有套题，因而不确定 Deno 将如何解决这些没有被淘汰的问题。
• 将来并不确定会有多少开发者违心将 npm 中的成熟库逐步 迁徙到 Deno 中。

能够看出，无论你是 Node 开发者还是 Deno 爱好者，这些观点都有很多值得思考的中央。但也有有失偏颇的中央，比方文中将 Deno 阐明为编程语言，也将 Deno 只倒退了两年多的生态间接和建设了十年的 Node 生态作横向比照——Deno 注定会有本人独特的倒退轨迹。

最初，原文作者 Mehul 总结了他眼中的 Deno v1.0 的实在风貌：

Deno = (大多数状况下)[TypeScript + Node + 正确配置的 Docker 容器 + 繁多可执行程序 + < 各种各样的小工具 > – NPM]

译文开始

目前，我还没有在 Youtube 上找到任何一个像 codedamn 一样的频道（超过 10 万名开发者订阅），其对 Deno v1 版本的公布并不感到兴奋。

上周，我在我的频道上公布了一个视频，介绍了一些“为什么我认为咱们不须要 Deno——另一个基于 V8 和 Node 的 JavaScript 运行时”的起因，这些起因对我来说都很简明扼要。

同时通过本文，我能够在视频外拓展论述更多的起因。但如果你想先看视频，能够看看这个：

为什么 Deno 将会失败 —— Node.js v/s Deno 之我的观点

为了证实我总体上并不是拥护 Deno 甚至 JavaScript 自身，我想申明一下：我喜爱 JavaScript 胜过于很多其它的编程技术。我的次要技术栈也只围绕着 JavaScript 开展——Node/React/MongoDB/React Native/NativeScript/Ionic/ 甚至你能想到的更多相干库。

我也是次要用 JavaScript 这一门语言，就让我的 Youtube 频道及一个开发者平台的订阅人数达到了 10 万多人。

但重要的事件在于，放弃偏心主观的角度来看到一个事务的两面性很重要。Deno 当然有好的一面，但也有大多数人尚未看到 / 写文探讨的另一面。一起来看看吧！
_
留神：_本文注定会是一个有争议性的文章。请先让咱们放弃礼貌的态度并管制好本人的情绪。如果你能仔细阅读全文直到结尾，而后再说说你的更多想法，那我会备受感谢。_
_
本文底部我会列出我的社交账号，也心愿咱们能在哪里针对此主题进行更多的良好探讨。

Deno vs Node：货真价实的竞争关系

有很多业内人士都在说：“Deno 和 Node 之间没有任何竞争关系，彼此之间能够学到很多货色”。

在某种程度上，我批准这个认识，Node 和 Deno 的确能够互相学习。然而两者间真的没有竞争关系了吗？我齐全不批准这关观点。

让咱们从新看一下 Deno 和 Node 的独特特色：

1. 它们都是 JavaScript 的运行时环境；
2. 它们都能够在能够运行 V8 的任何计算机上运行；
3. 它们都有 ECMAScript 规范反对；
4. 它们都在被踊跃的保护中。

如果你这两年都是 Deno 的粉丝，这两年里不抉择 Node 而间接用 Deno 作为新我的项目的技术选型是不可能的。

同理，如果你以前从未应用过 TypeScript，并且认为本人想要尝试 Deno，此时你会很难同时用上 NPM 生态中的各种模块。

所以：Deno 和 Node 的开发人员目前的确存在一致——你必须做抉择，我想说这是两者为竞争关系的一个很重要的例子。

Deno 到底好在哪里？

首先，我须要列举一下 Deno 对本人的宣传中的那些劣势，Deno 为什么说本人是更好的运行时：

1. 它克服了 Node 的一些毛病；
2. 它在默认状况下是一个平安的运行时环境；
3. 它内置 TypeScript 反对；
4. 它将 Promise 的反对下放到底层；
5. 它基于 Rust 语言构建（比照与 C++ 之于 Node）。

在接下来的章节中，我将一个一个针对下面的每一个属于 Deno 的长处，来看看 Node 能够从中学到什么。我也将会在必要之时探讨，为什么 Deno 还没有那么有意义。

Deno 画龙点睛在了哪些地方？

让咱们开始拿起 Deno 的独特宣传点（USP，Unique Selling Proposition）并将它们一一解析：

默认平安的运行时环境

这是 Deno 里很受欢迎的个性，我很惊喜。Deno 间接默认反对一个平安的沙箱环境，除非你明确的抉择开启拜访文件系统或拜访网络等性能权限。

Deno 这样做是因为它想更加地贴近浏览器。Deno 恪守 ECMAScript 规范这点很不错，但为什么如此热衷于率先贴近浏览器？

或者答案是，Deno 想要放弃在客户端和服务端上编写的代码之间有良好的兼容性。但 Deno 如此强烈的想要反对浏览器以至于我感觉方向有些偏失、甚至有些过头了。

Node 虽不反对“平安的运行时”——但通过三思而行后，我感觉也有理由反对 Node：

1. 家喻户晓，你不应该在零碎上运行不受信赖的代码和可执行文件。这就是咱们总是抉择像 Express 库之于 Node 的起因（而不是轻易找个宣称本人速度比 Express 快 100 倍的库）。信赖来自于社区的大量应用。
2. 我不晓得有任何编程语言像 Deno 这样提供如此的沙箱环境。只管这个性能可能不错，但仿佛应该交由诸如 Docker 这类的容器环境来实现。我置信一个被良好配置的 Docker 环境，相比在沙箱化的 Deno 环境中运行不受信赖的 Node 代码来说，能更好的解决不受信赖文件的安全性问题。
3. 沙箱化并没那么容易——我尽管不是网络安全专家，但我感觉某些性能越多，攻击面就可能越大。Deno 承诺提供平安的运行时环境，但我想说平安很难实现。Deno 的承诺带来了微小的平安责任。世界上最大的企业们为反对它们的平安白帽打算，须要每年为独立开发者和平安公司投入将近数亿美金。因而，Deno 到底会将它们的“平安环境”带向何方？工夫会证实所有。

所以，Node 能够从 Deno 中学到什么？我想说不会学到太多。Node 或者能够从竞争对手能够引入一些平安环境的标识，然而没有太多意义。如果你想在你的零碎上随便运行一些未知代码，则最好克隆一个 C/C++ 仓库并运行 make 命令侵害零碎。

译者注：上段最初一句话是“If you randomly run arbitrary code on your systems, you might as well clone a C/C++ repo and run a make command over it and get your whole system compromised.”，有些难以翻译，也不容易看出为什么从 Node/Deno 忽然跑到了 C/C++，欢送交换。

据我所知，你不能在像 C/C++ 这样的底层语言上来“沙盒化”文件系统或网络拜访——这样效率并不高。

留神：最近我发现启用 --allow-run 标记的 Deno 简直能够实现任何操作。该视频具体介绍了相干内容：

冲破 Deno 的平安沙箱——Deno 并不平安

内置反对 TypeScript

为 TypeScript 现阶段的停顿欢呼，我很快乐 Deno 开箱即用地反对 TypeScript。

注:  感激 @lilasquared 指出 Deno 也能开箱即用地运行 .js 文件。本文重点强调应用 .ts 文件编写代码。Deno 当然能够间接运行 .js 文件。

然而，让咱们退一步来说：你晓得为什么 JavaScript 和 Node 在寰球领有数以万计的开发人员吗？因为进入这个畛域的壁垒简直为零。JavaScript 是灵便的，能够答应你的诸多谬误。而 TypeScript 总会给你一些奇怪的谬误。

对于生产级的应用程序来说就蹩脚了：生产环境上可不须要这些时尚的货色。同时对于学习者来说，JavaScript 是宽容的，纵使你可能会遇到一些 Bug，但也能够很轻松的改过，援用一句话，JavaScript 能够被疾速编码并将事件搞定。

对于初学者来说，我放心他们如果抉择应用 Deno（并被要求应用 TypeScript），因为他们还不理解 TypeScript，想着疾速在服务端上跑通代码，咱们可能会看到很多这种的代码：

const httpResponse: any = await getAPIResponse<any>({myParams})
// ...
const someOtherVariable = something() as any
// ...
any, any, any

TypeScript 是 JavaScript 的超集。你齐全能够有意识间写一段品质很差的 TypeScript 代码，仅仅应用 TypeScript 并不会让你的我的项目无懈可击。

直到你想起来原本就能在 Node 中写 TypeScript 之前，这种体验的确很乏味。我置信当初每个在生产环境中应用 Node 的大型公司都引入了 TypeScript 来编写我的项目——没有例外。当你解决诸多文件及其依赖关系、解决大量代码时，JavaScript 真的很难拓展。

TypeScript 是 JavaScript 生态系统中革命性的工具包，更好地同时反对了动态和动静语言。

因而 Deno 申明本人会内置 TypeScript 反对。但我想问为什么肯定要这样？的确，如果不内置的话，可能须要额定引入 Babel 和 Webpack 来实现这项工作，但这不是一堆第三方工具链围绕身边来共建生态的重要意义吗？咱们难道不想加强 DX 吗？

译者注：DX，开发人员体验，是 Developer Experience 的简称。当软件或零碎的用户是开发人员时，开发人员体验（DX）就相当于用户体验（UX, User experience design）。

JavaScript 仍然还会是 JavaScript，放弃本身的格调。况且，如果 Deno 真的能间接运行 TypeScript（或相似于 TypeScript 的语言），我感觉没什么问题。但事实上，Deno 其实也只是将 TypeScript 代码转换为 JavaScript 代码，并运行它罢了。

从这些角度能看出，Deno 仿佛是一个 Node 下各种工具的的集成版本，Deno 将一个测试工具、一个代码格式化程序和 TypeScript 等一次性的包含进来。我更喜爱一个精简的编程语言并在适合的时候由我本人增加各种插件——当然，我不能代表所有开发人员，这也只是我的观点。

为什么我会在曾经有专一于代码格式化的 prettier 库的状况下，仍然须要领一个内置的代码格式化工具？为什么要解决这种自身就做的不错的货色？

单体架构的确集中起来提供了很多工具，但它也真的很宏大，一个更精简和专一的外围库能力更好的保护和拓展。

Promise 的反对下放到底层

和 Node 作为比照，Deno v1 的公布对我来说看不出太多的意义。我十分尊重 Node 和 Deno 的创建者，然而 Node 领有一些 Deno 所没有的货色——世界各地泛滥经验丰富的开发人员的反对。

Node 由近 3000 位开发者贡献力量，并且是异步 I/O 事件处理的引领者。Deno 的确建设在 Rust 之上，并公开了相似 Promise 的的形象。然而 Node 有 C++，有 3000 名开发人员以及 10 年以上的开发和保护。

Node 的异步模型并没有被淘汰，promise 和事件侦听器模型也没有被淘汰，因而我不确定 Deno 将如何解决这些并没被淘汰的问题。

再见了，npm

很重要的事件是：Deno 并不反对 NPM。Ryan（Node 和 Deno 的创建者）在为此推广 Go 语言的相干个性。让我想到一些包管理器：

1. npm for JS (obviously)
2. npm 之于 JS（真很明细）
3. apt-get
4. composer 之于 PHP
5. brew 之于 macOS
6. cargo 之于 Rust（Deno 正是基于 Rust 构建)

我认为不应用包管理器来治理是很不好的一步。包管理器能做的太多了：表明版本、编写脚本、治理依赖关系等等。为什么 Deno 不应用 npm 呢？我并不分明，但这些是我想到的：

1. 首先，因为 Deno 须要 TypeScript 生态，然而后者生态更多的是 JavaScript 的。更正：Deno 也能良好的运行 .js 文件。
2. 其次，大量 npm 模块须要要求应用到文件 / 网络甚至更多的条件，而这些 Deno 都很严格的默认不提供这些权限了。所以你须要在 package.json 里注入大量颇许冗余的“permissions”字段来提供更多权限。然而 …Deno 无奈和 npm 互相配合，因而也没有 package.json。接下来咱们会来看看 Deno 到底如何解决模块零碎的。
3. NPM 模块数量及其宏大甚至臃肿，但这也是 Node 生态的弱小生命力所在。想要找一个库来将 tar 文件内容提取到 stream 流中？你能够抉择 tar-steram。想要一个数据格式验证库？你能够抉择 joi。想要配合 JWT 协同应用？你能够抉择 jsonwebtoken。我狐疑得有多久能力让开发者们将他们的各种库变得兼容 Deno 零碎？

Deno 对模块零碎采纳了一种齐全不同的办法。但无论如何，Deno 在尝试以某种形式“修补”现有的 NPM 模块。那么除了尝试在 Docker 容器中“入侵”（hacking around）一个 TS + Node 我的项目外，我看不到太多应用 Deno 的意义。

依据我目前所理解的无关 Deno 的所有，这是 Deno 当初的实在风貌：

Deno = (大多数状况下)[TypeScript + Node + 正确配置的 Docker 容器 + 繁多可执行程序 + < 各种各样的小工具 > – NPM]

搞定！让咱们沉着一下，而后听我一下的总结。

总结

我和其它人对 Deno 的呈现一样感到兴奋。但当 Deno 筹备齐全重写 JavaScript 运行时时，我的冀望便有所变动。

Deno 的自动化 TypeScript 文档等诸多不错的个性我没有提到，是因为我心愿这篇文章旨在展现 Deno 的另一面。因为 Deno 的长处简直能够再任何其余 Deno 的文章中找到，所以我须要再次强调硬币的两面性。

坦率来说，Deno 看起来为了一些很小的好处承当了微小的责任和代价，包含转移现有的 NPM 模块和代码库的诸多债权。你批准还是不批准我的这些观点呢？我很期待你的想法。推特分割我 @mehulmpt 或 Instagram 也能够！

祝好！

全文译完，欢送返回 @hylerrix/deno-tutorial 仓库点个 star 或 watch。

《Deno 钻研之术》生态现已反对四大方向的不同仓库，继续共建中 …

• deno-tutorial：外围仓库，电子书集中地，围绕 Deno 全生态的各种原创 / 翻译文章。
• deno-feedly：Deno 双周刊，中英双语每两周地汇总 Deno 动静，2021 开年之作。
• deno-algorithm：想在 Deno 上用 TypeScript 刷 LeetCode 算法？或者能够看看这个（才开源不久，刷肯定的题后再宣传）。
• awesome-deno-cn：见名知意，中文社区下的 Deno 资源全图谱，求 PR。

以及更多应用 Deno 生态库构建的电子书如 es-interview（《ECMAScript+ 面试宝典》）等，尽请 follow 好家伙：Github@hylerrix