在本文中，我會分享自己的一些想法，談一談爲什麼 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/deno_structured_logging
爲了其他一些簡單的開發功能——我們需要越來越多的包：
奇怪的是，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 有那麼多成熟的特性，我們至少可以繼續用它。