Differences b/w Parcel and Webpack

This post has originally been written here on my blog -> https://easyontheweb.com/differences-between-parcel-and-webpack/

A few days ago I had written an article about creating your first NPM packgage and during that article I realised that instead of using webpack as my bundler (it was just to include babel and use the import statement there) for that small project, I used parcel. As a matter of face I had been using parcel quite a lot of late, which prompted me to write this article where I’ll be comparing both of them and will be writing down the differences between Parcel and Webpack 4.

After comparing the two in the end I’ll also mention which one do I prefer over the other but let us first get down to what bundlers actually are and what are the differences between the two bundlers I mentioned, i.e, parcel and webpack.

What is a bundler ?
If you are a frontend developer or student you might or might not have heard of the term bundler but I’m 95% sure you must have used it, even if not knowingly. So, a Javascript module bundler actually is a tool that takes pieces of javascript code and their dependencies and creates a single file out of them for the browser (well, mostly for the browser).

There are many reasons why you would want to bundle all your javascript code but I’ll give the simplest of examples. Suppose you write 10 javascript code files and use the ES6 syntax in them. Now, you know that you won’t be able to use ES6 functionalities like import and all without using babel along (babel is a tool that converts your ES6 code to ES5 that browsers understand). So, you include babel in your project.

If you want, you can use all these 10 files inside your html code and also babel as well but that would not be the best thing to do. You do not want to manage all this yourself. Moreover, you won’t be doing it an optimised manner most probably. That’s where a bundler comes up. If you use a bundler, it will bundle up all your JS code as well dependencies like babel and create a single Javascript file that you can then feed to the browser in your html code.

Handling dependencies is something we do not like as developers (unless you’re a psycho, then congrats) and that is why we delegate that responsibility to bundlers.

Now that you know the main use of bundlers I’ll just go over their basic advantages once :-

Manage JS files and their dependencies on each other.
Help in code splitting. (more on that later)
Even handle CSS, images etc. these days.
Actually improve performance by using only what’s required and minifying the code.
Differences between Parcel and Webpack
Now that you know what Javascript bundlers are, let us see how these two famous bundlers differ from each other in various aspects.

1. Configurations The very basis of this debate comes from the fact that Parcel, unlike it’s mature competitor provides a zero-config setup, i.e, to use parcel as a bundler for your application you basically need to do nothing except install parcel in your project and directly use it. It comes with pre-configured out of the box support for all the major things like CSS, SCSS , images etc. It also supports code splitting out of the box.

Webpack on the other hand requires webpack.config.js file to be created first and rules be written into that file, loaders be imported into that file and then you can use webpack as the bundler for you project.

This also is the exact reason why these days I tend to just use Parcel for my small demo projects and apps. It just is so easy and simple to setup and get started with.

WINNER: PARCEL

1. Speed Being a frontend dev means you constantly build your bundle file and keep making changes to your code as well. The good news here is that both Webpack 4 and Parcel have a hot module reload functionality in place and keep a watch on your changes.

What makes them different is the way they implement things. Now, to look at it – Webpack builds your package significantly faster as compared to parcel(sometimes 5x) when it comes to the first build but there is a catch – Parcel on the other hand is faster and detecting changes and watching your files after the initial build up.

Why is that? Because Parcel on the first build up implements some sort of caching that will help it be faster in subsequent watches.

WINNER : TIE

1. Customisations This is an area where I don’t even think there is a competition. Webpack is a much more mature tool and follows the Configuration over convention principles . Now, even if it makes it difficult to start off with Webpack – when you are working on a big project – requirements come in from left and right and as of now, I’m not very sure, in fact the JS community is not very sure if Parcel will be able to handle some situations with it’s no-config approach.

Webpack, as mentioned before works on the basis of a webpack.config.js file that you may configure in any way, write your own set of rules and work with a plethora of open-source loaders specifically written to work with your webpack bundler.

1. Tree shaking The entire concept behind bundlers is to be able to feed just a single file to the browser right? Now, think about it – what would you want from that file? You would want that file to be as light weight as possible. The smaller the file the lesser the browser would have to download and hence, lesser the boot-up time for your application.

Parcel, being the new kid on the block has an advantage here because what they did was implement tree shaking, which is just a fancy word to express elimination of unwanted dead code in our application (which eventually reduces the bundle size) for both ES6 as well as the older commonJS modules. Webpack does tree shaking only for the ES6 modules.

As most of the older modules have been written in commonJS, parcel gets the advantage here as it is able to detect useless code even amongst that.

WINNER: Parcel

1. Code splitting One of the most important things that bundlers take care of is code splitting. As you app starts growing in size, so does your single bundle file, therefore what bundlers do is implement some sort of mechanisms to load certain code parallely or even lazy load parts of code so that your application boots up faster.

There are many ways Webpack implements code splitting but they do require configuring webpack. Parcel on the other hand claims to support zero-config code splitting in lesser ways than webpack but still effective ways like dynamic imports and all.

Deciding a winner here won’t be very fair though, as once provides you more customisation and other provides you ease but I think I’ll just edge towards Webpack here a bit.

WINNER: Webpack

Final words..
Unlike many other blog articles I read during the research for this article I decided not to include any code snippets revolving around webpack.config.js as I think they are very overwhelming. You might just read into those, feel they are too complex and not give webpack a chance just due to that, even though your favourite Next.js or Vue might be using webpack under the hood itself.

Personally, I would say this – start off with Parcel. It requires no setting up and you won’t have to put in any time to get things like SCSS and babel and all working for your project. What I believe is that with time, the community around Parcel will only increase and it will be giving a good competition to Webpack.

That being said, if your app does reach a point where Parcel just is not doing the job anymore and you need the power that comes with webpack , it is not much of a huge switch – you can do that any time. Therefore, start your new apps with Parcel and use it till you have to use Webpack (maybe you won’t have to ever).

Comments

[Peter Vivo]

Great post, thanks! I was changed from webpack to parcel a year ago, and my experience is great with Parcel. Bonus: you can import glsl file directly to js code, so you can use syntax highlight for them.

import randomPixelShader from './shader/randomPixelShader.glsl';