👏🏾 👵🏼 ☸️ 5对德诺的要求 🖕🏽 🤾🏿 🤓

前言

我不是地名小组的成员。我不是他的粉丝。我没有跟着他。我什至不真正相信他。但是看到社区的负面反应，我忍不住干预了。在本文中，我想考虑针对Deno的最常见主张，并提出另一种观点。

Deno-NodeJ的杀手er

这不是真的。这样，仅由“见证人”，疯狂的粉丝或渴望炒作的翻译人员来推广。据我所知，甚至Ryan Dahl本人（Deno的作者）也没有将他的发展定位为NodeJ的替代品或替代品。相反，他的愿景是“将来可能会使用相同的NodeJ”。如果需要，可以使用这个概念（由于现代现实中不切实际，我们不会责骂汽车或智能手机的概念）。从Ryan的角度来看，NodeJ存在一些问题。他向社区展示了如何解决这些问题的某种想法。您可以参加。立即来到GitHub，描述您所看到的架构问题。讨论他们。提出解决方案。

我认为Deno不会取代NodeJ。但是对于他来说，变成JavaScript的TypeScript变成了可能。

通过URL导入

许多人从错误的角度看待它。想法是删除整个项目的全局依赖项列表。因此，在每个模块/文件中都有一个自己独立的依赖性列表，而不是一个大的package.json。我看到了几个好处。

如果需要编写某些功能，则无需查看项目中已经使用了哪些依赖项。您不仅限于它们。您使用所需的东西。
您可以添加功能而无需考虑遗留问题。新模块将具有自己的依赖性，而旧模块将具有自己的依赖性。
在将大型项目迁移到某些依赖关系的新版本的过程中，您可以更改代码库并分批进行这些更改。

但是对于这种方法，您需要能够描述每个模块的依赖性。名称，版本以及获取此依赖项的位置。结果，使用URL导入。这甚至不是Deno的想法。这是标准的一部分。只是每个人都习惯于照常工作。但这不是唯一的方法。

但是，现在没有互联网怎么办？

就像您将使用NodeJ一样。天哪，NodeJs将依赖项下载到一个单独的目录中。仅在NodeJs中会启动它npm install，而Deno 在首次启动时会自动执行。

听起来很有趣，但我拒绝！

没问题。有这样的东西- 导入地图。迪诺支持他，尽管还不够。因此，您可以通过使用Analog来描述所有依赖项的同义词package.json。但是您将不仅限于此：

各个模块仍可以使用其自己的依赖项版本，并根据需要忽略导入映射。
导入映射规范建议可以指定多个下载源。Deno当前不支持此功能。但是从技术上讲，这是可能的。您可以指出多个来源，如果其中一个不可用，则将从另一个下载依赖。
```
{
   "imports": {
      "moment/": [
         "https://deno.land/x/moment/",
         "https://raw.githubusercontent.com/lisniuse/deno_moment/master/"
      ]
   }
}
```

没有npm，我将无法在全球范围内交付控制台实用程序！

好吧，实际上您可以。deno install这是一个模拟npm install --global。Deno下载，将所需的库编译为二进制文件，然后将其全局保存。不同之处在于，您必须授予图书馆某种许可。也就是说，在未经您同意的情况下，全局安装的软件包将无法访问网络，文件或其他任何地方。

奇怪的感觉似曾相识

这不是没有彻底的。Deno是相同的NodeJ。我只看到一些区别：

迪诺拒绝向后兼容。是什么使他无法使用自己的自行车，而是使用语言规范中描述的自行车来实现相同的目的。我确信，如果某种“ Node-next”在没有向后兼容性的情况下出现，我们将获得Deno提供的相同功能。而且，NodeJ逐渐朝这个方向发展：所有新的ES芯片（例如ES模块，顶级等待等）都逐渐引入到NodeJ中。
拒绝一般依赖项列表。这可以是正号或负号。这取决于具体情况。但是不能否认，这样的架构具有生存权。
这样做的目的是防止脚本在没有明确许可的情况下访问系统。

我认为这就是所有差异。因此，我认为没有理由讨厌Deno。那是他积极进取的公关人员:)

5对德诺的要求