前端生態系統的復雜性是出了名的。在每一層，似乎都存在著不兼容的，相互競爭的標準。
沒有通用的導入系統。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
