Open gwuhaolin opened 6 years ago
爱折腾的前端圈时常会有新轮子诞生，只要是好东西就能快速获得大量关注，资历再好的大哥只要不如新人也很快会被替代。
横空出世的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目前有如下明显的缺点：
零配置其实是把各种常见的场景做为默认值来实现的，这虽然能节省很多工作量，快速上手，但这同时会带来一些问题：
.babelrc
postcss.config.js
tsconfig.json
目前Parcel只能用来构建用于运行在浏览器中的网页，这也是他的出发点和专注点。 在软件行业不可能存在即使用简单又可以适应各种场景的方案，就算所谓的人工智能也许能解决这个问题，但人工智能不能保证100%的正确性。
反观Webpack除了用于构建网页，还可以做：
分别去用Parcel和Webpack构建以上项目，收集的数据如下：
从以上数据可以看出：Parcel构建速度快，但Parcel输出文件大
导致Parcel构建速度快的原因和iOS比Android用起来更流畅的原因类似：
导致Parcel输出JS文件大的原因在于：
以上项目完整源码可下载
现阶段的Parcel就像beta版的iPhone，看上去很美好但还不能用于生成环境，如果你现在就把Parcel用于生成环境，相信我你一定会踩很多坑。 踩坑不要紧，要命的是无法在网上找到解决方法以快速解决问题。
我不是不鼓励大家使用Parcel，历史总需要先驱去推动，就像乔布斯义无反顾的引领了一个时代，我们也需要去实践Parcel，坑都是一个个填平的，所以我鼓励大家在一些个人小项目中使用Parcel。
如果Parcel能解决上面提到的这些问题，我会毫不犹豫的在我的下一个项目中使用他。
阅读原文
哦哦校友啊
huanz
commented
6 years ago huanz
commented
6 years ago
横空出世的Parcel近日成为了前端圈的又一大热点，在短短几周内就获得了13K的Star。 作为前端构建工具新人的Parcel为什么能在短期内获得这么多赞同？他和老大哥Webpack比起来到底有什么优势呢？
我花了6个月的时间写了一本全面介绍Webpack的图书《深入浅出 Webpack》近日刚出版，感觉被新出的Parcel给腰斩了。 但本文将本着公平公正的心态来详细对比一下他两，让你能明白他们直接的异同和优缺点对比，好决定是选Parcel还是Webpack。
为了对比他两，我们从实际出发举一个实战项目为例子，分别用Parcel和Webpack去实现，实战项目要求如下：
Parcel让人眼前一亮
在用了很久Webpack后用Parcel的感觉就像用了很久Android机后用iPhone，不用再去操心细节和配置，大多数时候Parcel刚刚够用而且用的很舒服。
用Parcel去完成以上项目的要求，我只是专心去写项目页面所必须的代码，Parcel智能快速的帮我构建出了能正常运行的结果。
以下是Parcel让我心动的点：
而反观Webpack，比Parcel要麻烦很多：
这个项目我用Parcel时花在构建配置上的时间不到一分钟，而用Webpack构建时花了5分钟去配置。
Parcel还需要时间去打磨
通过以上项目实践，发现Parcel目前有如下明显的缺点：
Parcel需要为零配置付出代价
零配置其实是把各种常见的场景做为默认值来实现的，这虽然能节省很多工作量，快速上手，但这同时会带来一些问题：
.babelrcpostcss.config.jstsconfig.json这些配置文件也一起发布上去了， 由于目前Parcel只要在目录中发现这些配置文件就会认为该项目中的代码需要被处理。例如mini-store这个库中就把.babelrc文件发布到了Npm上，项目依赖的本来是lib中已经编译成了ES5的JS代码了，但Parcel还会去用Babel处理一遍。 Npm官方并没有规定发布到Npm上的包需要符合哪些规范，这会让Parcel很为难。Parcel使用场景受限
目前Parcel只能用来构建用于运行在浏览器中的网页，这也是他的出发点和专注点。 在软件行业不可能存在即使用简单又可以适应各种场景的方案，就算所谓的人工智能也许能解决这个问题，但人工智能不能保证100%的正确性。
反观Webpack除了用于构建网页，还可以做：
构建速度和输出文件大小对比
分别去用Parcel和Webpack构建以上项目，收集的数据如下：
从以上数据可以看出：Parcel构建速度快，但Parcel输出文件大
导致Parcel构建速度快的原因和iOS比Android用起来更流畅的原因类似：
导致Parcel输出JS文件大的原因在于：
总结
现阶段的Parcel就像beta版的iPhone，看上去很美好但还不能用于生成环境，如果你现在就把Parcel用于生成环境，相信我你一定会踩很多坑。 踩坑不要紧，要命的是无法在网上找到解决方法以快速解决问题。
我不是不鼓励大家使用Parcel，历史总需要先驱去推动，就像乔布斯义无反顾的引领了一个时代，我们也需要去实践Parcel，坑都是一个个填平的，所以我鼓励大家在一些个人小项目中使用Parcel。
如果Parcel能解决上面提到的这些问题，我会毫不犹豫的在我的下一个项目中使用他。
阅读原文