关于 Deno 消亡的报道被大大夸大了

最近 Deno 受到了一些批评——关于 Deploy、KV、Fresh 以及我们整体发展势头的批评。您可能已经在网上看到了一些负面评论；它们在常见平台流传，并引起了相当多的关注。

其中一些批评是合理的。事实上，我认为可以说，我们对正在进行的工作以及公司和产品的未来方向过于沉默，从而助长了一定程度的担忧和不确定性。这是我们的责任。

在其他方面，最近的批评不准确或具有猜测性。这就是我们撰写此文的目的；为了澄清事实。这是一篇关于我们目前状况、所学经验以及接下来将构建内容的总结。一些人担心 Deno 本身正在衰落或消失，但这完全不是事实。自去年 10 月发布 Deno 2 以来——仅仅六个多月前！——根据我们的月活跃用户指标，Deno 的采用率翻了一倍多。Deno 2 强大的 Node 兼容性有效消除了一个主要的采用障碍，解锁了广泛的严肃用例。该平台变得更快、更简单、功能更强大。Deno 现在比以往任何时候都得到更广泛、更认真的使用。

Deno Deploy

我们听到的最大疑问之一是关于 Deno Deploy——特别是可用区域的减少。虽然我们理解这种缩减给人的观感，但其原因并非人们常担心或指责的那样。

相反，现实情况是：大多数应用程序不需要在所有地方运行。它们需要快速、靠近其数据、易于调试并符合当地法规。我们正在为此优化。

我们于 2021 年推出 Deno Deploy，旨在探索一种新的无服务器 JavaScript 模型。它最初在 25 个区域启动，增长到 35 个，现在在 6 个区域运行。这种缩减是出于成本考量——是的——但也由使用情况驱动。大多数开发者并没有部署简单的无状态函数。他们正在构建全栈应用：与数据库交互的应用，而这些数据库几乎总是位于单个区域。我们发现，大多数时候，多余的区域大多未被使用。当流量高峰来临时，空闲区域会迅速达到容量上限，导致延迟飙升。我们发现，将流量路由到更远但更大的区域通常比在附近冷启动的区域运行更快。

我们追求的“边缘”愿景与人们实际使用服务的方式不符。我们不应该对此保持沉默。

Deno Deploy 正在紧锣密鼓地开发中——我们尚未发布最新版本，但即将推出。您可以在此处申请抢先体验。

Deploy 正在演变为一个用于托管应用程序的平台——而不仅仅是函数。它将支持子进程、后台任务、OpenTelemetry、构建管道、缓存，甚至自托管区域。它运行 Next.js、SvelteKit 以及 Fresh 等全栈框架。

很快，您将能够将您的应用程序固定到特定区域——或在您自己的云中运行它。这是我们从关心控制、合规性和性能的用户那里反复听到的需求。更多详情即将公布。

KV

Deno KV 是我们零配置、全球一致的键值存储，具有简单的 API 和实时功能。我们意识到，对于会话数据、功能标志和协作状态等场景，KV 表现出色。开发者喜欢它的本色：一个零配置、开箱即用的全球存储。

但它并不能解决所有问题。它不是一个通用数据库，对于大多数应用程序来说，它不能替代关系型系统。为了满足这些更广泛的状态管理需求，我们正在进行多项工作。

首先，我们正在努力使传统关系型数据库在 Deno Deploy 中更容易获得和使用。
其次，我们认为 Deno KV 本身在简化计算与状态绑定方面做得还不够。因此，受 Cloudflare 的 Durable Objects 等系统启发，我们正在开发一个新项目，以实现这种更深层次的集成，旨在将状态直接绑定到计算。

鉴于这些新方向，Deno KV 将继续处于测试版阶段。我们将继续解决其当前版本的关键错误和安全问题。虽然 KV 对其预期用途而言很有用，但它的作用并非成为 Deno 中所有状态管理的核心或演进解决方案。随着这些其他状态管理计划的成熟以及我们整体平台战略的演进，我们保留未来对 Deno KV 进行重大更改的权利。我们很高兴很快能分享更多关于这些新项目的信息。

Fresh

Fresh 活跃且发展良好——它支持我们构建的每一个应用程序和网站。我们知道你们中的许多人一直热切期待 Fresh 2，也许有些人因等待而感到沮丧。我们理解您的心情。我们本可以更早发布，但打好基础至关重要，我们不想为了快速的市场宣传而牺牲质量。我们所有的网站都依赖 Fresh，因此其卓越性至关重要。我们刚刚撰写了一篇详细文章，介绍了 Fresh 2 中即将到来的重大改进——请去阅读！稳定版将于今年晚些时候发布。

Deno，运行时平台

Deno 不再仅仅是一个运行时；它是一个用于构建和运行 JavaScript 系统的完整平台。以下是其内置功能：

TypeScript 和 JSX 支持
精细权限和沙盒，用于安全执行
完整的语言服务器协议 (LSP)、VS Code 扩展以及用于类型检查的deno check
Jupyter Notebook 集成，支持 LSP 的 TypeScript 类型检查
deno compile，用于生成独立二进制文件
强大的 Node/npm 兼容性，包括工作区支持
通过内置 OpenTelemetry 提供一流的可观测性，开箱即用提供结构化跟踪。**这是一项重要的基础设施组成部分，而非事后添加，正如一些人所嘲笑的。**
deno fmt，用于自动格式化 JavaScript、TypeScript（甚至模板字符串中的 CSS 或 SQL）
基于 ES Modules 和 Web 标准构建
一个全球部署面（通过Deno Deploy）
一个发布系统（JSR），具有开放治理、不断增长的标准库和出色的工作区支持

您可以编写、运行、测试、部署和监控——所有这些都通过单一工具链完成。我们一直在加强集成。更少的参数。更优的默认设置。更小的鸿沟。各部分之间的协作比以往任何时候都好。

我们不是在追求与其它运行时功能对等。我们正在构建一个内聚的系统。我们正努力从根本上改进 JavaScript 开发。如果说我们犯了错，那是因为我们在这个目标上用力过猛了。但我认为没有人会争辩说，Deno 没有在为世界默认的编程语言创造一个更美好的世界而努力。

我们为何这样做

对于一大类问题，脚本语言是高效的终极解决方案：即工程时间是限制因素的业务逻辑问题。

Ruby、Python、Lua、Perl 和 JavaScript 都遵循这一思路。但 JavaScript 是唯一在所有设备上分发、拥有标准制定机构、科技巨头间独立实现以及庞大而充满活力的生态系统的语言。我们认为，有未来的脚本语言是 JavaScript（以及 TypeScript）。它值得拥有一个与之匹配的平台，而不是一堆零散工具的拼凑。一个开箱即用的单一系统。

就像 JavaScript 为您提供垃圾回收和内置数组一样，Deno 为您提供权限系统、Web 服务器、可观测性、代码检查和类型安全——所有这些都开箱即用。您无需手动拼凑。Deno 就是那个粘合剂。

展望未来

我们没有放慢脚步。我们正在加速前进。

我们正在持续改进平台性能、兼容性和完善度。JSR 正在走向成熟。我们最近成立了开放治理委员会，并积极致力于将 JSR 转型为一个独立的、社区驱动的基金会。

我们在 TC39 和 WinterTC（前身为 WinterCG）方面的工作仍在继续。我们还在积极挑战 Oracle 误导性的 JavaScript 商标。所有这些都是我们为改进和发展 JavaScript 生态系统所做的广泛努力的一部分。

我们正在基于从 Deploy 和 KV 中学到的一切构建新产品，这些产品尚未发布。它们旨在使持久化、分布式应用程序更简单。很快将公布更多详情。

我们认识到，我们的沉默有时会成为不确定性的来源，我们致力于在推进这些激动人心的进展的同时改进我们的沟通。

感谢阅读。也感谢所有使用 Deno 进行构建的开发者们：谢谢你们。

– Ryan