![Cover image for [COMPARISON] Webpack or Parcel, which one is better?](https://media2.dev.to/dynamic/image/width=1000,height=420,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fthepracticaldev.s3.amazonaws.com%2Fi%2Faryx4cf3s3pxopeha959.png)
Hey, DEV.to community.
Almost every modern web developer uses Webpack, either knowingly or without knowing that the framework they use gets help from Webpack to bundle their app.
There is another bundler called Parcel, which claims to be a zero-configuration bundler.
Let's see these two in action.
In the time I'm writing this article I'm using the latest stable version of Webpack and Parcel. Webpack version is 4.41.5 and Parcel version is 1.12.4.
This is going to be a pointing-based article so you can keep track of the points and see which is better at the end.
Each section has a mark out of 10, and either of these bundlers can get any number between 0 and 10.
This is only my opinion, and yours might be different. So this is only a personal point of view. (Though I will include some reasons as well)
What is a bundler?
In case you don't know what a bundler is, a bundler follows a simple concept: you give it your files, including style files like Sass, Less or Stylus, your images, fonts, JavaScript files and they will assemble them in a seamless way, so they work perfectly on production. Your CSS preprocessors will be able to be compiled and included without further actions.
Getting started
When you want to get started with these bundlers, you first have to install them (what a great point, no?), but there are some few more steps and will get started with them.
After installing Webpack, you need to create a file called webpack.config.js, and here is where you should include your configurations, so Webpack knows how to handle your bundle.
A very basic Webpack configuration looks like this (from the official website):
const path = require('path');
module.exports = {
entry: './src/index.js',
output: {
filename: 'main.js',
path: path.resolve(__dirname, 'dist'),
},
};
Then you can start Webpack to watch over your files.
But what happens in Parcel is crazy, you only need to create an index.html file and include your script with a relative path as usual like below:
<html>
<body>
<script src="./index.js"></script>
</body>
</html>
And start watching your index.html file, and that's it. Parcel is also capable of watching a JavaScript file rather than an HTML file as well.
I mark Parcel 10, but Webpack has to stick with 8 here.
Webpack: 8
Parcel: 10
Installing dependencies and preprocessors
We'll the next major thing about using a bundler is the help you need with your preprocessors like Sass or Less.
Well, this is how you should configure Webpack to recognize your preprocessors:
module.exports = {
module: {
rules: [
{
test: /\.s[ac]ss$/i,
use: [
'style-loader',
'css-loader',
'sass-loader',
],
},
],
},
};
And you have the npm packages needed:
npm i --save style-loader css-loader sass-loader
Although this might look scary, it isn't that hard, to be honest.
What about Parcel? Do you remember Parcel's claim? ZERO CONFIGURATION! So you don't have to do anything. All the things needed will be installed automatically with no effort.
Parcel gets another 10, and Webpack gets an 8.
Webpack: 16
Parcel: 20
Speed
One of the most important things that might have attracted you to this article is the performance test.
We'll let's try a simple bundle and see which of these bundlers perform faster?
I will run each bundler three times from scratch, and each of them with three bundling requests.
The app.js is the file that is being bundled. It only has one dependency, which is Vue.js and a console.log.
app.js:
import Vue from 'vue';
console.log('I\'m a bundle');
The chart below will show how these bundlers work when you're bundling for the first time (clean directory), and both are using production mode:
| Bundler | First run | Second run | Third run | Average |
|---|---|---|---|---|
| Webpack | 272 ms | 261 ms | 262 ms | 265 ms |
| Parcel | 2440 ms | 2510 ms | 2470 ms | 2473.33 ms |
As you can see, Webpack performs much better (almost x9 times) than Parcel when you are bundling for the first time.
Let's see what the results are when you are watching and bundling the same file again.
For this test, I will add and remove a lorem ipsum comment twice, so it is four times.
| Bundler | First run | Second run | Third run | Fourth run | Average |
|---|---|---|---|---|---|
| Webpack | 202 ms | 246 ms | 130 ms | 104 ms | 170.5 ms |
| Parcel | 71 ms | 69 ms | 67 ms | 54 ms | 65.25 ms |
In this one, Parcel takes over Webpack and performs faster (almost x2.5 times) than Webpack.
Although Parcel performs faster than Webpack when watching, which is more important than the initial bundling since you will mostly watch and run initial bundling only once, the difference in the initial bundling is too much.
I will give Webpack 10 and Parcel a 9 in this section.
Webpack: 26
Parcel: 29
Dev server
When you are building an application, you're most likely searching for a dev server.
Both of these bundlers provide a dev server, but you have to install Webpack's as a separate package and configure it.
This will be your webpack.config.json file:
var path = require('path');
module.exports = {
//...
devServer: {
contentBase: path.join(__dirname, 'dist'),
compress: true,
port: 9000
}
};
Webpack gets a 9 here, and Parcel gets a 10.
Webpack: 35
Parcel: 39
Code splitting
When it gets to the real world, code splitting is a real matter. Huge and heavy files cannot be loaded fast, and a website being slow won't be something that your client or visitor would want to have.
As the previous sections, Parcel claims to support code splitting with zero configuration, and that's true.
But Webpack needs some configuration.
Both of them support dynamic imports, and that's good.
BUT HERE IS THE PROBLEM THAT IS LITERALLY ANNOYING.
After bundling your code, this is what a Webpack dist folder looks like:
This is very neat and clean, it needs some configuration though to split your dynamic components, but it isn't that hard.
Everything is in its appropriate folder, images, CSS, JavaScript, and even fonts.
And this is how Parcel's dist folder looks like. You have no control over how Parcel manages these files, and your dist folder is completely flattened, and even worse, your index.html is also among these files. THIS IS A HUGE MESS!
To be fair because of the no configuration feature, Parcel has I give it a 2, and Webpack gets a 9 in this section.
Webpack: 44
Parcel: 41
Community and usage
Webpack is famous, and lots of frameworks use Webpack as their bundler such as my beloved Nuxt.js. So far, I don't know any framework that uses Parcel.
Webpack has a way bigger community behind it comparing Parcel's. Thus you will find more solutions for your problems when using Webpack.
Webpack has lots of extensions and ready to use awesome configurations as well.
This doesn't mean Parcel is an unknown bundler, though.
I give Webpack 10 here, and Parcel gets a 7.
Webpack: 54
Parcel: 48
Options and customization
I think you already know what is going to happen in this section.
Webpack is the king when it comes to customization. Parcel claims to be a zero-configuration bundler, which is very good, but you don't get that much customization in case you need it in an enterprise-level application.
Webpack provides thousands of options for you to configure it as you wish, which is really powerful.
Webpack gets a full 10, and Parcel will get a 2 (unfortunately).
Webpack: 64
Parcel: 50
Conclusion
Webpack is the winner here, and I suggest you using Webpack in case you don't want to get in trouble later. Webpack is very stable and reliable as I have used it thousands of times.
I loved Parcel for its easiness but sacrificing all those options Webpack provides made me not use Parcel again after only one project. Maybe if Parcel gets the flattened dist folder issue solved and provides more options to configure I would use Parcel again.
I compared the build time and made the charts. The folder structure and all of the pictures and context of this article are genuine. Use it if you want with a link to this page in case that doesn't cause you any problem.
I hope you enjoyed this article.
Tell me what you think in the comments section below.
Top comments (21)
I would agree on almost every point (except for code splitting because I don't care about bundled code, but that's just my opinion), but you made a small mistake that got carried until the end : 26 + 9 don't make 37.
Hi
Thanks for spotting the mistake
I edited the post
Hi everyone!
Just signed up to post this. :D
It's purely my own opinion and it's not biased, Because I'm just a user and not the creator of these tools. ;)
Learning curve: Parcel 10 WP 0
Ease of use: Parcel 10 WP 0
Implementation time: Parcel 10 WP 0
Maintainance: Parcel 10 WP 0
.
.
.
Conclusion: Parcel +Infinity WP -infinity
Totally fair. Not oriented, Not biased
Hi there and welcome to DEV.to community!
I see you are a Parcel guy! Nice! Enjoy whatever tool you feel more comfortable with. :)
And thanks for your comment!
Hi @adnanbabakan and thank you!
Honestly, I had just read about Parcel for the first time an hour before reading your article, and I was googling for comparisons between Webpack and Parcel that led me here. No offense, but when you give a 2 to Parcel and a 9 to Webpack in regards to code-splitting, I believe it's fair to give a 10 to Parcel and a 2 to Webpack in regards to getting started, Installing dependencies and preprocessors, and things that I mentioned above.
I see what you mean but I believe code splitting in production in Parcel is literally a mess. And no offence taken brother. Everyone has their own opinion! That's why I always tell people to use the tools they feel the best with! :)
Hi Adnan.
I know it's been a long time, but I'm here to admit that after messing with parcel v2 a lot, now I see that it's a total mess.
Honestly you need to reconfigure every preconfigured setting and then it works like crap.
Hi there. Thanks for coming back and telling about your experience. I appreciate it!
Eventually, one build a web-application and want it to run smoothly. i think Parcel creators understood this simple truth and committed to it. Usually, one configures a bundler in order to make it work smoothly. They use "receipts" for that, according to the resource types they have, as well as the entry points. It can all be automated. What Parcel builders did, is do more automation, and smarter automation. That's all. i see zero reasons not to work with it in small nor big projects.
Saying it is not suitable for big projects sounds to me like people who says that for big project, don't use small libraries, such as the amazing Riot JS, but use Angular or React. To be, after more than 30 years in the industry, it sounds like the person is simply don't understand what they are talking about.
IMHO, at least for me, how the 'dist' is being structured is really not a big deal. Most importantly is the source code structure. I will only care if the 'dist' affects the performance of the application at runtime, if not, it really doesn't matter. Just like nobody cares how code is being compiled into binaries form. Nobody cares how the binaries forms look like. All they care about are the flags and switches that create optimized binaries like smaller file sizes and it won't degrade the application performance at runtime.
Hey,
I've tried Parcel some time ago and it was cool, but the fact it lacks configuration is a flaw in my opinion. What if I want to customize something? If I want to fine-tune emitted file names?
This might be the perfect solution for people who want to start learning and don't really have any knowledge of Webpack. I know it can be scary at the beginning (even though after introducing version 2 it's really simple), so a lot of folks will be looking for alternatives. But for production usage, I think Webpack is a standard for a reason.
I worked with parcel 1 for a 2 years long, but our really complex SPA startup project reach the point when parcel bundler get much more instabil. So I changed builder to webpack 5, which take a day, but worth. Much stabile and faster. Parecel bundler adavntage is: you can include even glsl shader program - by the way you can edit with syntax highlight, and typescript or rust code without any problem to your js app. But too much pain cause the instability, special when you build your project under linux. Funny but our teams each developer use different operating system for develeopment: ubuntu, windows 10 and I work on mac, so that way important the consistent building system.
My conclusion after reading this:
One thing that parcel lacks is configuration.
That is actually by design.
I don’t think it’s a fair comparison, webpack vs parcel.
You would not bundle sever files with parcel for example.
I think a better comparison would be webpack vs rollup.
Parcel is really designed to be config free and for smaller projects. The “configuration” of parcel really comes from the fact you directly include the files you need within the entry point as if they worked native. For example linking to a typescript file instead of a js file.
Reading people saying webpack is easier is hilarious. It’s the difference between configuration over convention. The convention needs to be learned, but it’s soooo simple. Where as webpack has a much larger surface area. If you want the control, that is fine.
There should be enough space for either technology. It’s not a winner take all situation.
Hi
Thanks for your comment
I appreciate your opinion, though I think the comparison between Webpack and Parcel is pretty fair since they claim the same idea.
But Webpack being easy is kinda a joke.
Yep, they are a bundle, but from a very different perspective.
I mean you can use grunt and gulp to bundle. Bundling isn’t unique or even that modern. It’s been around for a while.
I just mean that in “how” they bundle and the concepts, webpack and rollup are more equivalent.
Parcel was built out of the frustrations of webpack if I am not mistaken to make it simpler for many front end projects.
Hahaha
Yes. It can both be a poditive point and a negative one.
If one of Parcel's cons are that the dist folder is "A HUGE MESS!" then I think this comparison is a bit biased.
Or to the folder structure affect performance?
It is not biased as I have not created either of these tools XD. It is just that I think folder structure even in a built one is a thing that should be neat. And no it doesn't affect the performance. :)
I want to try parcel, but webpack is too easy since it lives in nearly every JavaScript framework's project template without needing to configure it yourself.
Yes. Almost every framework uses webpack.