Node 的复杂性问题
虽然 Node 今天在网络上无处不在，但它最初并非旨在成为网络的运行时。但它确实满足了 Web 开发者使用 JavaScript *做所有事情* 的日益增长的需求。在 Node（和 npm）不断扩展的范围以服务于这些广泛的用例时，构建一个简单的 Web 应用程序变得负担沉重，充满了不稳定的复杂构建步骤、工具设置、依赖项差异管理以及使用 shims 和 polyfills 来弥合使用 Web 标准 API 之间的差距。
Ryan Dahl 回顾了他在构建 Node 时的遗憾，这些遗憾导致了 Node 今天不必要的复杂状态。
过多的配置
在 Node.js 中启动一个新项目需要几个步骤，然后才能真正开始编程。设置 TypeScript。设置你的测试框架。设置格式化程序。代码检查器。类型检查器。设置你的打包器。添加正确的插件。在选择你的工具之后，调整所有它们的配置文件，使它们能够很好地协同工作。一些 Next.js 项目中有超过 30 个配置文件。
编程应该只是编程本身 —— 而不是在编写一行代码之前配置工具。
与 Web 标准和浏览器 JavaScript 的差异
由于 Node.js 最初是作为事件驱动的、异步 I/O JavaScript 运行时创建的，因此 Web 标准和互操作性不是主要关注点。因此，Node.js 发明了自己的一套 API（例如 fs、path 等），并且它的 JavaScript 风味与现代浏览器中使用的 JavaScript 产生了差异。当使用 Node.js 构建 Web 应用时，这导致了更多的复杂性，因为现在你需要将打包器、源映射器、转译器、shims 等添加到你的工作流程中。
模块加载和解析
Node 的 node_modules 文件夹及其“默认供应商”策略大大复杂化了模块解析算法。有时，不同的包需要其他包的不同版本，从而导致复杂的依赖树，其中循环依赖和对等依赖需要同一依赖项的不同版本。这导致花费时间审核依赖项以及构建时间过长。
npm 的 package.json 的范围随着时间的推移而扩大，今天包含过多的样板代码。在创建 JavaScript 模块时，我们现在需要包含像 LICENSE 信息这样的琐碎细节。如果你想编写和共享一个单文件 JavaScript 程序，你不应该需要填写冗长的问卷。
Deno：一个为 Web *而* 构建的全新开始
我们认识到 Node.js 的这些 “千刀万剐” 的问题，并从头开始重新构想构建 Web 和云软件的现代、高效和简单的方法应该是什么样的。
Deno 是一个单一、简单的系统 —— 而不是像 npm、node-gyp、gulp、grunt、jest 等等这样无数个不同的工具 —— 它提供了你需要的开发工具，无需任何配置，因此你可以直接开始编码。
了解更多关于 Deno 的信息