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