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 能解决上面提到的这些问题，我会坚决果断的在个人下一个项目中使用他。

阅读原文