本文为阅读笔记，内容皆来自其他文章，参考最后一部分
什么是构建工具
构建工具是一段自动根据源代码生成可使用的文件程序，构建过程包括打包、编译、压缩、测试等一切需要对源码进行的相关处理。构建工具的目的是使构建过程的自动化，使用它可以让我们避免机械的劳动。
webpack 的诞生
前端发展速度超乎想象，对页面性能和用户体验更是追求极致，以至于gulp某些领域尤其大型的SPA（单页应用）显得有些不够用。
- 单页应用的核心是模块化，ES6之前JS语言本身一直没有模块系统的，导致AMD，CMD，UMD各种轮子模块化方案都蹦出来。对这种模块化乱象，gulp显得无能为力，gulp插件对这一块也没有什么想法，模块化解决方案不是谁都能hold住的，需要考虑的问题太多了
- 对前沿的SPA技术gulp处理起来显得有些力不从心，例如Vue的单文件组件，gulp配合一些插件可以勉强处理，但是很蹩脚，其实归根到底，是模块化处理方面的不足；
- 优化页面加载速度的一条志昂要法则就是减少http请求，gulp值是对静态资源做流式处理，处理后未做有效的优化整合，也就是会所gulp忽略了系统层面的处理。
gulp
使用流程
- 通过gulp.task注册任务
- 通过gulp.src方法获取到想要处理的文件流
- 然后把文件流通过pipe方法导入到gulp插件中
- 最后把经过插件处理后的流再通过pipe方法导入到gulp.dest中
- gulp.dest方法则把流中的内容写入到文件中
gulp.tast('scss', () => {
return gulp.src('app/sass/!*.sass')
.pipe(sass())
.pipe(gulp('dist/css'))
})
核心api
| api | 描述 |
|---|---|
| task | 创建一个任务 |
| series | 顺序执行多个任务 |
| prallel | 并行执行多个任务 |
| src | 读取数据资源转换成stream |
| pipe | 管道-可以在中间对数据进行处理 |
| dest | 输出数据到目标路径 |
| on | 事件监听 |
| watch | 数据源监听 |
gulp和webpack的区别
| gulp | webpack | |
|---|---|---|
| 定位 | 强调的是规范前端开发的流程 | 是一个前端模块化方案 |
| 目标 | 自动化和优化开发工作流，为通用website开发而生 | 通用模块打包加载器，为移动端大型SPA应用而生 |
| 学习难度 | 易于学习，易于使用，api总共只有5个方法 | 有大量新的概念和api，有详尽的官方文档 |
| 使用场景 | 基于流的作用方式合适多页面应用开发 | 一切皆模块的特点适合单页面应用开发 |
| 作业方式 | 对输入（gulp.src）的js，ts，scss，less等资源文件进行打包（bundle）、编译（compile）、压缩、重命名等处理后（guld.dest）到指定目录中去，为了构建而打包 | 对入口文件（entry）递归解析生成依赖关系图，然后将所有以来打包在一起，在打包之前将所有依赖转译成可打包的js模块，为了打包而构建 |
| 使用方式 | 常规js开发，编写一些列构建任务（task） | 编辑各种JSON配置 |
| 优点 | 适合多页面开发，易于学习，易于使用，接口优雅 | 可以打包一切资源，适配各种模块系统 |
| 缺点 | 在大页面应用方面输出乏力，而且对流行的大页面技术有些难以处理(比如vue但文件组织，使用gulp处理就会很困难，而webpack一个loader就能轻松搞定) | 不适合多页应用开发，灵活度高但同时配置很繁琐复杂，"打包一切"这个优点对于HTTP1.1尤其重要，因为所有资源打包在一起能明显减少浏览器访问页面时的请求数量，从而减少应用程序必须等待的时间。但这个有点可能会随着HTTP/2的流行而变得不那么突出，因为HTTP/2的多路复用可以有效解决客服端并行请求的瓶颈问题。 |
| 结论 | 浏览器多页应用（MPA）首选方案 | 浏览器单页应用（SPA）首选方案 |
