Parcel Vs Webpack

33
爱折腾的前端圈时常会有新轮子诞生,只要是好东西就能快速获得大量关注,资历再好的大哥只要不如新人也很快会被替代。

横空出世的 Parcel 近日成为了前端圈的又一大热点,在短短几周内就获得了 13K 的 Star。

作为前端构建工具新人的 Parcel 为什么能在短期内获得这么多赞同?他和老大哥 Webpack 比起来到底有什么优势呢?

我花了 6 个月的时间写了一本全面介绍 Webpack 的图书《深入浅出 Webpack》近日刚出版,感觉被新出的Parcel给腰斩了。

但本文将本着公平公正的心态来详细对比一下他两,让你能明白他们直接的异同和优缺点对比,好决定是选 Parcel 还是 Webpack。

为了对比他两,我们从实际出发举一个实战项目为例子,分别用 Parcel 和 Webpack 去实现,实战项目要求如下:

  • 项目采用TypeScript + React + SCSS
  • 项目采用了 Antd UI 组件库,但要做到按需加载只用到了的组件,而不是所有组件都打包进去;
  • 项目使用了 Lodash 库,用于检查构建是否有剔除无用代码的能力( TreeShaking );
  • 构建需要支持模块热替换功能,以提高开发效率;
  • 支持 SourceMap ,以方便调试;
  • 对比他们的首次启动速度和监听变化时的构建速度;
  • 在生成环境下需要压缩 JS、CSS,CSS 需要提取到单独到文件,并对比他们在生产环境下构建出文件大小;
  • 需要生成自动会加载对应资源的 HTML 文件;

Parcel 让人眼前一亮

在用了很久 Webpack 后用 Parcel 的感觉就像用了很久 Android 机后用 iPhone,不用再去操心细节和配置,大多数时候 Parcel 刚刚够用而且用的很舒服。

用 Parcel 去完成以上项目的要求,我只是专心去写项目页面所必须的代码,Parcel 智能快速的帮我构建出了能正常运行的结果。

以下是 Parcel 让我心动的点:

  • Parcel 能做到无配置完成以上项目构建要求;
  • Parcel 内置了常见场景的构建方案及其依赖,无需再安装各种依赖;
  • Parcel 能以 HTML 为入口,自动检测和打包依赖资源;
  • Parcel 默认支持模块热替换,真正的开箱即用;

而反观 Webpack,比 Parcel 要麻烦很多:

这个项目我用 Parcel 时花在构建配置上的时间不到一分钟,而用 Webpack 构建时花了 5 分钟去配置。

Parcel 还需要时间去打磨

通过以上项目实践,发现 Parcel 目前有如下明显的缺点:

  • 不支持 SourceMap :在开发模式下,Parcel 也不会输出 SourceMap,目前只能去调试可读性极低的代码;
  • 不支持剔除无效代码 ( TreeShaking ):很多时候我们只用到了库中的一个函数,结果 Parcel 把整个库都打包了进来;
  • 一些依赖会 让Parcel 出错:当你的项目依赖了一些 Npm 上的模块时,有些 Npm 模块会让 Parcel 运行错误;

Parcel 需要为零配置付出代价

零配置其实是把各种常见的场景做为默认值来实现的,这虽然能节省很多工作量,快速上手,但这同时会带来一些问题:

  • 不守规矩的 node_module :有些依赖的库在发布到 Npm 上时可能不小心把.babelrc postcss.config.js tsconfig.json这些配置文件也一起发布上去了

由于目前 Parcel 只要在目录中发现这些配置文件就会认为该项目中的代码需要被处理。例如 mini-store 这个库中就把.babelrc文件发布到了 Npm 上,项目依赖的本来是 lib 中已经编译成了 ES5 的 JS 代码了,但 Parcel 还会去用 Babel 处理一遍。

Npm官方并没有规定发布到 Npm 上的包需要符合哪些规范,这会让 Parcel 很为难。

  • 不灵活的配置:零配置的 Parcel 关闭了很多配置项,在一些需要的配置的场景下无法改变。例如:

Parcel 使用场景受限

目前 Parcel 只能用来构建用于运行在浏览器中的网页,这也是他的出发点和专注点。

在软件行业不可能存在即使用简单又可以适应各种场景的方案,就算所谓的人工智能也许能解决这个问题,但人工智能不能保证 100% 的正确性。

反观 Webpack 除了用于构建网页,还可以做:

构建速度和输出文件大小对比

分别去用 Parcel 和 Webpack 构建以上项目,收集的数据如下:

数据项 Parcel Webpack
生成环境构建时间 8.310s 9.58s
开发环境启动时间 5.42s 8.06s
监听变化构建时间 3.17s 2.87s
生成环境输出 JS 文件大小 544K 274K
生成环境输出 CSS 文件大小 23K 23K

从以上数据可以看出: Parcel 构建速度快,但 Parcel 输出文件大

导致 Parcel 构建速度快的原因和 iOS 比 Android 用起来更流畅的原因类似:

  • Parcel 因为一体化内置,所以集成和优化的更好,而 Webpack 通过插件和 Loader 机制去让第三方扩展这会拉低性能;
  • Parcel 内置多进程并行构建,而 Webpack 默认是单进程构建 ( Webpack 也支持多进程 );

导致 Parcel 输出 JS 文件大的原因在于:

  • 不支持 TreeShaking
  • 构建出的 JS 中出现了所有文件的名称,如图:
以上项目完整源码可下载

总结

现阶段的 Parcel 就像 beta 版的 iPhone,看上去很美好但还不能用于生成环境,如果你现在就把 Parcel 用于生成环境,相信我你一定会踩很多坑。

踩坑不要紧,要命的是无法在网上找到解决方法以快速解决问题。

我不是不鼓励大家使用 Parcel,历史总需要先驱去推动,就像乔布斯义无反顾的引领了一个时代,我们也需要去实践 Parcel,坑都是一个个填平的,所以我鼓励大家在一些个人小项目中使用 Parcel。

如果 Parcel 能解决上面提到的这些问题,我会毫不犹豫的在我的下一个项目中使用他。

阅读原文

你可能感兴趣的

老刀 · 7月10日

我从来没有觉得哪个工具比另外一个工具更好。我觉得掌握工具只是为架构服务的。适合的场景用合适的工具。掌握工具的优缺点,用在适合场景。工具是死的,需求是活的。觉得掌握一个新工具就自我感觉良好了,还是菜鸟思维。个人非常讨厌“轮子”,“全家桶”,“刀耕火种”......类似的词语。感觉就是菜鸟装逼的“特殊标记”。

+2 回复

清蒸不是水煮 · 2017年12月27日

o.o 恕我孤陋寡闻,这是我看到的第一篇 Parcel 和 Webpack 的比较文,学习了。

回复

1

应该是比较最全面的一篇吧,很多介绍parcel的文章都会简单比较一下优缺点。

白吟灵 · 2017年12月28日
东尼大兔 · 2017年12月27日

还等等看

回复

zeromake · 2017年12月28日

parcel 的css modules好像还不支持,也不支持alias, 顺便看了博主的书只找到两点优化,其它的HappyPackParallelUglifyPlugin效果不知道为啥还不如不加

// 模块搜索优化
mainFields: ['jsnext:main', 'main'],
modules: [path.resolve(__dirname, '../node_modules')]
// Scope Hoisting
plugins: [
        new ModuleConcatenationPlugin(),
]

回复

鱼肚 · 2017年12月30日

分析得比较全面.不过parcel还是太新了,需要继续优化的.

回复

0

继续优化下去怕会变成下一个webpack...,手动滑稽

Quiet · 2月24日
天魔人心 · 2月9日

希望完善下回答,这一条 无法映射路径以缩短导入语句;
可以用balel解决 -- 详见https://github.com/parcel-bun...

回复

Seven丶 · 3月4日

博主分析的很透彻,比较的也比较详细,有心了,谢谢!

回复

载入中...