本文从以下几个方面来对gulp和webpack进行对比讨论
1. gulp简介
2. webpack简介
3. 两者优劣对比
4. 总结
前言: 什么是构建工具?
构建工具是一段自动根据源代码生成可使用文件的程序，构建过程包括打包、编译、压缩、测试等一切需要对源代码进行的相关处理。构建工具的目的是实现构建过程的自动化，使用它可以让咱们避免机械重复的劳动，从而解放我们的双手
1. gulp简介
官网定义：Gulp 致力于 自动化和优化 你的工作流，它是一个自动化你开发工作中痛苦又耗时任务的工具包。
也就是说，gulp处理的是日常工作中遇到的以下几个问题
用 es6，typescript 编写的脚本文件需要编译成浏览器认识的 javascript
用 scss，less 编写的样式文件需要编译成浏览器认识的 css
检查代码是否符合书写规范，跑单元测试和集成测试
开发环境如果有 sourcemaps(对编译后的代码准确位置的追踪) 的话调试起来就方便多了，修改完代码浏览器能自动刷新立即看到效果就更好了
生产环境部署代码需要压缩合并静态文件，添加文件指纹控制缓存
2. webpack简介
官网定义：Webpack 是当下最热门的前端资源模块化 管理和打包 工具。它可以将许多松散的模块按照依赖和规则打包成符合生产环境部署的前端资源。还可以将按需加载的模块进行代码分割，等到实际需要的时候再异步加载。
webpack可以处理工作中以下问题
单页应用的核心是模块化，ES6 之前 JavaScript 语言本身一直是没有模块系统的，导致 AMD，CMD，UMD 各种轮子模块化方案都蹦出来。对这种模块化乱象，gulp 显得无能为力，而webpack的诞生就是为了解决这类问题；
对前沿的 SPA 技术，webpack更加适合处理；
优化页面加载速度的一条重要法则就是减少 http 请求。gulp 只是对静态资源做流式处理，处理之后并未做有效的优化整合，也就是说 gulp 忽略了系统层面的处理，这一块还有很大的优化空间，尤其是移动端，gulp-concat，CSS Sprites小打小闹还行，遇上大型应用根本拿不上台面。现在的页面动辄上百个零碎资源（图片，样式表，脚本），也就是上百个 http 请求，而webpack则可以解决此类问题。关于为何减少 http 请求可以有效降低页面加载时间戳这里。
3. 两者优劣对比
| Gulp | Webpack | |
|---|---|---|
| 定位 | 基于流的自动化构建工具 | 一个万能模块打包器 |
| 学习难度 | 易于学习，易于使用，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)首选方案 |
4. 总结
gulp上手快，api少，处理多页面引用js文件工作流灵活方便，多页面应用构建首选
webpack适合单页面spa应用，处理模块化打包，减少http请求有优势
