网站开发需要了解我们为什么需要前端工具、它所经历的各个演变阶段，以及将塑造未来前端构建工具的新发展，我们有必要对网站上的现代前端开发有一个大致的了解。
前端构建工具对于现代前端开发人员的工作流程至关重要，原因有很多，归类为改进的开发人员和用户体验。从开发人员的角度来看，前端工具为我们提供了：编写模块的能力、用于本地开发的开发服务器、用于在开发模式下缩短反馈循环的热模块替换 (HMR)、使用 polyfill 定位旧版浏览器的能力、处理主机的能力除了 JavaScript 之外的文件类型，这个列表还在继续。因此，用户可以享受功能更强大、功能更丰富的应用程序，这些应用程序通过代码拆分、缓存、预取和其他资源优化技术等技术保持高性能——有些应用程序甚至可以离线工作。
在前端应用程序变得像今天这样复杂之前，所有 JavaScript 的用途都是为原本简单的 HTML 文档添加基本的交互性——类似于使用 Adobe 的 Flash 的方式。没有复杂的“JavaScript-heavy”应用程序，因此，不需要任何工具来更好地编写和发布 JavaScript，但情况并非如此。随着时间的推移，我们开始在 Web 上创建更多参与的用户体验，我们从更多的静态网页转向为用户特定数据提供服务的高度动态的 Web 应用程序。这些应用程序比传统应用程序需要更多的 JavaScript，并且使用 JavaScript 的局限性变得更加明显。
当您要加载大量 JavaScript 时，加载 JavaScript 的这种限制会成为瓶颈。同时加载多个 JavaScript 文件存在浏览器限制，并且拥有一个巨大的 JavaScript 文件存在可维护性问题（如文件大小、范围问题、命名空间冲突等）。我们提出了诸如立即调用函数表达式 (IIFE) 之类的解决方案，以帮助解决封装和一些范围问题，之后，我们获得了在许多不同文件中编写 JavaScript 的能力。然后，我们需要一种方法将这些文件合并为一个文件，以便在浏览器中提供服务。
能够使用 IIFE 将我们的 JavaScript 拆分为不同的文件，似乎我们所需要的只是一种连接这些文件并将单个文件发送到浏览器的方法。这种需求见证了 Gulp、Grunt、Brocolli 等工具的兴起。然而，我们很快意识到我们的想法可能有点过于简单化了。随着我们的应用程序变得更加复杂，诸如缺少死代码消除、针对小更改进行完全重建以及其他性能问题等问题使我们意识到我们需要的不仅仅是串联。这催生了更现代的打包工具，如 Webpack、Parcel 等。
JavaScript 生态系统中事物变化的速度通常令人疲倦，但好处是社区可以快速发现问题并着手寻找潜在的解决方案。随着我们着眼于提高前端工具的性能，正在开发新一代的构建工具。当今主流构建工具的局限性导致人们多次尝试重新构想前端构建工具应该是什么和做什么，并且今天有很多新的构建工具。仔细观察会发现，这些新工具似乎采取了两种主要方法来解决问题（不一定相互排斥）：范式变化和平台变化——两者都由 Web 开发生态系统的新进展提供支持。
前端构建工具传统上是使用 JavaScript 构建的，最近又使用 Typescript。这是有道理的，因为 JavaScript 是 Web 的语言，使用同一种语言为 Web 编写构建工具可以让更多人更轻松地为工作做出贡献并围绕这些工具构建社区。尽管如此，这种方法仍然存在固有的问题。作为一种高级语言，JavaScript 无法达到本机级别的性能。这意味着建立在这个平台之上的工具对它们的性能有一个上限。因此，为了突破这一限制，更新的构建工具正在构建在较低级别、本质上更高性能的语言（如 Rust）上。
