为什么选择 webpack

为了理解为什么要使用 webpack，让我们回顾一下在捆绑器出现之前如何在 Web 上使用 JavaScript。

在浏览器中运行 JavaScript 有两种方法。首先，为每个功能包含一个脚本；这种解决方案难以扩展，因为加载太多脚本会导致网络瓶颈。第二种选择是使用包含所有项目代码的大型 .js 文件，但这会导致作用域、大小、可读性和可维护性问题。

IIFE - 立即调用函数表达式

IIFE 解决了大型项目的范围问题；当脚本文件被 IIFE 包裹时，可以安全地连接或组合文件，而无需担心范围冲突。

IIFE 的使用导致了 Make、Gulp、Grunt、Broccoli 或 Brunch 等工具的出现。这些工具被称为任务运行器，它们将所有项目文件连接在一起。

但是，更改一个文件意味着必须重新构建整个文件。连接使跨文件重用脚本变得更容易，但使构建优化更加困难。如何才能知道代码是否真的被使用？

即使只使用 lodash 中的单个函数，也必须添加整个库，然后将其压缩在一起。如何对代码的依赖项进行树摇？延迟加载代码块在规模上很难实现，并且需要开发人员进行大量手动操作。

JavaScript 模块的诞生得益于 Node.js

Webpack 运行在 Node.js 上，Node.js 是一个 JavaScript 运行时，可以在浏览器环境之外的计算机和服务器上使用。

Node.js 发布后，一个新时代开始了，它带来了新的挑战。现在 JavaScript 不再在浏览器中运行，Node 应用程序如何加载新的代码块？没有可以添加到其中的 html 文件和脚本标签。

CommonJS 出现了，它引入了 require，允许你在当前文件中加载和使用模块。这通过按需导入每个模块来立即解决范围问题。

npm + Node.js + 模块 - 大规模分发

JavaScript 正在以一种语言、一个平台以及一种快速开发和创建快速应用程序的方式接管世界。

但是，浏览器不支持 CommonJS。没有实时绑定。循环引用存在问题。同步模块解析和加载速度很慢。虽然 CommonJS 是 Node.js 项目的绝佳解决方案，但浏览器不支持模块，因此创建了像 Browserify、RequireJS 和 SystemJS 这样的捆绑器和工具，使我们能够编写在浏览器中运行的 CommonJS 模块。