【译文】Deno 令人失望

一旦决定重新审视自己的业务和媒体战略，就不可避免地要开始重新思考和审视过去所做的其他决定。

其中一个决定就是Deno，在过去几年中，我的大部分个人项目和实验都使用了Deno。这些项目大多比较简单–命令行脚本或小型网站。例如，我使用 Lume 和 Deno 制作了 softwarecrisis.dev 新闻通讯登陆页面。在 Colophon Cards 之后的研究项目中，我使用 Deno 制作了大部分原型。它非常有用。

有很多地方值得称道

Deno 有:

对标准浏览器 API 的支持总体上要比 node 好得多。
非基于标准的应用程序接口更贴近浏览器习惯，使前后端之间的切换不那么生硬。
出色的标准库
安装更简单。它只有一个二进制文件，使安装和部署更加简单。
你需要的大多数工具：内核、测试运行器、基准测试、代码格式化、类型检查器和文档生成。
运行代码的合理安全模型

如果你的任务只需要标准库或标准工具，那么使用 Deno 就是一个梦想–简单本身。

如果任务需要的东西比这更多，你很快就会发现自己陷入困境。

Deno背后的公司试图通过双管齐下来解决这个问题：

为网络项目可能需要的大多数常用工具和项目构建 Deno 专用版本。
迅速为其运行时推出 node 和 npm 兼容性。
这意味着，一家初创公司已经承担起了构建自己的可扩展主机、持久化存储产品、持久化执行队列、实时通知、计划执行、前端 React
框架的责任，毫无疑问，在您读到这篇文章时，还有更多的工作要做。

这意味着，一家初创公司已经承担起了构建自己的可扩展主机、持久存储产品、持久执行队列、实时通知、计划执行、前端 React 框架的责任，毫无疑问，在您读到这篇文章时，还有其他一些责任。

他们甚至计划为 Deno 2.0 构建自己的全功能软件包注册表。(另外，关于 Deno 未来的许多信息都只能通过视频获得，这也挺令人讨厌的）。

此外，他们还试图为其运行时实现与 node 和 npm 的完全兼容。

基本上是这样：

你的商业模式是托管。
但人们常用的工具和项目都无法在新的运行时和托管环境中使用，所以你需要实现自己的工具和项目来填补空白。
然后你会发现，对托管服务需求最大的是拥有传统代码和传统依赖性的客户，因此你必须给他们提供一种方法，将它们移植过来。这就是兼容性。
原来，”传统 “系统中许多恼人的功能都是有原因的，所以你必须自己实现它们，但你显然要以更新、更现代、更合理（但不那么向后兼容）的方式来实现它们。
如果不是因为你现在必须对运行时的大部分功能进行两个版本的维护，要么是从 “遗留 “系统到新系统的转换层，要么是需要维护的两个完全独立的功能，那么这样做也没什么问题，甚至可以说是非常好。

我们以前见过这种策略。它基本上就是 Cloudflare 的策略，或多或少有些细节。执行过程中的大部分差异都是因为 Cloudflare 从这条特殊香肠链的另一端开始：先是云托管，然后是开源运行时，而不是像 Deno 那样反其道而行之。

我认为 Deno 的工具更好用，他们的运行时也更容易使用，但两家公司的总体战略是相同的。

Bun 采用了相同的策略，他们唯一的创新在于，由于起步较晚，他们从一开始就明白了与 node 和 npm 兼容的必要性。

我认为这种做法对他们都没有好处。

传统 “兼容性实际上消除了为 Deno（或 Cloudflare 或 Bun）制作软件包的动力。既然你可以直接制作一个 Node 软件包，为什么还要使用 dnt 来创建同时兼容 Deno 和 Node 的软件包呢？它仍将同时兼容 Deno 和 Node。这一点，Deno 自己已经看到了。无论哪种方式，你都能获得跨运行时的兼容性。

风险在于，Deno实际上将成为运行来自npm生态系统的代码和项目的平台。只不过，它在 “节点 “方面永远不会像节点本身那样出色。

由于 node 是一个不断变化的目标，因此在 node 和 npm 兼容性层中始终会存在空白。它是一个仍在不断变化的活项目。

如果 Deno 由基金会或开源社区维护，我就不会那么担心了。它不可避免地会缩小范围，但这也没什么。要成为一个成功的社区驱动型软件项目，并不需要称霸世界。假以时日，它一定能找到自己的定位。

但要想成为一家成功的风险投资初创公司，你确实需要征服世界上的大部分地区。

Deno 生态系统已经出现了脱节。许多第三方模块似乎停滞不前，已经有一段时间没有更新了。那些看起来充满活力的项目往往是那些针对浏览器兼容平台的项目，因此他们几乎不需要付出任何具体努力，就能免费获得 Deno、Cloudflare 和 Bun 的支持。

Node 也没有停滞不前。他们正在增加对许多使 Deno 与众不同的功能的支持，例如内置工具、具有覆盖范围的测试运行器和 HTTP 导入。甚至导入映射也在他们的路线图上。

Node 的命运也不取决于一家初创公司或科技公司的命运。

npm 生态系统仍然是一个战略性问题，但增加对导入映射和 HTTP 导入的支持将在一定程度上缓解这一问题，与此同时，你可以直接从 git 安装 node 软件包，或使用与 npm 兼容的第三方仓库。任何 git 远程 URL 都可以使用 npm install，无需 GitHub。

看到软件生态系统中的资金和人才流失，公司大规模转向固有的保守的 LLM 进行开发，以及软件开发者普遍日益增长的挫败感，我们很难设想 Deno 或 Bun 会在与 Node 的直接竞争中胜出。

一旦这两家由风险投资支持的初创公司走投无路，我也不太愿意使用它们。

对于我们这些喜欢使用 JavaScript 的人来说，这意味着从长远来看，Node 是我们后端的最佳选择。

也许是时候尝试在 node 中重现 Deno 的工作乐趣了。

但是，Node 的改进并不是 Deno 面临的唯一问题。

最重要的一点是，Node 的合理替代方案–开发人员可能会选择的 “无 Node “工作环境–并不是基于 JavaScript 的。导入映射意味着浏览器实际上拥有一个 API 表面，非 JavaScript 项目可以利用它来构建依赖关系管理系统。现在，围绕 JavaScript 的很多工具都是用 Rust 而不是 JS 实现的，其中很多都是由 Deno 自身驱动的，这使得它在 Node 和 Deno 生态系统之外更容易被访问。此外，WASM 组件模型有望使许多依赖关系在运行时独立，而围绕 JavaScript 的基于 Rust 的工具是合乎逻辑的初始目标。

对于许多人来说，”没有 Node “的替代方案不会是另一种 JavaScript 运行时，而是完全不同的东西。

本文文字及图片出自 Disillusioned with Deno