调查结果与路线图
今年早些时候，我们发布了一项调查，以帮助我们将工作重点放在改进 Deno 运行时上。 感谢超过 700 份回复（感谢填写表格的人！），我们对我们正在取得的进展获得了一些宝贵的见解，并确定了哪些领域需要改进。
以下是从调查中收集到的关键见解的高级摘要，以及我们在 Deno 2 之前的工作重点
我们的 Node/npm 兼容性已经取得了长足的进步
可以理解的是，对于某些人来说，当涉及到使用 Deno 时，无法访问关键的 npm 模块或运行 Node 项目可能会成为一个根本性的障碍，这就是为什么我们花费了巨大的努力来改进 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 云托管提供商包括 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 导入，这与浏览器的运作方式相同。 从理论上讲，这很有道理。 但我们遇到了问题——如果一个程序包含两个模块但版本不同怎么办？ 在模块图中协调这个问题是一个复杂的工程问题，称为重复依赖问题。 我们开发了像 deps.ts 这样的模式来管理远程依赖。 但这仍然不是最优的，需要展平和重新导出必要的符号，从而导致 package.json 的版本更加冗长和混乱。
许多调查受访者都同意依赖管理可以改进，并留言询问关于管理依赖、删除传递依赖、更新依赖等方面的最佳实践。
依赖管理仍然很痛苦，我们正在努力开发一个解决方案，我们希望这个解决方案能够使整个 JavaScript 和 TypeScript 社区受益——一个基于 Web 标准构建的现代注册表。
Deno 2 之路
我们感谢活跃的社区渴望向我们提供反馈并改进 Deno，使其成为默认的 JavaScript 和 TypeScript 运行时。 这次调查的结果不仅强烈表明我们走在正确的道路上，而且还有助于我们将精力集中在对您重要的功能上。
我们的目标是在今年发布一个主要版本，该版本将提供第三方框架兼容性、使用任何 npm 模块的能力，同时拥有最佳的开发者体验。