调查结果和路线图
今年早些时候，我们发布了一份调查，以帮助我们集中精力改进 Deno 运行时。在收到 700 多份回复（感谢填写表格的所有人！）之后，我们对我们正在取得的进展获得了一些宝贵的见解，也确定了哪些领域需要改进。
以下是调查中收集的关键见解的高级总结，以及我们在 Deno 2 之前集中精力的方向。
我们的 Node/npm 兼容性已经取得了长足的进步
可以理解的是，对于某些人来说，无法访问关键的 npm 模块或运行 Node 项目可能是使用 Deno 的一个障碍，这就是为什么我们在改进 Node 和 npm 兼容性方面付出了巨大的努力。好消息是，最近的调查中大多数受访者表示，基于现有的兼容性水平，Deno 已经走在了成为所有项目的默认运行时的道路上。然而，结果表明，在这方面，我们需要进一步努力才能达到我们的目标。
在接下来的几个月里，我们将重点关注改进 Node 和 npm 的兼容性，特别是围绕
- 识别并修复错误
- 添加 Node API 填充
我们的目标是让任何 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 项目的主要云提供商。
其他提到的用于托管 Deno 项目的云托管提供商包括 AWS、Vercel、GCP 和 Digital Ocean。虽然我们有关于使用 Deno 与deno_docker 托管到 VPS 托管提供商的教程，但我们认识到，还需要做更多工作才能确保更流畅的端到端自托管体验。
为此，我们最近添加了Arm64 Linux 支持，并成为deno-lambda 的积极维护者，以创建 AWS Lambda 的 Docker 镜像。在接下来的几个月里，我们将专注于创建
- 用于构建各种 Deno 应用程序的 Docker 容器的最佳实践
- 使用 CloudFormation/Terraform 模板在 AWS ECS 和 Lambda 上编写 Deno 服务的指南
在托管 Deno 时遇到问题，或者需要有关如何为您的项目托管 Deno 的指导？在这里告诉我们.
对依赖项管理进行重大升级
Deno 推出了一个全新的 URL 导入概念，这与浏览器的运作方式一致。从理论上讲，这是合理的。但我们遇到了问题 - 如果一个程序包含两个模块，但版本不同怎么办？在模块图上协调这一点是一个复杂的工程问题，称为重复依赖问题。我们已经开发出了像 deps.ts 这样的模式来管理远程依赖项。但这仍然不是最佳方案，需要扁平化和重新导出必要的符号，从而导致更冗长和混乱的 package.json 版本。
许多调查受访者同意依赖项管理可以改进，并留下了一些评论，要求提供有关管理依赖项、消除传递依赖项重复、更新依赖项等的最佳实践。
依赖项管理仍然很痛苦，我们正在努力寻找一个可以惠及整个 JavaScript 和 TypeScript 社区的解决方案 - 一个基于 Web 标准的现代注册表.
通往 Deno 2 的道路
我们感谢一个积极的社区，他们渴望给我们反馈并改进 Deno，使其成为默认的 JavaScript 和 TypeScript 运行时。这份调查的结果不仅表明我们走在了正确的道路上，而且还有助于我们集中精力在对您重要的功能上。
我们计划今年发布一个主要版本，它将提供第三方框架兼容性，以及使用任何 npm 模块的能力，同时提供一流的开发体验。