在本文中，我会分享自己的一些想法，谈一谈为什么 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

创作场景

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