基于一个合理大小的应用程序,包含1726个模块,未压缩有6.5M 。构建在2016年的MAcBook Pro,4核物理CPU。css
打包工具 | 时间 |
---|---|
browserify | 22.98s |
webpack | 20.71s |
parcel | 9.98s |
parcel - 开启缓存 | 2.64s |
目前已经有不少的打包工具了,包括webpack和browserify。那么为何咱们还须要另一个呢?主要缘由是由于开发者的经验。node
许多的打包工具都是围绕着配置和插件构建的,并且为了让应用正常的工做,超过500行的配置并不罕见。这些配置不只繁琐并且耗时。一般状况下,这可能致使次优化的应用发送到生产环境。parcel被设计成零配置的:只须要将它指向应用程序的入口点,它就能正常工做。webpack
目前现存的打包工具都很是慢。拥有大量文件和依赖的大型应用可能须要花费几分钟的时间来构建,这在开发过程当中随着时间的变化而变得尤其痛苦。监听文件变动可以帮助从新构建,但初始的启动仍然很是慢。parcel利用工做线程编译你的代码,利用现代的多核处理器能力。这致使了初始构建的速度大大提高。它还具备一个文件系统缓存,能够保存每个文件的编译结果,以便后续可以更快的启动。git
最后,现有的打包工具都是围绕字符串加载/转换构建的,其中转换须要一个字符串,解析它,进行一些转换,而后再次生成代码。一般这样会致使许多的解析和代码生成在单个文件上运行,这是很是低效的。相反,parcel的转换工做在AST上,所以每一个文件只有一个解析,多个转换以及一个代码生成。github
parcel将资源树转换为bundle树。许多其它的打包工具基本上都是基于js资源,其它格式都是粘贴的-例如,默认状况下以字符串的形式内嵌到js中。parcel是文件类型无关的-它能够按照你指望的方式与任何类型的资源一块儿工做,无需配置。web
parcel将一个入口点做为输入,能够是任何类型的:JS文件,HTML,CSS,图片等。在parcel中定义了各类资源类型,它们知道如何处理特定的资源类型。资源文件被解析,它的依赖关系被提取,并转换成最终的编译形式。这建立了一个资源树。缓存
一旦资源树被构建,资源就被放入一个bundle树中。为入口资源建立一个bundle,并为动态导入的资源建立子bundle,这回致使代码拆分的发生。当导入不一样类型的资源的时候就会建立子bundle,例如若是你在js中导入css文件,它就会打包成对应js的兄弟bundle。若是一个资源须要多个bundle,它会被打包到最近的共同祖先,所以它不会被包含屡次。工具
在构建bundle树以后,每个包都有特定的文件类型的包装器写入文件。优化
原文地址:https://github.com/parcel-bundler/parcel插件