Deno正在消亡？创始人Ryan Dahl发长文回应外界质疑

摘要：Deno 是一个现代 JavaScript 和 TypeScript 运行时，由 Node.js 的共同作者 Ryan Dahl 于 2018 年发起。这个项目的初衷是纠正他在设计 Node.js 时所留下的一些“遗憾”，例如模块系统、安全模型和开发体验等。凭

编译 | 苏宓

出品 | CSDN（ID：CSDNnews）

近日，Hacker News 上一篇名为《Deno’s Decline》（Deno 衰落）的文章引发了不少开发者的关注。

Deno 是一个现代 JavaScript 和 TypeScript 运行时，由 Node.js 的共同作者 Ryan Dahl 于 2018 年发起。这个项目的初衷是纠正他在设计 Node.js 时所留下的一些“遗憾”，例如模块系统、安全模型和开发体验等。凭借开箱即用、原生支持 TypeScript、更加注重安全性以及对现代 Web 标准的支持，Deno 一度在技术圈收获了不少好评。

不过在这篇文章中，曾是 Deno 坚定支持者的技术人 David Bushell 直言，Deno 正在走下坡路。其批评了 Deno Land Inc. 推出的商业产品 Deno Deploy。该平台号称具备“全球范围的边缘计算能力”，可以将 JavaScript 应用的服务器端逻辑部署在离用户更近的地理位置，从而实现低延迟和高性能——但 Bushell 认为，实际表现远不如宣传。

他指出自己在 2023 到 2024 年间亲自试用了 Deno Deploy，整体体验非常不理想。2024 年初，Deno Deploy 的部署节点从最初的 35 个锐减至 12 个；到了年底进一步缩减为 7 个，到 2025 年只剩下 6 个。比如首尔的节点被迁移至东京，响应时间从 8ms 飙升到 42ms，所谓“全球规模”几乎名存实亡。

Bushell 还提到，除了 Deploy，Deno 的其他核心项目也都陷入停滞或乏力的状态：

Fresh 框架：自 2024 年 10 月以来没有新版本发布，开发节奏明显放缓；

Deno KV：最后一个正式版本停留在 2023 年底，后续几个版本只打了 tag 并未发布，官网和博客也没有进一步动态；

JSR（JavaScript Registry）：被他讽刺为 “NPM at home”，意指并未解决 NPM 存在的根本问题；

Deno 运行时本身：更新内容大多是围绕 Node.js 兼容性修修补补，缺乏真正的创新。他还指出 SQLite 支持其实是受 Node 推进所迫才补齐的。他甚至调侃 Deno 2.2 的“主打功能”居然是 telemetry（遥测），从侧面反映出项目方向上的迷失。

Bushell 批评 Deno 背离了“修复 Node 生态”的初衷，早已不再是那个推动 JavaScript 根本性变革的项目，如今只是不断追赶 Node 的步伐。他坦言自己曾对 Deno 寄予厚望，如今却感到被“套牢”甚至“被割韭菜”，并自嘲是个“JavaScript 傻瓜”，但依然对新兴竞争者 Bun 抱有期待，准备继续跳进下一个“VC 支持的小丑车”。

随着这篇文章引发广泛讨论，Deno 之父 Ryan Dahl 也做出了回应，发文澄清称《关于 Deno 已死的报道被严重夸大了》。以下是他回应的全文内容：

最近有一些关于 Deno 的批评，涉及 Deploy、KV、Fresh 这些项目，甚至质疑我们整体的进展。你可能也在网上看到过这些声音，它们在一些常见的社区传播开来，吸引了不少关注。

有些批评确实有道理。说实话，我们在沟通上确实做得不够，没能及时、清晰地向大家说明我们正在做什么，未来的方向是什么。这导致了一些不安和疑问，这是我们需要承担的责任。

但也有一些声音并不准确，甚至带有猜测成分。我们写这篇文章，就是想把事情说清楚。这是一份近况更新，讲讲我们目前的发展、过程中的一些收获，以及接下来要做的事。有些人担心 Deno 已经走下坡路甚至快要“消失”，但这种说法完全不符合事实。

自去年 10 月发布 Deno 2 以来（其实才过去半年多！），我们的月活跃用户数量已经翻了一倍。Deno 2 引入了对 Node 的强大兼容性，这打破了过去的一个主要障碍，让很多实际场景都能顺利使用 Deno。整个平台变得更快、更简单、功能更强大。如今，Deno 的使用范围更广，用户也更加“认真”地在使用它。

Deno Deploy

我们最近听到最多的问题之一，是关于 Deno Deploy 的，特别是有人质疑为何可用区域数量减少了。我们理解这种“收缩”的表面看起来可能会引发担忧，但其实并不是外界猜测的那样出了什么问题。

真实情况是：大多数应用根本不需要在全球每个角落都运行。它们更需要的是：响应足够快、靠近数据源、调试方便，并能符合本地的合规要求。我们现在就是在围绕这些核心需求做优化。

Deno Deploy 是我们在 2021 年上线的，目的是探索一种全新的无服务器 JavaScript 模式。最初支持 25 个区域，后来扩展到 35 个，现在减少到了 6 个。

是的，区域数量的缩减确实有成本方面的考虑，但更关键的是使用情况。

我们发现，开发者并不是在部署那种简单的无状态函数，而是在构建完整的全栈应用——这些应用通常需要访问数据库，而数据库往往只部署在一个区域。结果就是，大多数区域几乎没人用。更糟糕的是，一旦流量突然上涨，那些平时“闲置”的区域反而最容易被打满，导致响应变慢。后来我们发现，直接把请求路由到一个稍远但运行良好的区域，反而比就近启动一个“冷区域”还更快。

我们当初追求的是一种“边缘计算”的理想状态，但那其实并不符合大家实际的使用方式。对于这点，我们之前没说清楚，这是我们的问题。

目前，Deno Deploy 正在大幅迭代开发。新版还没正式上线，但已经非常接近了。你可以在这里（https://dash.deno.com/account）申请抢先体验。

未来的 Deploy 不再只是一个函数托管平台，而会发展成一个完整的应用托管平台。它将支持子进程、后台任务、OpenTelemetry、构建流水线、缓存，甚至支持自托管区域。像 Next.js、SvelteKit，还有我们自己的 Fresh 等全栈框架都能在上面运行。

很快，你就可以将应用固定在某个特定区域运行，或者部署在你自己的云环境中。这是许多用户反复向我们提的需求——为了更好的控制力、合规性和性能。更多更新，敬请期待。

Deno KV 是我们推出的一款“零配置”的全局一致性键值存储，API 简单，还支持实时功能。对于会话数据、功能开关、在线协作等场景来说，KV 表现非常出色。开发者喜欢它，就是因为它简单、开箱即用，而且在全球范围内都能很好地工作。

但我们也很清楚，它并不是万能的。KV 不是通用型数据库，也不能取代大多数应用中需要的关系型系统。为了满足更广泛的状态管理需求，我们现在也在推进几项新计划：

首先，我们正在努力让传统的关系型数据库（比如 PostgreSQL）在 Deno Deploy 中更容易使用、更加无缝集成。

其次，我们认为 Deno KV 在“计算与状态的绑定”上做得还不够。受到 Cloudflare Durable Objects 这类系统的启发，我们正在开发一个新项目，目标是实现更紧密的绑定方式——也就是说，把状态直接和计算逻辑关联起来。

基于这些新的方向，Deno KV 会继续保持 beta 状态。我们会继续修复关键 bug 和安全问题，但它不会成为 Deno 里“统一解决状态管理”的那种核心方案。随着我们在状态管理方向上推出更多新工具，我们也可能对 Deno KV 做出较大的调整或改动。

这些新项目很快就会有更多消息，我们也非常期待跟大家分享进展。

Fresh

Fresh 依然活跃，状态很好——我们公司自己所有的应用和网站，都是用 Fresh 构建的。我们知道很多人都在期待 Fresh 2 的到来，也理解有些用户因为久等而感到有些失望。我们听到了大家的声音。其实我们本可以更早发布一个版本，但我们更希望把基础打扎实，不想为了博眼球而牺牲质量。Fresh 是我们内部项目的“核心依赖”，所以它必须足够可靠、足够优秀。

正式版将在今年晚些时候发布。

Deno，不只是一个运行时

Deno 已经不只是一个 JavaScript 运行时了，它现在是一个完整的平台，用来构建和运行 JavaScript 应用。它内置了：

原生支持 TypeScript 和 JSX

细粒度的权限控制和沙箱机制，确保运行安全

完整的语言服务器协议（LSP），配套 VS Code 插件，以及 deno check 提供类型检查

Jupyter Notebook 集成，支持 TypeScript 类型检查

deno compile 可以直接打包成可执行文件

对 Node.js/npm 的强大兼容性，包括 workspace 支持

一流的可观测性，内建 OpenTelemetry，开箱即用的结构化追踪（这是基础设施，而不是事后补丁）

deno fmt 自动格式化 JavaScript、TypeScript，甚至可以格式化模板字符串里的 CSS 和 SQL

完全基于 ES Modules 和 Web 标准构建

全球部署能力（通过 Deno Deploy）

包发布系统 JSR，拥有开放治理机制、不断扩展的标准库，以及出色的 workspace 支持

用 Deno，你可以用一套工具链完成编写、运行、测试、部署和监控。我们不断在做的是：减少命令参数，更好的默认行为，减少工具间的割裂。现在这些模块协同工作的效果，比以往任何时候都要好。

我们并不是在追求功能和其他运行时一一对标，而是在构建一个统一、有机的系统。我们真正想做的是：从根本上改善 JavaScript 的开发体验。如果我们有什么“错”，那是因为我们走得太远、目标太大。但我相信，没有人会否认 Deno 是在为这个世界上默认的编程语言创造一个更好的未来。

我们为什么在做这件事？

脚本语言，天然就是解决很多业务场景最合适的终点形态，尤其是那些“工程时间”才是瓶颈的问题。

Ruby、Python、Lua、Perl、JavaScript 都走的是这条路。而 JavaScript 是唯一一个真正普及到了每一台设备上的脚本语言，它有标准组织、有跨巨头的独立实现，还有庞大而活跃的生态。我们相信，有未来的脚本语言，就是 JavaScript（以及 TypeScript）。它值得拥有一个完整的平台，而不是一堆临时拼凑的工具。我们想提供的是一个“自带电池”的一体化系统。

就像 JavaScript 给你内建了垃圾回收和数组，Deno 同样开箱即用地提供了权限系统、Web 服务器、可观测性、代码检查和类型安全。这些功能不需要你去拼接各种第三方工具——Deno 本身就是那个粘合剂。

展望未来

我们不是要结束，而是在加速。

我们会持续打磨性能、兼容性和平台体验。JSR 正在逐步成熟，我们也成立了一个开放治理委员会，正在推动将 JSR 过渡为一个真正独立、由社区驱动的基金会。

我们在 TC39 和 WinterTC（原 WinterCG）中的参与也在继续。同时，我们也在积极应对 Oracle 误导性的 JavaScript 商标使用行为。这些都是我们为了推动 JavaScript 生态发展所做的一部分努力。

基于我们在 Deploy 和 KV 中积累的经验，我们还在开发一些全新的产品（还未发布），目标是让构建“持久化、分布式应用”变得更简单。这些产品很快就会有更多消息。

我们知道，之前的沉默可能带来了一些不安感。接下来我们会做得更好，把话说清楚，让大家及时了解我们的方向和进展。

—— Ryan

来源：

https://news.ycombinator.com/item?id=43863937

📢 2025 全球产品经理大会

2025 年 8 月 15–16 日