Cloudflare 收购 Deno
Cloudflare 对 Deno 公司的收购会把 Deno 团队及其 celld 技术带入 Cloudflare 的 Workers 生态，而开源的 Deno 运行时本身只会再获得一年的 bug 和安全更新，之后官方开发将停止。评论者普遍将其视为一次 acquihire，并认为这对独立的 JavaScript/TypeScript 运行时是一次打击，许多用户现在正准备迁回 Node.js，或转向 Bun 和 workerd 等替代方案。这一举动也引发了更广泛的担忧：VC 资助的开源工具是否可持续、运行时是否会进一步集中到大型平台，以及是否需要由社区或基金会支持的治理来确保长期稳定。
收购与 Deno 运行时停止开发
- Deno 团队将加入 Cloudflare；Deno 运行时未来约 1 年内只会获得 bug 修复/安全更新，之后原团队将停止继续主动开发。
- 许多读者认为这更像是 acquihire 和事实上的停止维护，而不是“Deno 加入 Cloudflare”。
- 有些人批评这一点在 Deno 的帖子里写得很明确，但在 Cloudflare 的帖子里被淡化或根本没有提到。
celld、workerd 与 Cloudflare 的策略
- 许多人认为 Cloudflare 关注的主要是 celld 和该团队的运行时经验，而不是 Deno 运行时本身。
- 计划是把 celld 的自托管 Durable Objects 模型合并进 Cloudflare 的开源 workerd，打造一个一等公民、可自托管的 Workers/Durable Objects 运行时。
- 线程中的 Cloudflare 员工强调：workerd + celld 将继续保持开源，并希望让 KV/queues/等组件在通用基础设施上可插拔（例如 S3 风格的对象存储）。
为什么 Deno “失败”了（按评论者的说法）
- 常见理论包括：
- 面向运行时 + 托管（Deploy）的 VC 模式不可持续。
- Node 已经“足够好”而且体量巨大；Deno 没有带来 10 倍级别的改进。
- 早期拒绝支持 npm/node_modules 阻碍了采用；后来再加入兼容性又削弱了最初愿景。
- Bun 激进的 Node 兼容和速度抢走了关注度。
- Deno 团队评论说，Deno 正被拉向完整的 Node 兼容，变成“又一个 Node”，而 celld 则是一个更有新意的抽象。
对用户和生态的影响
- 一些公司和项目大量基于 Deno 构建（serverless 平台、内部工具、yt-dlp 集成、爱好者的 TUI/桌面应用），现在都面临迁移工作。
- 关于迁移难度的看法分歧很大：
- 许多人说迁移到 Node/Bun 基本可以由 LLM 自动化，除非强依赖 Deno 特有 API（Deno.serve、KV、Deploy），否则只是“一两天”的工作。
- 也有人强调平台锁定和文书/流程上的痛苦。
开源、融资与整合
- 线程里反复质疑 VC + OSS 运行时模式；很多人认为 Deno 本该保持为一个精简、由赞助支持的开源项目。
- 人们担心整合趋势：Bun → Anthropic，多个开发工具 → AI/云巨头，现在 Deno → Cloudflare。
- 也有人指出，Deno 的想法已经推动 Node 增加了权限、TS stripping、单文件可执行应用；竞争被认为改进了 Node。
围绕 Deno 的产物的未来
- Deno 运行时是 MIT 许可证；人们在讨论可能的社区分叉版本（“opendeno”）。
- Cloudflare 参与者表示 rusty_v8 和 JSR 会继续存在，并会在 Cloudflare 继续整合/托管。
- 社区是否能诞生一个可行的、由社区主导的 Deno 后继者，普遍被认为仍不确定。