Deno 之死：Cloudflare 收购后运行时进入维护模式，作者复盘原因与后续
The Disappointing Death of Deno: What Happened, Why, & What's Next
Cloudflare 于 10 月 9 日收购 Deno 公司，Deno 运行时进入维护模式，未来十二个月只提供月度安全补丁和 bug 修复，之后核心团队将停止开发，Deno Deploy 也将在六个月内关停。
2026年10月12日
2026年10月9日星期五，有消息宣布 Cloudflare 收购了 Deno 公司，即开源 Deno JavaScript 运行时背后的团队。这一公告还带来了令人失望的消息：Deno 运行时将进入维护模式，在未来十二个月内每月接收安全补丁和错误修复，届时 Deno 核心团队将停止对该运行时的开发。Deno 公司还将在六个月内关闭其托管平台 Deno Deploy。
Deno 公司被收购对我来说并不意外。他们由风险投资资助，2026 年有许多迹象表明该业务并不健康。但让我意外的是，收购的结果竟是 Deno 运行时的死亡。作为一名在个人项目中全力投入 Deno、并在过去的工作中以小型、可控的方式引入它的开发者，我感到失望和沮丧。Deno 运行时对开发者极其友好，在很多方面都是我理想的开发环境。经过一个周末的反思，以下是对发生了什么、为什么以及接下来可能发生什么的详细分析。
伟大的 JavaScript 运行时之战
JavaScript 运行时基本上是一个允许你运行 JavaScript 代码的程序。你编写 console.log("Hello!")，将其保存为 hello.js，然后告诉 JavaScript 运行时可执行文件运行该代码。JavaScript 运行时评估并执行代码，将 Hello! 打印到终端。从某种意义上说，Web 浏览器是最古老、最持久的 JavaScript 运行时。它们被视为客户端运行时，因为它们在浏览器中运行，而不是在服务器上。在服务器端 JS 运行时方面，Node.js 存在时间最长（自 2009 年起），使用最广泛。十多年来，它一直是事实上的服务器端运行时。1
Node.js 的创造者是 Ryan Dahl。他也是 Deno 的共同创造者。就在 Node.js 发布大约 10 年后，他宣布了 Deno，一个旨在解决 Node.js 缺陷的新服务器端运行时。Deno 这个名字来自 "node".split('').sort().join('') // => "deno"。从一开始，Deno 的核心就是安全性、简洁性和更好的开发者体验。
Deno 运行时最初用 Go 编程语言编写，但后来改用 Rust。大约在同一时期，TypeScript（JavaScript 的类型化超集）开始流行。与当时的 Node.js 不同，Deno 允许开发者直接运行 TypeScript，而无需先编译为 JavaScript。Deno 于 2020 年 5 月发布 v1 版本。尤其是在该运行时的第一个版本中，它试图将自己与 Node.js 区分开来。Deno 旨在尽可能兼容 Web 的 ECMAScript 标准，使用模块导入和像 fetch 这样熟悉的 API。Deno 还内置了代码格式化和 linting，灵感来自 Go 和 Rust 等其他现代语言和工具链。
大约就是在这个时候，我开始在个人项目中使用 Deno。我在日常工作中写的 TypeScript 越来越多，而 Deno 吸引我的地方在于启动一个项目所需的配置极少。我可以编写零依赖的 TypeScript CLI，甚至无需任何配置文件就能将它们编译成可执行二进制文件。Deno 有一个可导入的标准库，提供了现代语言应有的海量函数。你甚至可以用 deno bundle 把代码打包以便在浏览器中运行。它确实让人感觉把服务端 JavaScript 和 TypeScript 带入了现代时代。
Deno 发布 v1 一年多后，第三个竞争者登场了：Bun。Deno 试图推动生态演进，而 Bun 则瞄准成为 Node.js 的直接替代品，同时引入了 Deno 提供的许多特性：直接运行 TypeScript 代码的能力、健壮的标准库，以及其他人体工学上的改进。随着 Bun 逐渐成熟、能力增强，这三者都成为了功能完备的 JavaScript 运行时，各有优劣。
我记得当时正在做一个个人项目，不确定该用 Deno 还是 Bun。那时我已经使用 Node.js 很久了，因为它在现代 Web 应用开发中几乎无处不在。所以探索 Deno 和 Bun 既令人兴奋又让人耳目一新。在 2020 年代初期，比较 Deno 和 Bun 时，对于我和我的小项目来说并没有一个明确的选择。Bun 内置了大量功能，比如无需引入外部依赖就能轻松连接 SQLite，以及可以轻松调用的哈希算法。而 Deno 有内置的格式化和 lint 工具，非常方便。Deno 那些改善开发者体验的内置功能，最终让我决定使用 Deno。我也很喜欢它想要推动生态演进，而不是去兼容 Node.js。Deno 对未来的愿景是我所认同的。
在此期间，Node.js 只是作为一个成熟、稳定、广泛使用的运行时稳步前行。新版本发布时会有一些合理的补充，但很少有太过创新或破坏性的变化。但 Node.js 的问题在于，生态系统变化太快，让人疲惫不堪。以测试为例。Jest 多年来一直是热门选择。后来它被 Vitest 取代。Node.js 中的框架、库和工具存在大量更迭。Deno 和 Bun 吸引人的一点是，许多这类辅助工具和库都是内置的，就像其他编程语言一样。更少的依赖意味着需要升级和维护的东西更少。也意味着更少的安全隐患。
Deno 和 Bun 都获得了风险投资人的资助。JavaScript 生态系统，比我用过的任何其他语言都更甚，有大量投资人资助的开源项目。数据库 ORM 变成了成熟的产品。一些开源 JS 库感觉不像是协作项目，而更像是打磨过的产品（这种方式让我觉得不吸引人，也不寻常）。Deno 团队和 Bun 团队用他们的资金雇佣开发者来开发运行时。Deno 尝试构建商业产品，比如他们的 Deno Deploy 托管服务。他们还构建了社区项目，比如 JSR，一个新的 JavaScript 代码注册中心，作为 Node.js 包管理器 npm 的替代品。Deno，或者至少 Ryan Dahl，还花了很多时间对抗 Oracle 对 JavaScript 的商标。与此同时，Bun 只是专注于运行时，并含糊地谈到未来某个时候会建立托管平台。但投资人期望他们的钱能带来回报。这两家公司都不是以构建稳定、成熟的运行时为目的的非营利基金会。不，两家公司都需要把一美元的投资变成两美元，或者理想情况下更多。
Deno 的托管平台 Deno Deploy 使用起来和运行时一样简单。只需把一些代码推送到 GitHub，它就能快速部署到云端，而且不需要构建步骤。团队定期添加新功能，比如内置到运行时中的 cron 作业和键值存储，使本地开发与托管应用保持一致。根据我将一个 Fresh Web 应用部署到它的经验，它运行良好，满足了我的需求。当时，它很有潜力，我希望它能成为 Deno 公司可持续的资金来源。
看起来三个 JS 运行时相互竞争会推动它们都变得更好，同时也会为了脱颖而出而创新。Deno 在被收购和弃用之前，一直在添加有趣的功能，比如 deno desktop 来在 Web shell 中运行应用。团队构建了 Fresh，一个由 Preact 驱动的全栈 Web 应用框架，基于 Deno 构建，作为 Next.js 的替代品。Deno 有一个更简单、更安全的生态系统的愿景。而且这个运行时拥有执行这一愿景所需的工具、库和团队。
Deno v2
2024 年 10 月，Deno v2 发布。它的主要卖点是兼容 Node.js，与 Bun 类似。Deno 将兼容 Node.js 的 package.json，并可作为直接替换的运行时。不用 npm run dev，只需 deno task dev 就能正常工作。他们还重建了托管平台 Deno Deploy，但奇怪的是移除了前面提到的 cron 作业等功能。最大化 Node.js 兼容性成为 Deno 和 Bun 的共同重点。
当时，我记得我想 哇，这可能是 Deno 起飞的机会。 鉴于它可以完全取代 Node.js，并且在若干方面比 Bun 有更好的开发者体验，它没有理由不成功。但事实并非如此。我无法自信地说明为什么 Deno 没有起飞并一飞冲天、成为事实上的运行时，但我至少可以说明，作为一名工程负责人，为什么除了小型内部项目之外，使用 Deno 做任何事情都从来都不合理：
在开发中使用与生产环境不同的运行时是个坏主意。
Vercel 是那份工作中运行的绝大多数 TypeScript 代码的托管平台。有些应用也托管在 Render 上。但当时，部署到 Vercel 的代码运行在 Node.js 上。尽可能在本地匹配生产环境有助于排除 bug 和异常行为。“本地能跑但生产环境不行”对调试来说非常糟糕。我尝试过用 Deno 在本地运行这些应用，但问题太多，实际上并不可行。Deno 的一大吸引力在于开发工具（linter、formatter、LSP 等）是内置的。但如果只有一个人用 Deno，你没法丢掉所有那些 Node.js 依赖。虽然 Deno 能运行 Node.js 应用，但这并不意味着切换到 Deno 就是明智的。尤其是当应用托管平台并不用 Deno 运行代码时。
另外，在 Deno Deploy 上运行这些应用也不可行，因为 Vercel 对 Next.js 应用渗透得很深，从它们的图片优化器到各种缓存机制。Deno Deploy 从来都不够健壮，无法把我们成熟的 Web 应用迁移过去。
所以我们继续使用 Node.js，以保持应用运行环境的一致性。
也许现在 Next.js 和其他托管平台已经支持 Bun 运行时了。改用 Bun 可能是有道理的。我不知道，因为我没有在积极开发任何较大的 TypeScript Web 应用。但在 2025 年，即使我想在工作中和个人项目里全职使用 Deno，这么做也不合理。所以对我来说，Deno 被降级到了脚本和业余项目。
不过 Deno 确实在一些大型企业中获得了一些认可。Slack 的 SDK 至少一度使用了 Deno。Bunny.net 的边缘脚本运行时使用 Deno。Netlify 也曾一度用 Deno 来做脚本。默认安全和无需构建步骤即可运行 TypeScript 的能力，使 Deno 成为这些项目比 Node.js 更合理的运行时选择。
Deno 的衰落与 LLM 的崛起
Deno 未能实现所需的巨大增长，无法为投入该公司的超过 2600 万美元投资带来健康回报。我无从得知 Deno 公司提供的企业支持是否带来了可观的收入。我也无从得知 Deno Deploy 是否有很多客户。但从外部来看，Deno 这家公司或这个运行时显然都不像是蒸蒸日上。
Ryan Dahl 在 2025 年 5 月 20 日写了一篇题为“Deno 消亡的报道被严重夸大了”的博客文章2，其中说道：
我们不是在追求与其他运行时的功能对等。我们在构建一个连贯的系统。我们在试图从根本上改进 JavaScript 开发。如果说我们有错，那是因为我们在这个目标上走得太远了。但我认为没有人能否认，Deno 正在为世界上默认的编程语言努力创造一个更美好的世界。
我们不是在收尾。我们是在加速。
我们正在基于从 Deploy 和 KV 中学到的一切构建新产品，尚未发布。它们旨在让持久化、分布式应用变得更简单。很快会有更多消息。
我们认识到我们的沉默有时会成为不确定性的来源，我们承诺在推进这些激动人心的发展过程中改进我们的沟通。
我记得当时读到这篇博客文章，并且真心相信 Ryan Dahl 所说的话。但事后回看，时机实在不巧。这篇博客文章写于 2025 年 5 月，正值智能体开发兴起的前夕——将编码工具接入 LLM API，循环生成代码并运行命令，直到任务完成。
由 LLM 驱动的编码工具改变了“JavaScript 运行时大战”的性质以及 Deno 的命运。在很多方面，Deno 本已准备好成为那个开发者使用概率性编码工具来运行命令和生成代码的世界里的首选运行时。该运行时默认安全的设计、用于检查正确性的内置工具、LSP、直接运行 TypeScript 代码。一切都已经具备。但 Deno 并没有随着 AI 编码的兴起而腾飞。事实上，情况恰恰相反。2026 年下半年，Deno 领域没有宣布任何重大进展。公开层面，发布仍在继续（例如 Fresh 框架发布了 v2）。但尽管 Ryan Dahl 声称 Deno 是在收尾，而不是在走下坡路，看起来却显然是后者。
Bun 和 Deno 都让构建命令行界面并将其编译为可执行二进制文件变得容易。使用 Deno，你运行 deno compile，它就会为你的宿主操作系统输出一个可执行文件（加上额外标志还可为其他系统输出）。二进制文件很大3，因为它包含了运行时本身，但这是一个快速且无痛的过程，可以在任何操作系统上完成，使得这两个运行时都成为用 TypeScript 构建 CLI 的便捷选择。LLM 接受了大量 TypeScript 和 JavaScript 的训练。此外，各种类型检查和 lint 工具能帮助由 LLM 驱动的编码工具在处理任务时检查正在编写的代码。
Claude Code 是 AI 公司 Anthropic 打造的由 LLM 驱动的编码工具，它使用 Bun 运行时构建。随着投资资金涌入 AI 公司，Claude Code 成为最受欢迎的编码工具之一，Anthropic 于 2025 年 12 月收购了 Bun 背后的团队。Bun 的投资者得到了回报，Bun 的未来开发至少在可预见的未来获得了资金保障。由于 Anthropic 的主要产品之一依赖 Bun 运行时，收购它、资助它并掌控它是合理的。
我记得当时想知道为什么各种公司为他们的 CLI 选择 Bun 而不是 Deno。老实说，我并不确定。更接近编码工具和其他大型 CLI 开发的开发者会有更多见解。但无论如何，Bun 通过构建一个开源 JavaScript 运行时，成功完成了让富人更富的使命。一美元的投资很可能变成了许多美元。
尽管 Deno 本已为软件开发方式的这一重大转变做好了准备，但天时地利并未齐备。Deno 公司靠投资资金驱动已有四年，团队规模远不止几个人。不难想象，资金正在相当快地消耗，并开始减少。我想 Bun 被收购只会给“需要某种投资回报”增加更多压力。如果我是投资者，我会想，如果竞争对手被一家大型 AI 公司收购了，为什么我们没有被收购？
Deno 之死
2026 年对 Deno 来说不是个好年头。三月份，出现了员工大规模离职。我看到的第一个离开的人是 Fresh Web 应用框架的维护者。然后有一天，一大群人在社交媒体上宣布告别并寻找新工作。这些人都是运行时、标准库以及其他附属项目开发的核心成员。有人猜测是裁员，但我找不到任何关于实际发生了什么的确认。Ryan Dahl 没有像典型的公司裁员后那样发布新闻稿说明发生了什么以及为什么。只有前员工在社交媒体上发帖说：“现在在场边为 Deno 加油，祝一切顺利，很棒的人们！”
然后孤注一掷的 AI 举措开始了。Deno 宣布了 Deno Sandbox，一种以更安全的方式运行 LLM 编写的代码的方法。你甚至可以调用 sandbox.deploy() 将其提升到 Deno Deploy 上的生产环境。有点巧妙，而且考虑到自 2025 年中期以来软件开发领域发生了多大变化，这完全合理。甚至还为此创建了一个 Python SDK。Deno 团队似乎在将他们从构建 Deno Deploy 中学到的经验与 LLM 运行命令和生成代码所固有的安全风险结合起来，构建一个更通用的、运行更安全的环境。
几个月后，在五月份，他们宣布了 Claw Patrol，一个开源项目，旨在帮助保护基础设施免受代理在访问服务器、数据库、机密等时可能造成的破坏。这是他们从内部使用中提取出来的，因为他们继续倾向于使用 LLM 进行开发和基础设施工作。
虽然以安全为重点的产品、功能和库是有意义的，但我实际上认为很少有大量使用 LLM 生成代码和执行命令的组织会非常认真地对待安全影响。尽管开发人员知道他们不应该在完全自动模式下运行连接到 LLM 的编码工具，并让其访问互联网、主机和关键基础设施，但这样做太容易也太诱人了。也许 Sandboxes 和 Claw Patrol 被广泛使用而我却不知道，但我怀疑，对于那些确实关心安全风险的公司来说，可能是对安全风险的漠不关心与大量类似解决方案的混合。
然后在八月份，Deno 公司发布了 celld，这是 Cloudflare 创建的 Durable Objects 模型的开源实现。celld 网站上说：
Durable Objects 模型是分布式系统多年来获得的最佳原语之一：一个单线程对象，拥有自己的存储，通过名称寻址。这个设计属于 Kenton Varda 和 Cloudflare Workers 团队。
celld 是写给他们的理念的一封情书；如此优秀的原语理应能在任何地方运行。
celld 甚至没有像 Sandboxes 和 Claw Patrol 那样在 Deno 博客上发布公告文章。但我可以想象，如果你花了数年时间为某个运行时构建运行时和托管平台，那么一个更具可扩展性的分布式架构会令人兴奋和向往。
虽然 Sandboxes 是一款产品，一个你可以付费购买的东西，但 Claw Patrol 和 celld 是作为开源项目发布的，甚至没有暗示它们可能如何转化为产品。这三个项目都瞄准了一个 LLM 正在编写越来越多代码、并能访问越来越多基础设施的行业。我不清楚 Claw Patrol、Sandboxes 或 celld 是否得到了任何认真的使用。也许有想法用 celld 来支撑 Deno Deploy 或其他某种比 Cloudflare 更容易自托管的托管替代方案？我完全不知道。
但看看大规模的人才流失、这三个项目，以及少数几个更次要的 Deno 运行时版本，很明显 Deno 公司的时间在滴答作响，某种东西需要迅速改变。打造一个商业上成功的软件产品，并使其收入以 Deno 公司所需的速度增长，至少需要六个月，甚至数年，即使有 LLM 生成代码也是如此。打造在财务上极其成功的软件产品很难。收购似乎是唯一的选择，也许这些努力是钓鱼线上的诱饵，用来寻找合适的买家？构建和发布开源工具与库似乎并不是一条显而易见的赚钱或获得收购的路径。但硅谷是个奇怪的地方……
不过它奏效了，至少在某种程度上。Cloudflare 收购了 Deno 公司，让这些人去开发 celld。Cloudflare 收购 Deno 并不是为了像 Anthropic 收购 Bun 团队那样继续开发运行时。不，这是一次人才收购，目的是让 Ryan Dahl 和 Bert 等人到 Cloudflare 工作，开发他们的开源 Durable Objects 项目 workerd：
Ryan 和 Bert 将领导一项新工作，使 workerd 自托管成为使用 Workers 编程模型构建和运行应用的一流支持方式。
以下是 Deno 就收购后运行时及其产品的未来所分享的内容：
我们将继续支持 Deno 运行时一年，每月发布包含错误修复和安全更新的版本。一年后，我们将结束对 Deno 运行时的开发。Deno 将保持开源，我们欢迎其他人继续其开发。
Deno Deploy 将继续运营六个月，然后关闭。我们将为迁移到 Cloudflare Workers 的付费客户提供迁移支持。
JSR 将继续运营，其基础设施将迁移到 Cloudflare。
我们将继续支持 rusty_v8，并努力将其集成到 workerd 中。
从 Deno 的帖子中可以清楚地看出动机：
对更好抽象的需求在 AI 时代尤为迫切。Durable Objects 汇集了对代理框架特别有用的能力：低成本、无服务器执行、持久状态、WebSockets 以及高级 JavaScript 接口。这是我最兴奋探索的，也是 celld 专注于 Durable Objects 的原因。
Ryan Dahl 对在这个 LLM 生成代码的时代构建服务器端软件的新方式感到兴奋。而且，方便的是，它还附带了一条出路：一部分资金返还给投资者，不再有裁员或大规模人才流失，不再需要构建一个兼容 Node.js 的 JavaScript 运行时。
Hacker News 上的一位评论者问道：“是谁决定放弃 Deno 运行时的？这是 Cloudflare 还是 Deno 的决定？为什么？” 4 Ryan Dahl 对此回应道：
这是一个共同的决定，我也同意。我对其成功投入最多，也付出了最多的努力——而我不再认为它是我能做出最重要工作的地方。Deno 中有一些好想法，工程实现也很出色——但它最终没有解决重大问题。它被卷入了 Node 兼容性的引力井，这迫使它的行为必须与 Node 完全一致。为什么要重新实现 Node？它已经能用了。边际的性能、用户体验或安全优势还不够。
我有兴趣构建强大的新抽象。celld 一直运行得非常好，仅依赖对象存储进行协调和持久化。它不仅仅是与文件系统或网络交互的略有不同的 API——它是一种全新的服务器开发模型。
我们将按月发布版本，持续一年，Deno 保持 MIT 许可。如果有人想继续推进它，我会很高兴。
在 Deno 的博客文章中，奇怪的是只有一句空洞的感谢：
致所有贡献代码、在 Deno 上构建业务、报告问题并信任我们方向的人：谢谢你们。
Deno 的未来与风险投资资助的开源
抱歉，但一句感谢和提醒代码库是开源的，并不是合适的回应。那是奇怪的行为。那不是作为一个项目的管理者或帮助引导它走向下一步。那不是真正相信并投资开源。Ryan Dahl，我很抱歉 Deno 解决的问题对你来说不再足够重大……我理解，很多事情都变了。但就像“为什么要重新实现 Node？它已经能用了。边际的性能、用户体验或安全优势还不够。”在年复一年地说这些理由足够之后，说出这样的话真是疯狂。当然，Node.js 现在可以运行一些 TypeScript 代码，但要做任何接近 Deno 所做的事情，都需要添加几十个包和配置。Node.js 世界是一团包管理器、工具和版本的混乱。Deno 有开发者使用它多年 有充分的理由，而被告知这些理由不再足够，从同时创建了 Node.js 和 Deno 的人口中说出，听起来只是令人难过。
在花了近十年向开发者推销为什么我们应该使用 Deno 以及公司的各种产品和库之后，这一努力的结果是一年的维护、一句感谢，以及一大堆 MIT 许可的 Rust 和 TypeScript 代码。很明显，Ryan Dahl 和 Deno 团队为这个项目和产品投入了很多。其中这么多是免费和开源的，令人钦佩。Deno 中投入了优秀的、创新的工作。硅谷是一个奇怪的地方，超过 2600 万美元被转化为开源代码，并被 Cloudflare 这样的大型科技公司收购式招聘，而可以说并不更好的新兴竞争对手却被最大的 AI 公司之一收购。
我完全能理解 Ryan Dahl 可能因经营 Deno 公司而疲惫不堪，想要转向其他更有趣的技术挑战。团队构建了 Deno 运行时和标准库，并维护了多年。从这个意义上说，这是一个成功。
但在我看来，一句感谢和一年的维护并不是处理这件事的尊重或恰当方式。那世界上像 Bunny.net 这样的公司呢？那些投入了时间和金钱以及基础设施到 Deno 上并基于它构建平台的公司。那些多年来一直使用它、支持它并享受使用它的开发者呢？即使 Ryan Dahl 或团队不再有兴趣继续开发 Deno，也不意味着你可以直接抛弃它然后跑路。即使最终的产品没有带来足以支撑一家可持续公司的收入，这也不是我曾想象过的结局。很容易想象出一种稍微不同的处理方式……
为什么 Ryan Dahl、Deno 公司和 Cloudflare 不转而以协作的方式向社区开放 Deno 的未来？公告本可以是：我们计划开展一系列公开讨论和电话会议，以建立一个 Deno 基金会，通过开放治理来维护运行时的未来发展。那样的话，依赖 Deno 的开发者和公司就不会像现在这样陷入不确定之中——不知道该做什么，谁有权使用 Deno 名称和资产，以及这种情况带来的所有其他法律问题。Ryan Dahl 不需要有答案，但我确实希望人们对 Deno 项目的未来能有比“如果有人想把它继续推进下去，我会很高兴”更开放的态度。Ryan Dahl、Deno 公司和 Cloudflare 可以也应该做更多来帮助 Deno 过渡到开放维护和治理。
2026 年 3 月 Deno 员工大规模离职后不久，由 Deno 公司内部构建和维护的 Fresh 框架被移出，放到了它自己的 GitHub 组织中，不再是一个官方的 Deno 项目。6 月 3 日，Fresh 的创始人之一在 GitHub Discussion 上发帖说5：
简而言之：Fresh 现在有了自己的组织，这样更多人可以获得审查和 PR 权限，我们也可以为它建立公开的治理结构。Deno 的人会继续贡献。Fresh 将变成仅支持 Vite，并在此过程中获得一堆新功能。我还在开发围绕 signals 和可序列化函数的新功能，让 Fresh 更易于使用。
在那之后的四个月里，没有任何后续，没有合并的 PR，没有对评论的回复，没有关于新治理的任何消息，什么都没有。既然 Deno 已被废弃，Fresh 会怎样？那些运行基于 Fresh 构建的应用的人呢？这可不是简单迁移到另一个框架或运行时那么简单。
“直接用 Node.js 或 Bun”其实并不是一个那么简单的答案。对于任何投资了 Deno 的公司或企业来说，你的运行时实际上被扼杀了，而社区或其他组织没有任何计划延续到未来的信号，这是一个非常糟糕的处境。像 Bunny.net 这样的组织，他们的运行时建立在 Deno 之上，该怎么办？他们维护自己的分支，还是帮助建立一个组织来维护它？他们切换到 Bun 吗？Bun 和 Deno 功能并不对等，所以对于 Bunny.net 这种规模的东西来说，这需要付出工作和努力，并会产生重大影响。
对于像我这样认同 Deno 的使命、并且有一大堆依赖 Deno 的小型 CLI、脚本和 Fresh Web 应用的开发者来说，我感到沮丧和不确定，某种程度上还觉得被欺骗了。我原本对 Deno 的资金来源以及该项目缺乏任何形式的开放治理有所保留，但我错误地忽略了这些担忧。直到最近，我还在用 Deno 的 Deploy 平台（两个版本都用过）来部署我的 Web 应用和网站，但把项目从上面迁走对我来说并不算太麻烦。不过可以说，我的工作流里仍然有大量地方用到 Deno。我用它来格式化 Markdown、HTML 和 CSS。我用它来生成静态站点。多年来，它一直是我个人项目的首选。我维护着托管在 JSR 上的库。我深深地卷入了 Deno 这一团乱麻之中。
我肯定不会在新项目中使用 Deno。除非未来该项目在治理方面会发生什么变化变得明朗，或者会出现一个持续维护的分支，或者别的什么。有太多不确定性，无法预知会发生什么。我肯定也不会再向 JSR 发布包了。
当然，我的一些项目可以轻松切换到 Node.js 或 Bun。但我会怀念我在项目中使用的内置格式化和 linting 以及 LSP。我对 Bun 由 Anthropic 资助和控制感到不安，这家公司正在开发的软件及其行事方式是我在道德上反对的。也许 Bun 会超越 Node.js 成为事实上的服务端 JS 运行时？但我不会使用 Bun。我想在需要时我会不情愿地使用 Node.js。但对我来说问题在于：我喜欢使用 Deno。它有许多特性，使它成为我的首选。我想还有其他开发者也有同感。我会很好奇 Deno 会发生什么，如果有的话。我不抱太大期望。但如果有更开放的维护模式，我会继续使用并支持它。虽然分叉 Deno 和 Fresh 并维护它们的想法乍一想有点有趣和令人兴奋，但我实际上并不太了解这两个项目或 Node.js 或 TypeScript 的内部机制。那不是我想要做的工作，但不难想象可能有其他公司或人愿意做那项工作。
不过，我从这一切中得到的最大启示，就像无云的晴朗秋日一样清晰：避开风险投资资助的开源项目。
我不太懂商业。但对我来说，Deno 和后来的 Bun 获得数百万美元投资来创建开源运行时、库和工具（也许还有一些产品），这确实显得很奇怪。开源项目的资金来源多种多样，从创建项目的公司，到依赖它们的公司，再到重视它们的社区。不同的方式各有优缺点，而且其中涉及大量政治因素。但如果人们和公司依赖某个开源项目，那么它很可能在某种程度上会得到维护。但风险投资支持的开源项目最让我担心，因为这种融资机制本身就内含着增长、赚钱以及可能被出售的压力。向一个项目注入大量资金并需要它增长，似乎不利于建立和维持一个长期（数年乃至数十年）的重要开源项目。产品和业务当然可以围绕开源项目涌现，但需要把一个投资人的一美元变成两个或更多投资人的美元，并以此作为项目本身的基本要求，这几乎肯定会导致崩溃和失败，除非天时地利人和。虽然 Bun 目前还有资金，但 AI 公司的财务基础看起来确实不稳定，Bun 的未来也很难说。风险投资资金不会带来可持续的开源软件。
也许 Deno 的故事还会有后续，依赖它的开发者和公司会继续推动开发。也许 Ryan Dahl、Deno 公司和 Cloudflare 会以更有意义的方式帮助实现这一点。或者，一旦那十二个月的维护期结束，Deno 就真的走到尽头了。我很想知道这一切会如何发展。与此同时，我会花些时间把我更重要的程序移植到更稳定的东西上。
感谢阅读！如果你觉得这篇文章有帮助、有见地，可以考虑请我喝杯咖啡，支持我的写作。
延伸阅读与关键链接
- Blog posts about the acquihire
- https://celld.dev/ - 促成 Cloudflare 收购的开源项目
- 大规模出走引发的 Reddit 讨论帖
- David Bushell's various Deno writings
脚注
来源：Hacker News · brettcodes.com