对企业应用而言，Deno是一个糟糕的选择

作者 | onederman

译者 | 王强

策划 | 张晓楠

在本文中，我会分享自己的一些想法，谈一谈为什么 Deno 不适合用作企业应用程序的运行时系统，至少现在如此。欢迎大家在评论中补充有用的信息。

包管理器

Deno 包管理器的主要问题是，它在 CI/CD 中很难用。我的意思是，如果你需要快速执行 CI/CD，则必须将所有软件包手动加载到你的应用 Git 中（否则，每次 CI/CD 启动后开发人员和测试人员都需要等待从网络加载所有内容——这只是在浪费开发时间和预算）。如果选择 Git 这个选项，那么你的开发人员需要像上世纪那样手动进行所有升级（或者干脆换成带有 NPM 的 Node.js）。

import { connect } from "https://deno.land/x/amqp/mod.ts";import * as base64 from "https://denopkg.com/chiefbiiko/base64/mod.ts";import { createLogger } from "https://denolib.com/yamboy1/deno-structured-logging/mod.ts";...

另外，我不喜欢 Deno 不在一个文件中指示所有包的做法。在大型企业级应用程序中这是会造成混乱的。试想一下，超过 20 位开发人员无需任何系统化方法即可导入软件包。而且根本没有版本控制（仅在某些 URL 中或手动创建的带有依赖项文件中才有，这不是严格的默认设置）。我认为这是不对的。

包

我希望 Deno 具有所有 Express 功能，这样就不用任何框架了。但 Deno 并没有这样做，而是引入了那个 Oak 框架（“Oak”是它的名字）：

https://deno.land/x/oak

为了记录日志，我们需要再导入一个包：

https://deno.land/x/deno_structured_logging

为了其他一些简单的开发功能——我们需要越来越多的包：

https://deno.land/x/

奇怪的是，Deno 默认（"开箱即用"）几乎没有集成其中的任何功能，要知道它的使用场景是非常清晰的。至少应该集成最基本的功能，例如路由、日志记录和调试吧。

安全策略

Deno 的安全策略仅适用于相对较小的应用程序。大型企业应用程序需要大量权限，因此在我看来，我们必须为每个软件包指定策略。这就是为什么我们需要一个带有包的根文件或生成器（用于单体应用、服务等）的原因所在。使用现在的方法时，如果一个包被感染，并且在应用级别为另一个包提供了权限（所以被感染的程序包将具有该权限），那么整个应用的这个权限都会失效。

deno run --allow-net .\main.ts# it allows running the server via the net# basically, there is one permission for the whole app right now

初步结论

从我现在看到的情况来看，对于企业应用程序而言 Deno 是一个糟糕的选择。Node.js 有那么多成熟的特性，我们至少可以继续用它。

参考阅读：

https://hackernoon.com/everything-wrong-about-deno-as-a-runtime-system-for-enterprise-applications-eb1b3yyi

---

InfoQ Pro 是 InfoQ 专为技术早期开拓者和乐于钻研的技术探险者打造的专业媒体服务平台。扫描下方二维码关注 InfoQ Pro，即可在【充电计划】中获取技术 PPT 下载链接，每周更新哟~持续关注我们，还有更多技术分享活动与干货资料，就等你来！

点个在看少个 bug 👇