Gulp和webpack的比较

本质：gulp和webpack的本质都是一个node包

Nodejs简介

1. 在以前 js 要么嵌到 html 页面里，然后用浏览器打开 html 页面才能运行js，要么就是在浏览器开发者工具的 Console 面板里编写运行代码片段。Node的出现使前端开发者有了脱离浏览器工作的能力，相对于把开发者工具的 Console 给抠下来了，从此 js 可以脱离浏览器直接在 node 里运行；js现在有了两个宿主环境，一个是浏览器，一个是 node。它是基于Chrome V8 引擎实现的一个 JavaScript 运行环境，功能其实类似 Console 面板，但提供了大量实用的 API；Node 可以算是前端革命式的创新，随 node 一起发布的 node 包管理器 npm(node package manager) 也已经是全球最大的开源库生态系统。
2. Node官方中文文档：http://nodejs.cn/api/

理想的前端开发流程

1，写业务逻辑代码（例如 es6，scss，pug 等）

2，处理成浏览器认识的（js，css，html）

3，浏览器自动刷新看到效果

前端开发就是不断的重复上面的三个步骤，后两步（也就是 2 和 3）应该是 自动化 的，前端开发者理应只需关注第 1 步——写业务逻辑代码；自动化的事情应该交由构建工具来做，时下流行的前端构建工具就有 gulp 和 webpack。

构建工具是一段自动根据源代码生成可使用文件的程序，构建过程包括打包、编译、压缩、测试等一切需要对源代码进行的相关处理。构建工具的目的是实现构建过程的自动化，使用它可以避免机械重复的劳动。

Gulp

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

举例：

1. 用es6编写的脚本文件需要编译成浏览器认识的 javascript（babel ）
2. 2，用 scss，less 编写的样式文件需要编译成浏览器认识的 css
3. 3，检查代码是否符合书写规范，跑单元测试和集成测试
4. 开发环境如果有 sourcemaps ，修改完代码浏览器能自动刷新立即看到效果

使用方式：

1. 全局安装 npm i -g gulp （如失败尝试使用install全拼）
2. 本地安装 npm i --save-dev gulp

全局安装，是为了执行你所编写的 gulp 任务，即 gulp yourTask。而后面的 --save-dev 是本地安装，是为了编写任务时使用 gulp 提供的 api，例如 gulp.src()、gulp.task()、gulp.dest() 等等。当然也是可以直接使用全局安装的 gulp 的 api 的，但是强烈不推荐，因为这样涉及到 gulp 版本控制的问题，而且使用全局 gulp 的 api 的话就会产生环境依赖。

 

1. 在项目的根目录下新建一个 gulpfile.js 文件，这是 gulp 的默认配置文件，也可放在其他目录，但这样的话就得在启动 gulp 任务时手动指定 gulp 配置文件 gulp yourTask --gulpfile yourGulpfilePath。
2. 在 gulpfile.js 里编写 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'));

});

3，在终端里运行gulp,将编译好的文件输入到dist目录。

4，gulp 的突出特点——易于学习，易于使用。

Webpack

gulp 似乎是完美的，对前端开发工作中每一项痛苦又耗时任务都能解决。然而前端发展速度之快超乎想象，对页面性能和用户体验更是追求极致，以至于 gulp 某些领域尤其大型 SPA（单页应用）显得有些不够用了；

单页应用的核心是模块化，ES6 之前 JavaScript 语言本身一直是没有模块系统的，导致 AMD，CMD，UMD 各种轮子模块化方案都蹦出来。对这种模块化乱象，gulp 显得无能为力，gulp 插件对这一块也没有什么想法。不过也可以理解，模块化解决方案可不是谁都能 hold 住的，需要考虑的问题太多了；

对前沿的 SPA 技术 gulp 处理起来显得有些力不从心，例如 Vue 的单文件组件，gulp 配合一些插件可以勉强处理，但是很蹩脚。其实归根结底，还是模块化处理方面的不足；

优化页面加载速度的一条重要法则就是减少 http 请求。gulp 只是对静态资源做流式处理，处理之后并未做有效的优化整合，也就是说 gulp 忽略了系统层面的处理，这一块还有很大的优化空间，尤其是移动端，那才真的是一寸光阴一寸金啊，哪怕是几百毫秒的优化所带来的收益（用户？流量？付费？）绝对超乎你的想象。别跟我说 gulp-concat，CSS Sprites，这俩玩意儿小打小闹还行，遇上大型应用根本拿不上台面。现在的页面动辄上百个零碎资源（图片，样式表，脚本），也就是上百个 http 请求，因此这个优化需求还是相当迫切的。

 

和gulp一样，先看看官方怎么吹牛逼：

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

在webpack眼里什么都是模块，和单页应用配合起来，天衣无缝。webpack 的理念比较前卫，它本身也带来了很多新的概念和内容，诸如加载器（loader）、依赖图（Dependency Graph）等等，学习成本要远远高于gulp。

 

使用方式：

1，全局安装  npm i -g webpack

2，局部安装   npm i --save-dev webpack

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

3，在项目根目录下新建一个 webpack.config.js，这是 webpack 的默认配置文件，同 gulp 的 gulpfile.js 的功能类似。webpack.config.js 同样是不区分大小写的，但是取成其他名字或放在别的目录就需要使用 --config 选项去指定配置文件了。

4，接下来就是在 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')

}

};

5，最后仍然和 gulp 类似，就是在终端里运行 webpack。

区别比较

gulp 走的是流式处理路线，webpack 走的是模块处理路线，但是两者所要达成的目标却是一样的，那就是促进前端领域的自动化和工程化管理。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)首选方案