为什么我认为Deno是一个错误方向的JavaScript运行时？

原文地址：WhyIBelieveDenoisaStepintheWrongDirectionforJavaScriptRuntimeEnvironments原作者：MehulMohan原文发布时间：2020-05-14译者：hylerrix收录《Deno 钻研之术》的翻译。译者序在为《Deno 钻研之术》介绍第一篇翻译文章的时候，看到了这篇文章。当时还是觉得自己驾驭不了，就重点写了几篇入门级的Deno文章。一转眼2021年，从《Deno 双周刊》第一期开始，开始新的一年Deno之旅，于是回忆起这篇文章，觉得看完这篇文章和相关文章，可以从中理解Deno另一个角度，翻译开始了。这篇文章相比于之前直接翻译的文章，有很多我想记下的地方（甚至是“开眼界”的地方），所以我独辟蹊径地打开了本文的“译者序”一章来整理一下原文及其译文。相关视频针对的是Deno的另一面，他们在说什么。正如原文所说，这注定是一篇有争议的文章。文中介绍的两个视频点赞数略大于点赞数，评论区更是“火爆”讨论。多种观点的冲突。原文中也有一些过激的批评，但不妨碍下面的翻译一一还原原作者的观点！那么，在原文和两个视频中，原作者Mehul想说的是为什么Deno没有那么好？其观点大致概括如下：注：如果想先看原文，可以跳过阅读，稍后阅读这个简单的总结。Deno和Node确实存在竞争，因为你必须在下一个项目中做出选择。现在Deno取得的成果并不多，大部分特性在Node生态中可以得到更好的解决。URL导入仍然是一场灾难。NPM中已经有很多明星项目，比如“只有一行代码”、“偷偷窃取用户数据”、“注入挖矿代码”、“兼容性问题导致很多上游库受到影响”等，URLimport本身不能解决这些问题的问题是，如果没有像Node这样强大的社区来保证可信的依赖库，就不会有更多的开发者愿意加入Deno生态。由于TypeScript是JavaScript的超集，您可以选择跳过类型验证。这时候建议新手在Deno上直接使用TypeScript，这样会造成很多编程坑，而且可能会有一堆any类型。在频繁的调试报错下，TypeScript的学习成本也很高，很容易写出低质量的代码。TypeScript并没有直接在Deno上运行，而是实际上变成了JavaScript来运行。为什么必须将它集成到Deno中？安全是一件很难的事情，而Deno推广自己的“安全沙箱”注定要承担很多责任。Deno安全沙箱也不是必需的，它可以通过容器或Docker等虚拟化技术来支持。同时，真正想要造成破坏的脚本会找到自己的方法来规避安全问题。以当前版本的deno--allow-run运行主进程，使得开启的子进程可以轻松突破安全沙箱的验证获取更多权限为例。发现Deno的“安全沙箱”并没有说的那么安全。Deno不需要将太多的工具链（代码格式化、测试工具、TypeScript等）整合为一个，让各种第三方工具链共同构建生态，同时保证Deno自身的专注，提供更友好的插件支持会很棒。Node的异步模型并没有死，承诺和事件侦听器模型也没有死，所以不确定Deno将如何解决那些没有死的问题。未来，不确定有多少开发者愿意逐步将npm中的成熟库迁移到Deno。可见无论你是Node开发者还是Deno爱好者，在这些角度上都有很多值得思考的地方。但也有偏颇的地方。比如文中将Deno描述为一种编程语言，将Deno的生态仅仅发展了两年多，直接拿来和已经搭建了十年的Node生态进行比较。Deno注定会有自己独特的发展。追踪。最后，原文作者Mehul总结了Denov1.0在他眼中的真实面貌：Deno=（在大多数情况下）[TypeScript+Node+正确配置的Docker容器+单个可执行程序+<各种小工具>-NPM]翻译开始到目前为止，我还没有在Youtube上找到像codedamn这样的频道（超过100,000名开发者订阅），这对Denov1版本的发布并不兴奋。上周我在我的频道上发布了一个视频，其中包含一些“为什么我认为我们不需要Deno——又一个基于V8和Node的JavaScript运行时”的理由，这些理由对我来说非常简洁。同时，通过这篇文章，我可以扩展和解释更多视频之外的原因。但如果您想先观看视频，请查看：为什么Deno会失败——我对Node.js的看法。与许多其他编程技术相比，我更喜欢JavaScript。我的主要技术栈也只围绕JavaScript——Node/React/MongoDB/ReactNative/NativeScript/Ionic/任何你能想到的。我也主要使用JavaScript作为一种语言，所以我在我的Youtube频道和一个开发者平台上已经有超过100,000名订阅者。但重要的是，重要的是要保持公正客观的眼光看待交易的两个方面。Deno当然有好的一面，但也有大多数人还没有看到/写过的一面。一起来看看吧！_注意：_这篇文章注定是一篇有争议的文章。请让我们首先保持礼貌并控制我们的情绪。如果您能通读全文然后分享更多您的想法，我将不胜感激。__我会在这篇文章的底部列出我的社交账户，希望我们可以就这个话题进行更多好的讨论。DenovsNode：名副其实的竞争业内有很多人说：“Deno和Node之间没有竞争，有很多东西可以相互学习”。在某种程度上，我同意这种观点，Node和Deno确实可以相互学习。但两者之间真的没有竞争吗？我完全不同意这个观点。让我们重新回顾一下Deno和Node的共同特点：它们都是JavaScript运行环境；两者都可以在任何可以运行V8的计算机上运行；两者都有ECMAScript标准支持；两者都得到积极维护。如果你这两年一直是Deno的粉丝，那么这两年不选择Node就直接把Deno作为新项目的技术选型是不可能的。同理，如果你之前没有用过TypeScript，想试试Deno，你也很难同时使用NPM生态中的各种模块。所以：Deno和Node开发人员现在确实存在分歧——你必须做出选择，我想说这是竞争关系的一个很好的例子。Deno有什么好？首先，我需要列举一下Deno自我推销的优点，为什么Deno说自己是一个更好的runtime：它克服了Node的一些缺点；默认情况下，它是一个安全的运行时环境；它具有内置的TypeScript支持；它将Promise支持降到底部；它基于Rust语言构建（将C++与Node进行比较）。在接下来的章节中，我将一一阐述Deno的上述每一个优点，看看Node可以从中学到什么。必要时，我还将探讨为什么Deno还没有意义。Deno多余的地方在哪里？让我们从Deno的独特销售主张（USP，UniqueSellingProposition）开始，一一剖析：默认情况下安全的运行时环境这是Deno中非常受欢迎的一个特性，让我感到惊喜。默认情况下，Deno直接支持安全沙箱环境，除非您明确选择启用对文件系统的访问或对网络的访问。Deno这样做是因为它想更靠近浏览器。很高兴Deno遵守ECMAScript标准，但为什么它如此热衷于成为第一个接近浏览器的人呢？也许答案是Deno希望在客户端和服务器上编写的代码之间保持良好的兼容性。但Deno如此强烈地支持浏览器，以至于我认为它有点偏离，甚至有点过分。Node不支持“安全运行时”——但经过深思熟虑，我认为也有支持Node的理由：众所周知，您不应该在系统上运行不受信任的代码和可执行文件。这就是为什么我们总是为Node选择像Express这样的库（而不是仅仅寻找一个声称比Express快100倍的库）。信任来自社区的大量使用。我不知道有哪一种编程语言能提供像Deno这样的沙箱环境。虽然这个功能可能不错，但它似乎应该留给像Docker这样的容器环境。我相信配置良好的Docker环境可以比在沙盒Deno环境中运行不受信任的Node代码更好地处理不受信任的文件安全性。沙盒并不是那么容易——我不是网络安全专家，但我觉得功能越多，攻击面可能就越大。Deno承诺提供安全的运行时环境，但我想说安全性很难实现。Deno的承诺带来了巨大的安全责任。世界上最大的公司每年在独立开发人员和安全公司身上花费??数亿，以支持他们的安全白帽计划。那么Deno究竟会将他们的“安全环境”带到哪里呢？时间会证明一切。那么，Node可以向Deno学习什么？我会说不会学到太多东西。Node或许可以引入一些竞争对手的安全环境标识，但意义不大。如果你想在你的系统上随机运行一些未知代码，最好克隆一个C/C++存储库并运行make命令来破坏系统。译者注：上一段的最后一句话是“如果你在你的系统上随机运行任意代码，你还不如克隆一个C/C++存储库并在其上运行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，并且想快速跑完服务器端的代码，我们可能会看到很多代码像这样：consthttpResponse:any=awaitgetAPIResponse({myParams})//...constsomeOtherVariable=something()asany//...any,any,anyTypeScript是JavaScript的超集。您可能会在不知不觉中编写出质量低劣的TypeScript代码，仅使用TypeScript并不能使您的项目无懈可击。这是一次非常有趣的体验，直到您记起无论如何您都可以在Node中编写TypeScript。我相信今天在生产中使用Node的每个大公司都引入了TypeScript来编写项目——没有例外。当你处理大量文件及其依赖项，处理大量代码时，JavaScript真的很难扩展。TypeScript是JavaScript生态系统中的革命性工具包，更好地支持静态和动态语言。因此Deno声明它将内置TypeScript支持。但是我想问为什么一定要这样呢？确实，如果不内置，可能还需要额外引入Babel和Webpack来完成这项工作，但这不就是周围一堆第三方工具链搭建生态的意义吗？我们不想增强DX吗？译者注：DX，developerexperience，是DeveloperExperience的缩写。当软件或系统的使用者是开发者时，开发者体验（DX）就等同于用户体验（UX，Userexperiencedesign）。JavaScript在风格上仍将是JavaScript。此外，如果Deno真的可以直接运行TypeScript（或类似于TypeScript的语言），我认为这不是问题。但实际上，Deno实际上只是将TypeScript代码转换为JavaScript代码并运行它。从这些角度可以看出，Deno似乎是Node.js下各种工具的集成版本。Deno同时包括一个测试工具、一个代码格式化程序和TypeScript。我更喜欢精简的编程语言，并在适当的时候自己添加各种插件——当然，我不能代表所有开发人员，这只是我的看法。既然已经有专注于代码格式化的prettier库，为什么我还需要一个内置的代码格式化工具？为什么要解决本身已经做得很好的事情？单体架构确实以集中的方式提供了很多工具，但它也确实非常庞大。可以更好地维护和扩展更精简和专注的核心库。Promise支持分散到底层。与Node相比，Denov1的发布对我来说意义不大。我非常尊重Node和Deno的创造者，但Node拥有Deno所没有的东西——全球许多经验丰富的开发人员的支持。Node有近3000名开发人员做出贡献，是异步I/O事件处理领域的领导者。Deno确实建立在Rust之上，并公开了类似Promise的抽象。但是Node有C++、3000名开发人员和10多年的开发和维护。Node的异步模型并没有死，承诺和事件侦听器模型也没有死，所以我不确定Deno将如何解决这些问题。再见，npm重要的事情：Deno不支持NPM。Ryan（Node和Deno的创始人）为此正在推广Go语言的相关特性。让我想起了一些包管理器：npmforJS（很明显）npmforJS（非常详细）apt-getcomposerforPHPbrewformacOScargoforRust（Deno是基于Rust构建的）我不认为使用包管理器这是一个非常糟糕的步骤来管理。包管理器可以做很多事情：版本控制、脚本、管理依赖项等等。为什么Deno不使用npm？我不知道，但我想到了这些：首先，因为Deno需要一个TypeScript生态系统，但后者的生态系统更多的是JavaScript。更正：Deno也可以正常运行.js文件。其次，大量的npm模块需要使用文件/网络甚至更多的条件，而这些Deno非常严格，默认不提供这些权限。所以你需要在package.json中注入很多冗余的“权限”字段来提供更多的权限。然而...Deno不能很好地与npm配合使用，因此没有package.json。接下来我们来看看Deno如何处理模块系统。NPM模块的数量极其庞大甚至臃肿，但这也是Node生态强大生命力所在。寻找一个库来提取tar文件内容以进行流式传输？你可以选择tar-steram。想要一个数据格式验证库？你可以选择joi。想和JWT一起使用吗？您可以选择jsonwebtoken。我想知道开发人员需要多长时间才能使他们的各种库与Deno系统兼容？Deno对模块系统采用了完全不同的方法。但无论如何，Deno正试图以某种方式“修补”现有的NPM模块。因此，除了尝试在Docker容器中“绕过”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仓库点个星或观看。《Deno 钻研之术》生态现在支持四个方向的不同仓库，持续共建...deno-tutorial：核心仓库，电子书合集，以及围绕整个Deno生态的各种原创/翻译文章。deno-feedly：Deno双周刊，中英文双语，每两周总结一次Deno动态，2021年初。deno-algorithm：想在Deno上用TypeScript刷LeetCode算法？或许你可以看看这个（只是开源，经过一定的提问量后会公示）。awesome-deno-cn：见名知义，中文社区下Deno资源全图，欢迎PR。还有更多使用Deno生态库搭建的es-interview(《ECMAScript+ 面试宝典》)等电子书，请关注好人：Github@hylerrix