先来说一下 webpack 是什么。

webpack 的官方对它是这样定义的：

中文的大概意思是说：

用大白话可以这样说：

如果这样还不明白的话，我们来说下前因后果。

举个例子，很多人开发了各种优秀的 JavaScript 模块或组件，我们不想重复发明轮子，而是想直接利用别人的模块，就是类似 require 或 include 这样的机制，把别人的模块引入进来，但是 JavaScript 又没有 类或包 这样的概念，那应该如何做呢？

如何去引入别人的模块？引入之后保证各种依赖关系不出错？这就是 webpack 要解决的问题。

模块化的概念我们理解了，那如何理解 这个词呢？

其实，模块化的问题解决之后，webpack 就能把各种资源模块打包合并成一个文件输出给浏览器。在打包的过程中还能对这些资源进行处理，比如压缩减少体积，把 sass 编译成 css, coffee 编译成 js。所以它在某些程度上，跟 grunt/gulp 的功能有些相同。至于与 grunt/gulp 的不同之处，我们下面会讲到。

grunt/gulp 的定义是 Task Runner。它有点像 ruby 的 Rake或 Thor，如果你不懂 ruby，那 c/cpp语言的 make，这应该总知道吧。它是一种写任务的工具，只是 grunt/gulp 是用 JavaScript 来写 task 而已。

grunt/gulp 强调的是前端开发的工作流程，我们可以通过配置一系列的 task，定义 task 处理的事务（例如文件压缩合并、雪碧图、启动 server、版本控制等），然后定义执行顺序，来让 grunt/gulp 执行这些 task，从而构建项目的整个前端开发流程。

打个比方，如果你的工程模块依赖很简单，不需要把 js 或各种资源打包，只需要简单的合并、压缩，那就不需要 webpack。grunt/gulp 就够用了。反过来，如果你的工程庞大，页面中使用了很多库（SPA很容易出现这种情况），那就可以选择使用 webpack，因为这样既能做到模块化管理，也能做到 grunt/gulp 的一些功能，比如压缩，转化 coffeescript 为 js 等。

虽然都是前端自动化构建工具，但看他们的定位就知道不是对等的。

grunt/gulp 严格上讲，模块化不是他强调的东西，他旨在规范前端开发流程。

webpack 更是明显强调模块化开发，而那些文件压缩合并、预处理等功能，不过是他附带的功能。

webpack 与其和 grunt/gulp 相比较，还不如跟 Browserify 比较，因为它们两者更相近，不过好像 Browserify 应该被 webpack 代替了吧，我对 Browserify 了解也不多，在此就不细说了。

1. webpack 不仅仅能处理 js, 也能处理 css, 也能处理 html，甚至是图片等各种前端资源。

2. 扩展性强，插件机制完善。

现在最流行的 react、vue、angular 等技术，你要学习和使用它们，难免会碰到 webpack，因为一般都会用 webpack 来构建前端的开发环境，这样，我们还有什么理由不学习呢？