Parcel Vs Webpack

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

横空出世的 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 要麻烦很多：

• 需要写一堆配置；
• 需要再安装一堆依赖；
• 不能简单的自动生成 HTML；

这个项目我用 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 关闭了很多配置项，在一些需要的配置的场景下无法改变。例如：

  • 无法控制对部分文件的特殊处理，以实现诸如按需加载这样的需求；
  • 无法控制输出文件名的 Hash 值和名称；
  • 无法控制构建输出目录结构；
  • 无法映射路径以缩短导入语句；
  • HTTP 开发服务器不支持 HistoryApi ；

Parcel 使用场景受限

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

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

反观 Webpack 除了用于构建网页，还可以做：

• 打包发布到 Npm 上的库
• 构建 Node.js 应用 ( 同构应用 )
• 构建 Electron 应用
• 构建离线应用 ( ServiceWorkers )

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

分别去用 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 能解决上面提到的这些问题，我会毫不犹豫的在我的下一个项目中使用他。

阅读原文