地址:为什么我认为对于JavaScript运行时环境来说Deno是一个错误的方向。作者:梅胡尔·莫汉。发布时间:2020年5月14日。译者:hylerrix。备注:本文遵循freeCodeCamp的翻译标准，将收录在《Deno Study的艺术》的翻译中。 备注:公益组织freeCodeCamp.org自2014年成立以来，以“免费帮助人们学习编程”为使命，开设了大量免费编程教程，包括互动课程、视频课程、文章等。 线下开发者社区覆盖160多个国家和2000个城市。 FCC正在帮助全球数百万人学习编程，希望世界上的每一个人都有机会获得免费优质的编程教育资源，成为开发者或者开发者利用编程解决问题。 搜索微信微信官方账号“freeCodeCamp”了解更多信息。 译者在介绍第一篇为《德诺研究的艺术》翻译的文章时看到了这篇文章。当时他还觉得控制不住，就先专注写了几篇入门级的Deno文章。 转眼到了2021年，Deno双周刊第一期就要继续开启Deno的新年之旅了，所以我想，通过阅读这篇文章和相关文章，我可以从另一个角度了解Deno，然后翻译就开始了。 相比之前直接翻译文章，这篇文章有很多地方是我想做笔记的(甚至是“睁开眼睛”)。因此，我独辟蹊径地打开本文的“译者序”一章，梳理一下参考文献和相关视频对Deno的另一面说了些什么。 参考文献中提到，这注定是一篇有争议的文章。文中介绍的两段视频点击量略大于点赞量，评论区充斥着“热门”讨论，让你看到多种观点的碰撞。 参考文献中有一些过分的批评，但不妨碍下面的翻译逐一还原原作者的观点！所以，原作者Mehul很想说为什么Deno在参考文献和两个视频里不那么好？其观点总结如下:注:如果想先看参考文献，可以跳过阅读，稍后再看这个简单的总结。 Deno和Node确实是竞争关系，因为你要在你的下一个项目中做出选择。 Deno现在的成绩并不多，大部分功能在节点生态中都能很好的处理掉。 进口还是一场灾难。 NPM已经出现了很多问题，比如“只有一行代码”、“偷偷窃取客户数据”、“注入挖矿代码”、“很多上游库因为兼容性问题受到影响”。URL导入本身无法处理这些问题，也没有Node这样强大的社区来保证可信依赖库，所以不会有更多的开发者愿意加入Deno生态。 因为TypeScript是JavaScript的超集，所以完全可以选择跳过类型验证。这时候推荐新手直接在Deno上用TypeScript的空间就很大了，可能会出现一堆任意类型。 在频繁的调试错误下，TypeScript的学习成本也很高，很容易写出低质量的代码。 TypeScript不直接在Deno上运行，但实际上变成了JavaScript来运行。为什么一定要整合进Deno？安全是一件很难的事情，Deno推广他的“安全沙盒”注定要承担很大的责任。 Deno安全沙箱不是必须的，可以通过Docker或者虚拟化技术等容器来支持。 同时，真正想搞破坏的脚本也会自己想办法规避安全问题。 以目前版本的deno - allow-run为例，发现deno的“安全沙箱”并不像说的那样安全，可以轻松突破安全沙箱的验证获得更多权限。 Deno不需要集成太多工具链(代码格式化、测试工具、TypeScript等。)合二为一。让各种第三方工具链共同构建一个生态系统，同时保证Deno自身的专注，提供更友好的插件支持，会很好。 Node的异步模型没有被消除，promise和Event Listener模型也没有被消除，所以Deno如何处理这些没有被消除的问题是不确定的。 未来有多少开发者愿意将npm中的成熟库逐步迁移到Deno，这是不确定的。 可见，无论你是节点开发者还是Deno爱好者，这些观点都有很多值得思考的地方。 但是，也有一些偏差。比如本文把Deno描述成一种编程语言，把发展才两年多的Deno的生态直接和打造了十年的Node的生态做对比。德诺注定有自己独特的发展轨迹。 最后参考作者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/native script/ionic/甚至更多你能想到的相关库。 我也主要使用JavaScript作为语言，这使得我的Youtube频道和一个开发者平台拥有超过10万的订阅用户。 但重要的是，保持一个公正客观的视角来看待一笔交易的双方是很重要的。 Deno当然有好的一面，但也有另一面是大多数人还没见过/写过的。 让我们来看看！_注:这篇文章注定是一篇有争议的文章。 请保持礼貌的态度，先控制好自己的情绪。 如果你能仔细阅读全文直到最后，然后再告诉我你的想法，我将不胜感激。 _我会在这篇文章的底部列出我的社交账号，也希望我们能就这个话题有更多好的讨论。 Deno vs Node:名副其实的竞争关系很多业内人士都在说，“Deno和Node没有竞争关系，可以互相学习很多东西。” 在某种程度上，我同意这个观点。Node和Deno真的可以互相学习。 但是两者真的没有竞争吗？我完全不同意这种观点。 我们再来看看Deno和Node的共同特点:都是JavaScript的运行时环境；它们都可以在任何可以运行V8的电脑上运行；都是ECMAScript标准支持的；它们得到了积极的维护。 如果你是Deno两年的粉丝，没有Node是不可能直接用Deno作为新项目的技术选型的。 同样的，如果你之前没有用过TypeScript，并且认为你想尝试Deno，你将很难同时使用NPM生态系统中的各种模块。 所以:Deno和Node的开发者目前确实存在分歧——你必须做出选择。我想说，这是他们竞争关系的一个非常重要的例子。 德诺有什么好的？首先我需要列举一下德诺在宣传上的优势。Deno为什么说它是更好的运行时:它克服了Node的几个缺点；默认情况下，它是一个安全的运行时环境；它有内置的类型脚本支持；它把对承诺的支持下放到底层；它基于Rust语言(相对于C++ for Node)。 在接下来的章节中，我将重点介绍Deno的上述每个优点，看看Node可以从中学习到什么。 我也会在必要的时候讨论为什么Deno没有那么有意义。 德诺在哪里画蛇添足了？让我们开始挑选Deno的独特销售主张，并逐一进行分析:默认安全运行时环境。这是Deno里很受欢迎的功能，我很惊讶。 O Deno默认直接支持安全的沙盒环境，除非你明确选择开放对文件系统或网络的访问。 Deno这样做是因为它想离浏览器更近一些。 Deno符合ECMAScript标准是好的，但是你为什么那么热衷于先接近浏览器呢？也许答案是Deno希望在客户端和服务器端写的代码之间保持良好的兼容性。 但是Deno想支持浏览器想的那么强烈，我觉得方向有点偏，甚至有点过了。 虽然Node不支持“安全运行时”——但仔细考虑，我觉得支持Node也是有原因的:众所周知，你不应该在系统上运行不可信的代码和可执行文件。 这也是为什么我们总是选择Express这样的库做Node(而不是随便找一个号称比Express快100倍的库)。 信任来自于对社区的广泛使用 我不知道有哪种编程语言能提供像Deno这样的沙盒环境。 虽然这个功能可能不错，但似乎应该由Docker这样的容器环境来完成。 我相信一个配置良好的Docker环境比在沙盒Deno环境下运行不可信节点代码更能解决不可信文件的安全问题。 沙盒没有那么容易——虽然我不是网络安全方面的专家，但我认为功能越多，攻击面可能就越大。 Deno承诺提供一个安全的运行时环境，但是我想说安全很难做到。 德诺的承诺带来了巨大的安全责任。 世界上最大的企业每年需要向独立开发者和安全公司投资近数亿美元来支持他们的安全白帽计划。 那么，Deno会把他们的“安全环境”带到哪里去呢？时间会证明一切。 那么，Node能从Deno身上学到什么呢？我想说我不会学到很多东西。 或者节点许可可以引入少量竞争对手的安全环境标识，但意义不大。 如果你想在你的系统上运行一点未知代码，最好克隆一个C/C++仓库，运行make命令破坏系统。 译者注:上一段的最后一句话是“如果你在你的系统上随机运行仲裁代码，你还不如克隆一个C/C++ repo并在其上运行make命令，让你的整个系统编译。”，有些很难翻译，也不容易看出来为什么突然从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是宽容的。即使您可能会遇到一些错误，您也可以轻松地纠正它们。引用一句话，JavaScript可以快速编码，事情可以搞定。 对于新手来说，我很担心如果他们选择使用Deno(并且被要求使用TypeScript)，因为他们还不了解TypeScript，想在服务器上快速的运行一遍代码，我们可能会看到很多这样的代码:conshttpresponse:any = await getapresponse < any & gt；({myparams})//...const其他一些变量= something () as any//...any，any，anytypescript是JavaScript的超集。 你可以不自觉地写出一段质量很差的打字稿代码。仅仅使用TypeScript不会让你的项目完美无瑕。 直到你想起来可以用Node写TypeScript，这种体验才是真正有趣的。 我相信现在每个在生产环境中使用Node的大公司都引入了TypeScript来编写项目——没有例外。 当你解决了很多文件及其依赖关系，解决了很多代码，JavaScript真的很难扩展。 TypeScript是JavaScript生态系统中一个革命性的工具包，它更好地支持静态和动态语言。 因此，Deno宣布它将内置TypeScript支持。 但我想问，为什么一定要这样？的确，如果不是内置，可能需要引入Babel和Webpack来完成这项工作，但这不就是我们身边一堆第三方工具链构建生态系统的意义吗？我们不是要加强DX吗？译者注:DX，开发者体验，是开发者体验的缩写。 当软件或系统的客户是开发者时，开发者体验(DX)等同于用户体验设计(UX) JavaScript还是会是JavaScript，保持自己的风格。 另外，如果Deno真的可以直接运行TypeScript(或者类似于TypeScript的语言)，我觉得也不会有问题。 但实际上Deno只是把TypeScript代码转换成JavaScript代码运行。 从这些角度来看，Deno似乎是Node下各种工具的集成版，Deno同时包含了一个测试工具、一个代码格式化程序和一个TypeScript。 我更喜欢流线型的编程语言，在合适的时候自己添加各种插件——当然我不能代表所有开发者，这只是我的看法。 为什么我已经有了一个更漂亮的专注于代码格式化的库，还需要一个内置的代码格式化工具？为什么一定要处理一些本身就很好的事情呢？单一架构确实提供了许多工具，但它也确实很庞大，一个更加精简和集中的核心库可以更好地维护和扩展。 对比Promise和Node的支持去中心化，Deno v1的发布对我来说意义不大。 我非常尊重Node和Deno的创始人，但是Node有Deno没有的东西——全球众多经验丰富的开发者的支持。 Node由近3000名开发者贡献，是异步I/O事件解析的领导者。 Deno确实是基于Rust，并且透露出类似于Promise的一般性。 但是Node有C++，3000个开发人员，10多年的开发维护。 Node的异步模型没有被淘汰，promise和event listener模型也没有被淘汰，所以我不确定Deno会如何处理这些没有被淘汰的问题。 再见，npm。重要的是，迪诺不支持NPM。 Ryan(Node和Deno的创始人)正在为此推广Go语言的相关特性。 我来想几个包管理器:npm for JS(很明显)npm for JS(真的很详细)apt-get composer for PHPbrew for macos cargo for Rust(Deno是建立在Rust上的)。我认为不使用包管理器进行管理是糟糕的一步。 包管理器可以做很多事情:标记版本、编写脚本、管理依赖项等等。 Deno为什么不用npm？我不知道，但这些是我的想法:第一，因为Deno需要TypeScript生态，但后者生态更JavaScript。 更正:Deno也能跑。js归档很好。 其次，大量的npm模块需要使用文件/网络甚至更多的条件，而这些Deno非常严格，默认不提供这些权限。 所以你需要在package.json中注入很多冗余的“权限”字段来提供更多的权限。 然而...Deno不能和npm合作，所以没有package.json 接下来我们就来看看Deno是怎么解决模块系统的。 NPM模块数量极其庞大甚至臃肿，但这也是节点生态强大的生命力所在。 寻找一个库将tar文件的内容提取到stream中？你可以选择tar-steram 想要一个数据格式验证库？可以选择joi。 想和JWT一起工作吗？可以选择jsonwebtoken。 不知道开发者要多久才能让自己的各种库兼容Deno系统？Deno对模块化系统采取了完全不同的方法。 然而，Deno正试图以某种方式“修补”现有的NPM模块。 那么我看不出使用Deno有多大意义，除了试图在Docker容器中“黑掉”一个TS+Node项目。 根据我目前所知道的关于Deno的一切，这就是Deno现在的真面目:Deno =(大多数情况下)【TypeScript+Node+正确配置的Docker容器+单个可执行文件+<各种小工具>:-NPM】搞定！让我们冷静下来，然后听我的总结。 总之，我和其他人一样对Deno的出现感到兴奋。 但是当Deno准备完全重写JavaScript的时候，我的期望发生了变化。 我没有提到Deno的自动打字文档等许多好功能，因为我希望这篇文章旨在展示Deno的另一面。 由于Deno的优点几乎可以在任何其他Deno文章中找到，所以我需要再次强调硬币的两面。 坦率地说，Deno似乎为一些小利益承担了很大的责任和成本，包括转移现有NPM模块和代码库的许多债务。 你同意还是不同意我的观点？很期待你的想法。 也可以在Twitter @ mehlmpt或者Instagram联系我！祝你好运！全文翻译完后，请到@hylerrix/deno-tutorial仓库订购一颗星星或手表。 德诺研究的生态目前已经支持四个方向不同的仓库，并且正在持续建设中...deno-tutorial:核心仓库，电子书集中的地方，围绕deno整个生态的各类原创/翻译文章。 Deno-Feedly: Deno双周刊，中英文Deno趋势总结双周刊，2021元年。 Deno-algorithm:想在Deno上用TypeScript刷LeetCode算法？也许你可以看看这个(只是开源，刷完肯定题再宣传) Awesome-Deno-cn:见名知意，华人社区Deno资源全图，求PR 以及与德诺生态图书馆共建的ES-Interview(“ECMAScript+Interview Collection”)等更多电子书，请关注好人:Github @ hylerriximage。