调查结果与路线图
今年早些时候，我们发布了一份调查问卷，旨在帮助我们集中精力改进 Deno 运行时。我们收到了 700 多份回复（感谢所有填写表格的用户！），从中获得了关于我们所取得进展的宝贵见解，并确定了需要改进的领域。
以下是本次调查收集到的主要见解的概要，以及我们在 Deno 2 发布前将重点关注的领域
我们的 Node/npm 兼容性已取得长足进步
可以理解，对于一些用户来说，无法访问关键的 npm 模块或运行 Node 项目可能是阻碍他们使用 Deno 的原因，因此我们投入了巨大的精力来改进 Node 和 npm 的兼容性。好消息是，最近调查中的大多数受访者表示，基于现有兼容性水平，Deno 已经有望成为他们所有项目的默认运行时。然而，结果也表明，在此方面我们仍需努力，直到我们满意为止。
在接下来的几个月里，我们将高度关注 Node 和 npm 兼容性的改进，特别是围绕以下方面：
- 识别并修复错误
- 推出更多 Node API polyfill
我们的目标是使任何 npm 模块都能与 Deno 配合使用，同时消除使用 npm 与 Node 配合时的诸多不便。我们旨在通过减少配置文件和简化依赖管理步骤，提供整体上更好的开发体验。
框架兼容性同样重要
除了能够使用 Deno 访问 npm 模块外，我们还询问了运行第三方框架的重要性。约 80% 的受访者表示第三方框架兼容性对其工作至关重要。
虽然大多数受访者表示在使用 Deno 与第三方框架时没有遇到问题，但有一部分人指出他们遇到了痛点，因此我们将把第三方框架兼容性作为 2024 年的首要任务。
虽然许多框架已经得到 Deno 的支持（例如 React、Express.js、Qwik），但我们承认有些框架尚未完全支持，或者在使用 Deno 时开发者体验不尽理想。我们决心改进框架兼容性，以确保在 Deno 2 发布前提供一流的开发者体验，例如支持 Next.js。
随时随地部署 Deno
使用 Deno 构建服务器和 API 仍然是主要用例，因此许多用户在云端托管 Deno 也就不足为奇了。我们很高兴得知，当被问及在云端托管 Deno 项目是否容易时，近半数受访者选择了“非常同意”。
那么大多数用户在哪里托管 Deno 项目呢？超过 50% 的用户使用 Deno Deploy（我们全球分布的 v8 隔离云）进行托管，但我们也看到其他云服务提供商有显著的使用量。
托管 Deno 项目的主要云服务提供商。
其他提及的 Deno 云托管服务提供商包括 AWS、Vercel、GCP 和 Digital Ocean。虽然我们提供了使用 deno_docker 将 Deno 托管到 VPS 服务提供商的教程，但我们认识到要确保更顺畅的端到端自托管体验，还有更多工作要做。
为此，我们最近添加了 Arm64 Linux 支持，并成为 deno-lambda 的活跃维护者，以创建用于 AWS Lambda 的 Docker 镜像。在接下来的几个月里，我们将专注于创建
- 为各种 Deno 应用构建 Docker 容器的最佳实践
- 在 AWS ECS 和 Lambda 上编写 Deno 服务的指南，包含 CloudFormation/Terraform 模板
在托管 Deno 时遇到问题，或者需要关于如何为您的项目托管 Deno 的指导？请在此处告知我们。
依赖管理迎来重大升级
Deno 最初采用了 URL 导入这一激进理念，这与浏览器的工作方式一致。理论上这很有道理。但我们遇到了问题——如果一个程序包含两个不同版本的模块怎么办？在模块图中协调这种情况是一个复杂的工程问题，称为重复依赖问题（Duplicate Dependency Problem）。我们开发了诸如 deps.ts 这样的模式来管理远程依赖。但这仍然不是最佳方案，需要平铺和重新导出必要的符号，导致 package.json 的版本更冗长、更杂乱。
许多调查受访者都认为依赖管理可以改进，并留言询问关于依赖管理、去重传递依赖、更新依赖等方面的最佳实践。
依赖管理仍然令人头痛，我们正在努力开发一个有望造福整个 JavaScript 和 TypeScript 社区的解决方案——一个基于 Web 标准构建的现代化注册表。
Deno 2 之路
我们非常感谢活跃的社区乐于向我们提供反馈，并帮助 Deno 发展成为默认的 JavaScript 和 TypeScript 运行时。本次调查的结果不仅强烈表明我们走在正确的道路上，也帮助我们将精力集中在对您而言重要的功能上。
我们今年的目标是发布一个主要版本，该版本将提供第三方框架兼容性，支持使用任何 npm 模块，同时带来一流的开发者体验。
有问题？有评论？请在 Twitter 或 Discord 上告知我们。