前端构建工具之争——Webpack vs Gulp 谁会被拍死在沙滩上

阅读目录

• 理想的前端开发流程
• Gulp 为什么物
• webpack 又是从哪冒出来的
• 结论

文章有点长，总共 1800 字，阅读须要 18 分钟。哈哈，没耐心的直接戳我到高潮部分。

理想的前端开发流程

在说构建工具以前得先说说咱指望的前端开发流程是怎样的？

• 写业务逻辑代码（例如 es6，scss，pug 等）
• 处理成浏览器认识的（js，css，html）
• 浏览器自动刷新看到效果

前端开发就是在不断的 123..123..123.... 循环中进行的，上面的后两步（也就是 2 和 3）应该是 自动化 的，前端开发者理应只需关注第 1 步——写业务逻辑代码。

自动化的事情应该交由构建工具来作，时下流行的前端构建工具备 gulp 和 webpack（有人说 webpack 不算是构建工具，我以为这没什么好争的。横当作岭侧成峰，我以为从当前 webpack 所能作的事情来看，说它是构建工具丝绝不为过）。本文不会对 gulp 和 webpack 的概念和内容作深刻解析，而是但愿从宏观的角度研究他们的优点短缺和适用场景，从而说清长期弥漫在前端圈两者之间扑朔迷离的关系。

什么是构建工具
构建工具是一段自动根据源代码生成可以使用文件的程序，构建过程包括打包、编译、压缩、测试等一切须要对源代码进行的相关处理。构建工具的目的是实现构建过程的自动化，使用它可让我们避免机械重复的劳动（这怕是程序员最不能忍受的了），从而解放咱们的双手。

解放了双手干什么
哇槽，爱干什么干什么。

Gulp 为什么物

先来听听 Ta 的官网是怎么说：

Gulp 致力于 自动化和优化 你的工做流，它是一个自动化你开发工做中 痛苦又耗时任务 的工具包。

想想我们平常的开发工做中痛苦又耗时任务有哪些呢？

• 用 es6，typescript 编写的脚本文件须要编译成浏览器认识的 javascript
• 用 scss，less 编写的样式文件须要编译成浏览器认识的 css
• 检查代码是否符合书写规范，跑单元测试和集成测试
• 开发环境若是有 sourcemaps 的话调试起来就方便多了，修改完代码浏览器能自动刷新当即看到效果就更好了
• 生产环境部署代码须要压缩合并静态文件，添加文件指纹控制缓存
• blabla...更多的你本身想吧

Gulp 声称要帮我们实现 自动化，那他是怎样帮助我们实现自动化的呢？这就不得不先提一嘴牛逼哄哄的 NodeJS。

Node 背景小知识

Node 使前端 Jser 有了脱离浏览器工做的能力，要搁之前的话我们写的 js 要么嵌到 html 页面里，而后用浏览器打开 html 页面才能运行js，要么就是在浏览器开发者工具的 Console 面板里编写运行代码片断。总之没了浏览器这个宿主，我们的 js 就 run 不起来。Node 这货突发奇想，把开发者工具的 Console 给抠下来了，今后 js 能够脱离浏览器直接在 node 里运行。至关于 js 如今有了两个宿主环境，一个是浏览器，一个是 node。固然了，Node 可不是开发者工具里的 Console，那只是打个比方。它是基于Chrome V8 引擎实现的一个 JavaScript 运行环境，功能其实相似 Console 面板，但提供了大量实用的 API，感兴趣的同窗可前往 Node官网 详细了解，英文吃力的骚年 戳这里。Node 能够算是前端革命式的创新，随 node 一块儿发布的 node 包管理器 npm(node package manager) 也已是全球最大的开源库生态系统。node/npm 这对组合一出，前端生态迎来了大爆发，一时间为解决各类问题的 node 包层出不穷，遍地开花。gulp 就是披荆斩棘，一路过五关斩六将闯出来的一个小 node 包。

扯谈完毕，接下来就来看看 gulp 是否是在装逼，他到底能不能帮咱们实现自动化。

做为一个 node 包，标准打开方式固然是：

npm i -g gulp

而后呢，这里以编译 less 为例，首先安装编译 less 须要用到的 node 包：

npm i --save-dev gulp gulp-less

前面已经全局安装过 gulp 了，怎么又本地安装了一遍
前面的 -g 是全局安装，是为了执行你所编写的 gulp 任务，即 gulp yourTask。然后面的 --save-dev 是本地安装，是为了我们编写任务时使用 gulp 提供的 api，例如 gulp.src()、gulp.task()、gulp.dest() 等等。固然也是能够直接使用全局安装的 gulp 的 api 的，可是强烈不推荐，由于这样涉及到 gulp 版本控制的问题，并且使用全局 gulp 的 api 的话就会产生环境依赖（你假设环境已经全局安装了gulp，万一没装呢，程序不就出错了）。

接着在项目的根目录下新建一个 gulpfile.js 文件，这是 gulp 的默认配置文件。

gulpfile.js 必须放在项目根目录？
固然也可放在其余目录，但这样的话就得在启动 gulp 任务时手动指定 gulp 配置文件 gulp yourTask --gulpfile yourGulpfilePath，可能还须要全局安装 gulp-cli，因此除非有特殊须要，不然就放在项目根目录就好了，这样最简单。

配置文件的名字必须是 gulpfile.js 吗？
不区分大小写，取成 gULPFile.js 的话 gulp 也能认识，只要 toLowerCase 以后是 gulpfile 就好了，若是取其它名字那你就又得使用 --gulpfile 选项去指定了。

如今工程目录结构已经成了下面的样子：

构建前 gulp 工程目录结构

接下来就是在 gulpfile.js 里编写 gulp task（gulp 把为每一个痛苦又耗时任务编写的处理方法称为一个 task）：

const gulp = require('gulp');
const less = require('gulp-less');

gulp.task('build:less', function(){
    return gulp.src('./src/*.less')
        .pipe(less())
        .pipe(gulp.dest('./dist'));
});

最后就是打开一个终端，在终端里运行 gulp build:less。好了，编译后的文件已经被输出到了 dist 目录：

构建后 gulp 工程目录结构

至此你已经算是一个 gulp 砖家了，这基本上就是 gulp 的所有内容。怎么样，是否是够简单，够丝滑。这也是 gulp 的突出特色——易于学习，易于使用，五分钟成砖家。若是想要执行解决其余痛苦又耗时的任务，只需下载安装对应的 gulp 插件包，而后依次类推写一个 gulp.task 出来就好了。

这些源代码具体是怎样被处理的
这一般不须要关心，由于 gulp 插件包已为你作好了，而且封装的很是漂亮，你只须要告诉 gulp 你要什么，gulp 及其插件会帮你打点好一切。这就比如你把一份电子文档传进打印机，告诉它我要一份 A4 纸打印，呲呲呲~，打印机就吐出来一张 A4 纸，上面是你的文档内容。源代码就是你的电子文档，gulp 插件就是打印机，生成的可用文件就是你手里的那张 A4 纸，你不用关心打印机内部是怎样工做的，由于它封装的很好，或者你能够把打印机拆了一探究竟也行。

Gulp 是基于流的？
流（Stream）不是 gulp 创造的概念，而是从 unix 时代就开始使用的 I/O 机制，一直到如今仍在普遍使用。Node 封装了一个 stream 模块专门用来对流进行操做。gulp 所基于的流便是 Node 封装起来的 stream。上面 gulp.task() 代码里面的 pipe 方法并非 gulp 提供的 api，而是 node 的 api，准确的说应该是 node 的 stream 模块提供的 api。具体是怎么实现的呢：gulp.src() 的返回值是 node Stream 的一个实例，以后的 pipe 调用的实际上是这个实例的 pipe 方法，而 pipe 方法的返回值依然是 node Stream 实例，以此实现前面的 .pipe().pipe().pipe() 这种串联写法。熟悉 jQuery 的同窗应该很清楚这种技巧。

webpack 又是从哪冒出来的

gulp 彷佛是完美的，对前端开发工做中每一项痛苦又耗时任务都能见招拆招，各个击破。然而前端发展速度之快超乎想象，对页面性能和用户体验更是追求极致，以致于 gulp 某些领域尤为大型 SPA（单页应用）显得有些不够用了：

• 单页应用的核心是模块化，ES6 以前 JavaScript 语言自己一直是没有模块系统的，致使 AMD，CMD，UMD 各类轮子模块化方案都蹦出来。对这种模块化乱象，gulp 显得无能为力，gulp 插件对这一块也没有什么想法。不过也能够理解，模块化解决方案可不是谁都能 hold 住的，须要考虑的问题太多了；
• 对前沿的 SPA 技术 gulp 处理起来显得有些力不从心，例如 Vue 的单文件组件，gulp 配合一些插件能够勉强处理，可是很蹩脚。其实归根结底，仍是模块化处理方面的不足；
• 优化页面加载速度的一条重要法则就是减小 http 请求。gulp 只是对静态资源作流式处理，处理以后并未作有效的优化整合，也就是说 gulp 忽略了系统层面的处理，这一块还有很大的优化空间，尤为是移动端，那才真的是一寸光阴一寸金啊，哪怕是几百毫秒的优化所带来的收益（用户？流量？付费？）绝对超乎你的想象。别跟我说 gulp-concat，CSS Sprites，这俩玩意儿小打小闹还行，赶上大型应用根本拿不上台面。如今的页面动辄上百个零碎资源（图片，样式表，脚本），也就是上百个 http 请求，所以这个优化需求仍是至关迫切的。关于为什么减小 http 请求能够有效下降页面加载时间戳这里。
• blabla... 你本身想吧，主要就是大型单页应用方面有短板；

时势造英雄。webpack 一声吼，大张旗鼓地挖起了gulp 的墙角。

老规矩，先看看webpack官网怎么吹牛逼介绍本身的：

Webpack 是当下最热门的前端资源模块化 管理和打包 工具。它能够将许多松散的模块按照依赖和规则打包成符合生产环境部署的前端资源。还能够将按需加载的模块进行代码分割，等到实际须要的时候再异步加载。

是否是看完一脸懵逼，不明觉厉。其实翻译过来就是 “在我眼里，什么都是模块”。webpack “万物皆模块” 的理念和 SPA 配合起来简直是金童玉女，天做之合。这也是 webpack 短期内名声大噪，直接撼动 gulp 地位的主要缘由。

webpack 的理念比较前卫，它自己也带来了不少新的概念和内容，诸如加载器（loader）、依赖图（Dependency Graph）等等。和 gulp 两小时成砖家的学习难度相比，webpack 或许你研究两天仍然会晕头转向。

接下来简单看一下 webpack 的主要工做方式。

webpack 和 gulp 同样也是一个小 node 包，打开方式天然是：

npm i -g webpack
npm i --save-dev webpack

和 gulp 同样，全局安装是为了执行 webpack 任务，本地安装是为了使用 webpack 提供的 api。

安装完 webpack 以后在项目根目录下新建一个 webpack.config.js，这是 webpack 的默认配置文件，同 gulp 的 gulpfile.js 的功能相似。webpack.config.js 一样是不区分大小写的，取成 webPACk.CONfig.js 的话 webpack 也能认识，可是取成其余名字或放在别的目录就须要使用 --config 选项去指定配置文件了。

如今工程目录结构以下：

构建前webpack工程目录结构

接下来就是在 webpack.config.js 里配置须要的选项，注意了，webpack 与 gulp 的重要不一样就是使用方式 由编程式变成了配置式：

const path = require('path');

module.exports = {
    entry: './src/index.js',        // 告诉 webpack 你要编译哪一个文件
    output: {                       // 告诉 webpack 你要把编译后生成的文件放在哪
        filename: 'bundle.js',
        path: path.join(__dirname, 'dist')
    }
};

最后仍然和 gulp 相似，就是在终端里运行 webpack（终端里通常会出现一大坨编译信息）。好了，如今 webpack 已经把编译好的文件输出到了 dist 目录：

构建后webpack工程目录结构

看到这是否是已经一头雾水了，在你还没明白发生了什么的时候 webpack 已经把事情干完了。这也是 webpack 和 gulp 做业方式的重要不一样：Gulp 是搭了个台子，让 gulp 插件在上面唱戏，尽情表演，全部构建相关的具体事情都交由 gulp 插件去作。而 Webpack 就牛逼了，webpack 先搭了个台子，而后本身在上面唱嗨了，仔细一听，他在上面唱的是《咱们不同》，固然了他也是让 webpack 插件在上面唱戏的。

也就是说 webpack 把不少功能都封装进了本身身体里面，使得本身强大同时臃肿。如今你能够在 ./src/index.js 文件里直接写 ES6 代码，由于 webpack 把编译 ES6 的工做已经封装到本身的实现里了，使得 webpack 看起来原生支持 ES6 而不须要借助第三方插件，其实他内部也是用了第三方插件的，因此你不用再专门去下一个 babel 之类的插件去转译 ES6。这样封装的好处是使用起来很方便，很差的地方就是使用者彻底不知道发生了什么，构建完了还一脸懵逼。

上面仅是 webpack 使用的最最最简单示例，简直连 “hello world” 都算不上。具体怎样打包各类资源（typescript，样式表，图片，字体等等）可前往 webpack官网 深刻学习，想看中文的同窗使劲 戳这里。

webpack “一切皆模块” 的特色完美解决了上面 gulp 暴露的几个短板，连 webpack 官网也说本身是由于看到现存的模块打包器都不太适合大型 SPA 应用，因而决定打造一个适合大型 SPA 应用的模块打包器，也就是说 webpack 其实就是为大型 SPA 而生的。

webpack 怎么实现像 gulp 同样对大量源文件进行流式处理
人家 webpack 原本就没打算作这事。webpack 不是以取代 gulp 为目的的，而是为了给大型 SPA 提供更好的构建方案。对大量源文件进行流式处理是 gulp 擅长的事，webpack 不想抢，也不必抢。即便抢，也无非是再造一个蹩脚的 gulp 出来而已。

既然 webpack 模块化这么强，那之后模块化就全用 webpack 好了
webpack 模块化是强，可是他胖啊，不是全部人都抱得动，主要是他为了提供更多的功能封装进了太多东西，因此选择上仍是须要因地制宜。若是单纯只是打包 js（多页应用每每是这种需求），彻底可使用 rollup，browserify 这种小而美的实现，由于他们只作一件事——打包js。而若是须要将图片，样式，字体等全部静态资源所有打包，webpack 毫无疑问是首选。这也是为何愈来愈多的流行库和框架开始从 webpack 转向使用 rollup 进行打包，由于他们只须要打包 js，webpack 好多强大功能根本用不到。连 rollup 官网也坦言若是你在构建一个库，rollup 绝对是首选，但若是是构建一个应用，那么请选 webpack。

结论

我看好多人说 gulp 和 webpack 不是一类东西，我不这么以为，虽说二者的出发点确实是不同的，gulp 走的是流式处理路线，webpack 走的是模块处理路线，可是二者所要达成的目标倒是同样的，那就是促进前端领域的自动化和工程化管理。webpack 发展到如今，已经很是强大了，强大到在构建方面 gulp 能作的事 webpack 基本上均可以胜任，gulp 作不了的 webpack 也能搞。一样的那些开发工做中痛苦又耗时的任务，gulp 和 webpack 都能解决，只是解决思路有天壤之别。

下表是从各个角度对 gulp 和 webpack 作的对比：

	Gulp	Webpack
定位	基于流的自动化构建工具	一个万能模块打包器
目标	自动化和优化开发工做流，为通用 website 开发而生	通用模块打包加载器，为移动端大型 SPA 应用而生
学习难度	易于学习，易于使用，api总共只有5个方法	有大量新的概念和api，不过好在有详尽的官方文档
适用场景	基于流的做业方式适合多页面应用开发	一切皆模块的特色适合单页面应用开发
做业方式	对输入（gulp.src）的 js，ts，scss，less 等源文件依次执行打包（bundle）、编译（compile）、压缩、重命名等处理后输出（gulp.dest）到指定目录中去，为了构建而打包	对入口文件（entry）递归解析生成依赖关系图，而后将全部依赖打包在一块儿，在打包以前会将全部依赖转译成可打包的 js 模块，为了打包而构建
使用方式	常规 js 开发，编写一系列构建任务（task）。	编辑各类 JSON 配置项
优势	适合多页面开发，易于学习，易于使用，接口优雅。	能够打包一切资源，适配各类模块系统
缺点	在单页面应用方面输出乏力，并且对流行的单页技术有些难以处理（好比 Vue 单文件组件，使用 gulp 处理就会很困难，而 webpack 一个 loader 就能轻松搞定）	不适合多页应用开发，灵活度高但同时配置很繁琐复杂。“打包一切” 这个优势对于 HTTP/1.1 尤为重要，由于全部资源打包在一块儿能明显减小浏览器访问页面时的资源请求数量，从而减小应用程序必须等待的时间。但这个优势可能会随着 HTTP/2 的流行而变得不那么突出，由于 HTTP/2 的多路复用能够有效解决客户端并行请求时的瓶颈问题。
结论	浏览器多页应用(MPA)首选方案	浏览器单页应用(SPA)首选方案

gulp 为什么不吸收百家之长，把 webpack 的东西集成进来，反正都是开源的
腾讯那么牛逼，你说他怎么不把阿里巴巴集成进来。集成应该是没可能，由于 gulp 和 webpack 的定位不同。因此，没有放之天下而皆准的解决方案，只有具体问题具体分析选择适合的解决方案才能正确地解决问题。gulp 和 webpack 只是咱们解决问题的工具，不要被工具束缚了手脚不能前进。

扯了这么多，到底谁会被拍死在沙滩上
能够看出来，这两个工具其实各有优缺，都有用武之地。合理地配合使用，取长补短，才能发挥最大的威力，因此这俩基友并非互斥的，而是互补的，谁也不会被拍死在沙滩上。

临末，送你们一个福利 😘