Deno 2.3 发布，改进了 deno compile、本地 npm 包等功能 🚀

最近出现了一些关于 Deno 的批评——关于 Deploy、KV、Fresh 以及我们整体发展势头的批评。你可能已经在网上看到了一些，并在常去的地方传播开来，引起了不少关注。

其中一些批评是合理的。事实上，我认为可以公平地说，我们因为对正在做的事情，以及公司和产品的未来方向保持沉默，而造成了一定程度的恐慌和不确定性。这是我们的责任。

在其他方面，最近的批评是不准确或推测性的。这就是我们撰写这篇文章的原因：为了澄清事实。本文将介绍我们目前的状况、我们所学到的东西，以及我们接下来要构建的内容。有些人担心 Deno 本身正在衰落或消失，但这与事实相去甚远。自从去年 10 月发布 Deno 2 以来——仅仅六个多月！——根据我们的月活跃用户指标，Deno 的采用率已经翻了一番以上。Deno 2 强大的 Node 兼容性有效地消除了一个主要的采用障碍，解除了各种严肃用例的限制。该平台变得更快、更简单、更强大。现在，Deno 的使用比以往任何时候都更广泛、更认真。

Deno Deploy

我们听到的最大的问题之一是关于 Deno Deploy——特别是可用区域的减少。虽然我们理解这种缩减规模的表面现象，但其原因并非通常担心的那样。

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

我们在 2021 年推出了 Deno Deploy，以探索 serverless JavaScript 的新模型。它最初在 25 个区域启动，增加到 35 个，现在在 6 个区域运行。这种减少确实是受成本驱动的——但也受使用情况驱动。大多数开发人员没有部署简单的无状态函数。他们正在构建完整的应用程序：与数据库通信的应用程序，该数据库几乎总是位于单个区域中。我们发现，大多数时候，多余的区域基本上没有被使用。当流量高峰到来时，空闲区域会迅速达到容量，导致延迟高峰。我们发现，路由到更远更大的区域通常比在附近冷启动的区域运行更快。

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

Deno Deploy 正在进行大量开发——我们尚未发布最新版本，但即将发布。你可以在此处申请提前访问。

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

很快，你将能够将你的应用程序固定到一个区域——或者在你自己的云中运行它。这是我们从关心控制、合规性和性能的用户那里一次又一次听到的。更多信息即将推出。

KV

Deno KV 是我们的零设置、全局一致的键值存储，具有简单的 API 和实时功能。我们意识到，对于会话数据、功能标志和协作状态等内容，KV 非常有效。开发人员喜欢它的优点：一个开箱即用的零配置全局存储。

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

鉴于这些新方向，Deno KV 将继续保持 beta 状态。我们将继续解决当前版本的关键错误和安全问题。虽然 KV 对于其预期的目的很有用，但它的作用不是作为 Deno 中所有状态管理的核心或发展中的解决方案。我们保留在未来对 Deno KV 进行重大更改的权利，因为这些其他状态计划会成熟，并且我们的整体平台战略会不断发展。我们很高兴能尽快分享有关这些新的 pipeline 项目的更多信息。

Fresh

Fresh 仍然活跃且运行良好——它为我们构建的每个应用程序和网站提供支持。我们知道你们中的许多人一直在热切期待 Fresh 2，也许有些人对等待感到沮丧。我们听到了。我们可以更快地发布一些东西，但必须把基础知识做好，我们不想为了快速的营销宣传而牺牲质量。我们所有的网站都依赖 Fresh，因此其卓越性至关重要。我们刚刚撰写了一篇详细的文章，介绍了 Fresh 2 中即将进行的重大改进——快去阅读吧！稳定版本将于今年晚些时候发布。

Deno, the runtime platform

Deno 不再只是一个 runtime；它是一个用于构建和运行 JavaScript 系统的完整平台。以下是内置的内容：

你可以使用单个工具链编写、运行、测试、部署和监控。我们一直在加强集成。更少的 flags，更好的默认值，更小的差距。各个部分比以往任何时候都更好地协同工作。

我们没有在与其他 runtime 争夺特性 parity，我们正在构建一个有凝聚力的系统。我们正在努力从根本上改进 JavaScript 开发。如果我们有错，那是因为我们在这个目标上走得太远了。但我认为没有人可以争辩说 Deno 没有为世界上默认的编程语言争取更好的世界。

我们为什么这样做

对于一大类问题，脚本语言是符合人体工程学的最终状态：工程时间是限制因素的业务逻辑。

Ruby、Python、Lua、Perl 和 JavaScript 都遵循这一思路。但 JavaScript 是在每个设备上分发的，具有标准机构、跨技术集团的独立实现以及庞大而充满活力的生态系统。我们认为，具有未来的脚本语言是 JavaScript（和 TypeScript）。它应该有一个与之匹配的平台，而不是 ad hoc 工具的拼凑。一个单一的、包含所有功能的系统。

正如 JavaScript 为你提供垃圾回收和内置数组一样，Deno 为你提供权限系统、web 服务器、可观察性、linting 和类型安全性——所有这些都是开箱即用的。你不需要将它们粘合在一起。Deno 就是胶水。

展望未来

我们没有在收缩，我们正在蓄势待发。

我们将继续提高整个平台的性能、兼容性和 polish。JSR 正在成熟。我们最近成立了一个开放治理委员会，并正在积极努力将 JSR 转变为一个独立的、社区驱动的基金会。

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

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

我们认识到，我们的沉默有时是不确定性的来源，我们致力于在推进这些令人兴奋的开发时改进我们的沟通。

感谢阅读。并感谢每一位使用 Deno 构建项目的人。

– Ry