Parcel Vs Webpack

最新推荐文章于 2024-07-20 04:31:40 发布

weixin_33974433

最新推荐文章于 2024-07-20 04:31:40 发布

阅读量125

点赞数

文章标签： webpack 前端人工智能 ViewUI

原文链接：https://segmentfault.com/a/1190000012612891

版权

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

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

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

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

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

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

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

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

以下是 Parcel 让我心动的点：

而反观 Webpack，比 Parcel 要麻烦很多：

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

通过以上项目实践，发现 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 只能用来构建用于运行在浏览器中的网页，这也是他的出发点和专注点。

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

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

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