为什么选择 webpack

要理解为什么要使用 webpack,我们可以回顾一下在打包工具出现之前,我们如何在 Web 上使用 JavaScript。

有两种方法可以在浏览器中运行 JavaScript。首先,为要实现的每个功能包含一个脚本,问题是解决方案难以扩展,因为加载太多脚本会导致网络瓶颈。另一种方法是加载一个包含所有项目代码的大型 .js 文件,但这会导致不可维护的脚本导致在作用域,大小,可读性,脆弱性和整体文件出现问题。

IIFE - 立即调用函数表达式

IIFE 解决大型项目的作用域问题。当脚本文件由 IIFE 包装时,可以安全地连接或安全地组合文件,而无需考虑范围冲突。

这导致了 Make,Gulp,Grunt,Broccoli 或 Brunch 等工具。这些工具称为任务运行程序,除了其他目的之外,它们还用于将所有项目文件连接在一起,以解决之前提到的一些问题。

但是,无论何时想要更改一个文件,都必须重建整个文件。连接使得跨文件重用脚本变得微不足道,并使构建优化更难实现。你怎么知道什么代码被使用,哪些不是?

如果您只使用 lodash 中的一个函数或者来自 moment.js 的一个日期实用程序,那么您实际上是在添加整个库并将它们压缩在一起。你如何树木化你的代码依赖?此外,延迟加载代码块可能难以大规模实现,并且需要开发人员的大量手动工作。

得益于 Node.js,JavaScript 模块诞生了

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

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

CommonJS 出现并引入了 require,它允许你在当前文件中加载和使用模块。这解决了开箱即用的作用域问题以及哪些代码是被使用的变得清晰,因为我们需要导入我们将要用到的每个模块。

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

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

但 CommonJS 没有浏览器支持。没有活动绑定。循环引用存在问题。同步模块分辨率加载器很慢。虽然 CommonJS 是 Node.js 项目的绝佳解决方案,但浏览器并不支持模块。就是在创建像 Browserify,RequireJS 和 SystemJS 这样的捆绑器和工具来解决这个限制时,可以编写在浏览器中运行的 CommonJS 模块。

但是没有对 CommonJS 的浏览器支持。没有实时绑定。循环引用存在问题。同步模块解析加载程序很慢。而 CommonJS 则是 Node.js 项目的绝佳解决方案,但浏览器并不支持模块。这时,创建了 bundlers 和 Browserify、RequireJS 和 SystemJS 等工具来解决这个限制,使编写运行在浏览器中的 CommonJS 模块成为可能。

ESM - ECMAScript 模块

对于 Web 项目来说,好消息是模块正在成为 ECMAScript 标准的一个官方特性,虽然浏览器支持仍然很短,早期实现表明打包仍然更快并为目前所推荐。

岂不更好......

...有一些东西不仅可以让我们编写模块,而且还支持任何模块格式(至少在我们到达 ESM 之前)并且可以同时处理资源和资产。

这就是 webpack 存在的原因。它不仅可以打包你的 JavaScript 应用程序,支持 ESM 和 CommonJS,还可扩展为支持所有不同类型的资源,如图像、字体和样式表。

webpack 非常关注性能,它总是在添加和改进功能,比如异步块加载和预取等,以帮助你将最佳版本的项目交付给用户,始终关注加载时间和性能。