前端生态系统的复杂性是出了名的。在每一层，似乎都存在着不兼容的，相互竞争的标准。

没有通用的导入系统。ES模块、CommonJS、异步模块定义（AMD）和通用模块定义（UMD）都是你可以导入或分享代码的不同方式。打包器试图通过支持多种方法来解决这个问题。但是代码经历了多层的压缩、混淆和转译。TypeScript被编译成JavaScript。网络上的代码会被压缩（以减少网络带宽）或混淆（以防止复制）。源映射可以解决其中一些问题，但这又是另一项需要配置的事情。获取正确的堆栈跟踪可能会很棘手。这需要语言、工具和运行时之间的协调。

极其不同的环境。一个特性和一个错误。前端代码预期在任何地方运行 - 不仅仅是浏览器。在不同环境中可用的上下文和API各不相同，很难知道你有哪些可用的上下文（更不用说知道你正在导入的库假设了什么）。这段代码能在服务器上运行吗？这段代码能在客户端上运行吗？这对开发者来说很困难（我可以使用什么代码）对于库维护者来说也很困难（我应该为哪些环境优化我的代码？）。

过度强调文件结构。太多的前端工具依赖于项目结构来进行行为设定。配置必须在项目的根目录中（导致了一长串的tailwind.config.js、postcss.config.js、eslint.config.js、next.config.js等）。文件结构对于导入代码是必要的恶，但在前端中，它却做了更多的事情。它可能是一个API，用于将特定文件路由为网页，或者作为API，或者作为静态网页，或者作为动态重新生成的网页。这些都很方便，但有时候很难调试，也很难发现代码库的部分内容。

配置地狱。开箱即用的工具有很多。长期以来，我们有create-react-app，这是一个被赞誉的工具包，它集成了许多这样的工具，从一开始就为开发者提供了一个可用的配置。但是，如果你偏离了这条黄金路径，你就会被20多个开发工具和复杂的交互所困扰。几乎每个工具都在与其他工具争斗。ESLint（代码检查工具）和Prettier（代码格式化工具）经常发生冲突。

开发失衡。在代码和部署之间有如此多的步骤，意味着热重载开发往往复杂。这导致了像webpack-dev-server这样的工具的出现，它为你处理了大部分问题。但是要警惕魔法。这些开发服务器中有太多的假设，它们可能会迅速偏离生产行为。

原文：https://matt-rickard.com/why-is-the-frontend-stack-so-complicated

作者：Matt Rickard