Rollup
如果用Webpack与Rollup进行比较的话，那么Webpack的优势在于它更全面，基于“一切皆模块”的思想而衍生出丰富的loader和plugin可以满足各种使用场景；而Rollup则更像一把手术刀，它更专注于JavaScript的打包。当然Rollup也支持许多其他类型的模块，但是总体而言在通用性上还是不如Webpack。如果当前的项目需求仅仅是打包JavaScript，比如一个JavaScript库，那么Rollup很多时候会是我们的第一选择。
- 配置
下面用一个简单的示例工程来看看Rollup是如何工作的。首先创建Rollup的配置文件rollup.config.js及我们打包的项目文件app.js
//rollup.config.js
module.exports = {
input:'src/app.js',
output:{
file:'dist/bundle.js',
format:'cjs'
};
}
//src/app.js
console.log("my first rollup app')
与Webpack一般装在项目内部不同，Rollup直接全局安装即可。
npm i rollup -g
然后我们使用Rollup的命令行指令进行打包
rollup -c rollup.config.js
即便我们的项目本身仅仅有一行代码，Webpack也需要将自身代码注入进去（大概50行左右）。显然Rollup的产出更符合我们的预期，不包含无关代码，资源体积更小。
2)tree shaking
在前面Webpack的章节中已经介绍过tree shaking，而实际上treeshaking这个特性最开始是由Rollup实现的，而后被Webpack借鉴了过去。
3)可选的输出格式
Rollup有一项Webpack不具备的特性，即通过配置output.format开发者可以选择输出资源的模块形式。上面例子中我们使用的是cjs（CommonJS），除此之外Rollup还支持amd、esm(ES6 Modules)、iife、umd及system。这项特性对于打包JavaScript库特别有用，因为往往一个库需要支持多种不同的模块形式，而通过Rollup几个命令就可以把一份源代码打包为多份。下面使用一段简单的代码进行举例。
4)使用Rollup构建JavaScript库
Parcel
Parcel在JavaScript打包工具中属于相对后来者（根据npm上的数据，Parcel最早的版本上传于2017年8月，Webpack和Rollup则分别是2012年3月和2015年5月）。在Parcel官网的Benchmark测试中，在有缓存的情况下其打包速度要比Webpack快将近8倍，且宣称自己是零配置的。它的出现正好契合了当时开发者们对于Webpack打包速度慢和配置复杂的抱怨，从而吸引了众多用户。下面我们来深入了解一下Parcel的这些特性。
- 打包速度
Parcel在打包速度的优化上主要做了3件事：·
1.1）利用worker来并行执行任务；
1.2）文件系统缓存；
1.3）·资源编译处理流程优化。
上面3种方法中的前两个Webpack已经在做了。比如Webpack在资源压缩时可以利用多核同时压缩多个资源（但是在资源编译过程中还没实现）；本地缓存则更多的是在loader的层面，像babel-loader就会把编译结果缓存在项目中的一个隐藏目录下，并通过本地文件的修改时间和状态来判断是否使用上次编译的缓存。
下面我们来着重说一下第3点，也就是对资源编译处理流程的优化。
可以看到，Parcel里面资源处理的步骤少多了，这主要得益于在它在不同的编译处理流程之间可以用AST作为输入输出。对于单个的每一步来说，如果前面已经解析过AST，那么直接使用上一步解析和转换好的AST就可以了，只在最后一步输出的时候再将AST转回String即可。（解析AST是个十分耗时的工作，能将其优化为只执行一次则会节省很多时间。）
WebAssemblyWebAssembly
是一项近年来快速发展的技术，它的主要特性是性能可以媲美于原生，另外像C和Java等语言都可以编译为WebAssembly在现代浏览器上运行。因此在游戏、图像识别等计算密集型领域中，WebAssembly拥有很广阔的发展前景
