在开源社区对Deno项目未来走向质疑声渐起之际，Node.js之父、Deno项目创始人Ryan Dahl于5月20日发表长文《关于Deno衰落的报道被严重夸大了》（Reports of Deno's Demise Have Been Greatly Exaggerated）。这篇回应在Hacker News等技术社区引发广泛讨论，支持和质疑声音并存，凸显出开源项目在发展过程中面临的多重挑战。

坦承沟通不足，但增长数据向好

Ryan在文章开头坦言，一些批评确实有其合理性。他承认公司在沟通方面做得不够好，未能及时向社区传达项目的发展方向。「这确实是我们的问题，」他说。

数据显示，自去年10月Deno 2发布以来短短6个多月内，月活用户数已翻倍增长。Ryan将这归功于Deno 2引入的强大Node兼容性，认为这消除了一个重要的采用障碍。

然而，这一增长数据在社区引发了不同解读。HN用户skybrian指出：「他们说用户翻倍了，但具体和什么比？而且到底在测量什么？他们没有披露任何真实的采用率数据。」正如用户skybrian所说：「人们最初对Deno抱有很高期望，因为它是新生事物，你可以想象它会有巨大增长。现在的失望可能源于与那些模糊的希望和梦想的对比。」

Node兼容性之争：理想与现实的角力

Node兼容性的引入成为社区争议的焦点。反对者认为这背离了项目最初的愿景。「当他们抛弃早期承诺，增加Node向后兼容性时，我对Deno的兴趣就消失了，」用户mattlondon表示，「Deno的全部卖点在于它是没有历史包袱的Node，但他们放弃了这点，基本上就变成了一个内置TypeScript支持和其他一些小功能的Node。」

但也有务实的声音为这一决定辩护。「为什么要把增加功能（npm兼容性）视为失去了什么？你完全可以不使用任何Node API，就用Deno自己的API——它们已经相当完善了，」用户skybrian说。还有人指出：「如果你想要纯粹不用Node的开发体验，Deno仍然能给你这种体验。但事实证明很少人真的在意这种纯粹性，所以幸好他们没有固守这一点。」

Deploy区域缩减：Edge还是集中化？

关于Deno Deploy可用区域从35个减少到6个的争议，Ryan解释说这是基于实际使用情况的决定。他表示大多数开发者构建的是需要与单一区域数据库通信的全栈应用，而不是简单的无状态函数。

这一解释在社区引发了关于serverless范式的更广泛讨论。「这听起来很奇怪，」用户nicce说，「我选择不使用Deno Deploy正是因为区域不够近，这只会让一切变得更慢。」用户wyuenho则表示：「我好奇这是否代表了现今serverless用户的普遍情况。如果是的话，那这与这场运动的初衷是否相符？这些用户是否只是不想处理docker/k8s？」

用户mosura提出了一个有趣的观点：「我的直觉是人们想要的是一个现代化的Heroku。一个管理良好的关系数据库加上一组自动扩展的服务器。这就能覆盖大多数不需要也不想要大规模扩展的公司。」

KV存储的转向与Fresh框架之困

对于KV存储服务，Ryan承认它将保持在beta状态，团队正在开发新的状态管理解决方案。这一消息让不少开发者感到担忧。「这是个糟糕的举动，」用户pier25评论说，「公司不采用KV正是因为它处于测试阶段，而不是因为这是个糟糕的想法。我经常使用Cloudflare Workers KV，对持久化对象并不感兴趣。直到现在我都对Deno KV很感兴趣。」

关于Fresh框架，尽管Ryan强调重构是为了确保质量，但社区对其发展速度表示担忧。用户dbushell指出：「Fresh正在进行重构，alpha版本要等到『2025年第三季度晚些时候（可能是9月）』。它本来就是一个相当基础的框架。唯一有趣的想法是不需要编译/构建步骤，而这个特性现在也要被放弃了。」

商业模式之忧

作为一个风投支持的项目，Deno的商业化方向也引发了社区的担忧。用户leptons写道：「如果AWS Lambda支持Deno，我可能会考虑使用它。我需要的是主流基础设施提供商的FaaS。我不会把任何重要项目放在Deno的服务器上，他们并不是行业领导者，而且在当前科技行业的形势下，转眼间就可能消失。」

用户yahoozoo认为Deno偏离了最初的定位：「Deno的问题在于它已经迷失了方向。当它多年前首次公布时，它仅仅是一个用Rust编写的更安全、更快的JS/TS运行时。但现在你去网站看，『产品』下拉菜单里塞满了其他东西。这就像他们看到Vercel在推出NextJS后又推出了部署平台，想要效仿。」

风投背景的双刃剑

多位开发者表达了对Deno风投背景的担忧。「这篇文章很好地说明了为什么这很重要，」用户afavour写道，「它几乎不是关于Deno本身，而主要是关于Deno Inc提供的付费服务。他们必须优先考虑这些，因为投资者想看到财务增长。」

用户Lerc为这种商业模式辩护：「从某种程度上说，这是件好事。他们的盈利计划是提供那些服务。这个目标需要Deno保持健康。如果Deno本身是他们想要销售的产品，我会更担心。只要Deno本身保持开源，我觉得这是可以接受的。」

Bun的崛起：竞争加剧

在Deno努力证明自己生命力的同时，新兴的JavaScript运行时Bun的快速发展也引发了社区的广泛讨论。「我的感觉是Deno被Bun和Node.js双重压制了，」用户k__表示，「虽然有人抱怨Deno加入Node.js兼容性，但我认为这恰恰是让Deno在后期保持生存的关键。」

用户eknkc分享了自己的经历：「有趣的是，我测试过几次Deno但一直在用Node，直到Bun出现后我就转向了Bun。我说不清具体原因。」k__补充道：「Bun从一开始就做对了，而且看起来人们都很喜欢它。即使使用兼容API，它也比Node.js和Deno快得多。如果他们继续保持这种势头，他们可能会达到Go语言级别的性能。」

不过，也有开发者对Bun提出了质疑。用户ctz指出：「看看Bun的问题追踪器就知道了，最近的五个问题都是崩溃相关。虽然其中一些是受控的panic或断言失败，但其他的则是像『从地址-1执行』或『试图从地址0x00000069读取』这样的问题。最近编写的软件根本不应该有这类问题。」用户Sytten补充说：「当你阅读Bun的代码库时，他们忽视边缘情况的做法令人担忧。相比之下，Deno的代码库是真的靠谱。这真的是Rust相比Zig将会大放异彩的案例。」

未来走向：在理想与现实间寻找平衡

Ryan在文章最后强调，Deno并非在收缩，而是在蓄力。团队正在持续改进平台性能，JSR包管理系统也在成熟并计划转型为独立的社区驱动基金会。在标准化方面，Deno继续参与TC39和WinterTC工作，同时还在积极挑战Oracle对JavaScript商标的误导性主张。

在文章最后，Ryan Dahl阐述了他对JavaScript未来的愿景：「脚本语言是一大类问题的人体工程学终点：工程时间是限制因素的业务逻辑。Ruby、Python、Lua、Perl和JavaScript都遵循这一思路。但JavaScript是唯一一个分布在每个设备上、有标准组织、跨科技巨头的独立实现、拥有庞大活跃生态系统的语言。我们相信JavaScript（和TypeScript）是有未来的脚本语言。它值得拥有一个匹配的平台，而不是临时工具的拼凑。一个包含所有功能的完整系统。」

这场讨论反映出，开源项目在发展过程中常常需要在多重目标间寻找平衡：技术理想与用户实际需求、开源精神与商业可持续性、创新突破与稳定性维护。Deno的经历或许能为其他开源项目提供有益的思考。