🚀Give Parcel a Try, You May Like It 🚀

Wow, I can’t believe I’m typing this article right now. Webpack and I have gone through so much.

I remember the first time I deleted hundreds of lines in gulp configuration in favor of sixty-something lines of webpack configuration. I hadn’t felt this good since, well, when I deleted thousands of lines of grunt configuration in favor of hundreds of lines in gulp configuration.

Surely webpack would be the gold standard, left unchallenged until the day browsers go the way of the dinosaur and are replaced with virtual reality or augmented reality or whatever. So efficient, so minimal, so pure. The documentation was rich and the community was strong.

Never has a comic been so relatable in my life

I have some memorable moments in my development career where I spent time learning how to configure webpack to squeeze extra performance out of my applications. I learned about every damn webpack plugin in existence and what they were used for. I started venturing into code splitting, long term caching, hot reloading, and even figured out clever ways to load my JS so that I could run my local environment in production. Even when webpack 4 was released and the plugin ecosystem was turned upside down, I stayed strong and loyal.

You’d imagine that when I started seeing threads on reddit like this, I scoffed. Pfft, what a sham. 😆 Parcel? Nothing could compare to my precious webpack. Here are some thoughts that ran through my head:

I bet *insert random tool or library X* isn’t even compatible with Parcel.

I’m guessing that if I tried it out, I’d find a glaring reason why it wouldn’t work for my project and it’d just result in half a day of wasted time.

Developers these days are so lazy! Webpack isn’t hard to learn! I did it, so everyone else should learn it too!!

This kind of mindset is really easy to get stuck into. Even though I’m self aware, I’ve done it so many times.

2009: jQuery? Why would I use that? Javascript works just fine! 🤔

2013: Angular 1.x? jQuery works just fine! 😐

2014: Gulp? But Grunt is fine!! 😦

2015: ES6? Babel? ES5 works just fine!! 😫

2016: Ugh, React? Angular 1.x works just fine!!!! 😠

2018: TypeScript? 😵

You get the picture.

Sometimes things change. You don’t always have to incorporate every single new thing into your arsenal, but you should at least keep an open mind.

Another Project, Another Webpack Config

Just recently I started a new repo and went through all the motions:

yarn add typescript react react-dom 

I installed all the extra stuff that you can’t leave home without:

yarn add --dev ts-loader css-loader style-loader react-hot-loader mini-css-extract-plugin webpack webpack-dev-server webpack-cli

I was pleased with how small my final configuration was now with webpack 4.x providing sensible defaults. The entire configuration clocked in at just 56 lines.

After executing webpack --config ./webpack.config.js and waiting a smooth 18 seconds, my build was complete:

This is a feature that will be used internally so it doesn’t have to be hyper optimized. There is some room for optimizations and whatnot, but hey, this is a good start. 💥 🚢

Enter Parcel

I was scouring the internet for interesting technology-related things to read this morning and came across another pro-Parcel post on reddit. I had an hour or two to kill, so I thought “Hey, why not install Parcel and see if I can really get my latest repo up and running without any actual config”. I was skeptical, but I went to the parcel github page and followed the instructions in the README. With one quick yarn add parcel-bundler and then another quick parcel src/index.tsx I was up and running.

I couldn’t believe it! Surely, something was not going to work. Would the page even load? I bet TypeScript wouldn’t compile correctly and it would be a mess! I wonder how I’d work without react-hot-loader reloading my app without full page reloads. Well…guess what?

Everything worked just fine

I was blown away. I quickly shut down the local development server and tried a build to see what would happen:

parcel build src/index.tsx

What? It worked? And it took the same amount of time to build as webpack? Without a config?

The sizes of the files were different, but not different enough for it to be a big deal. I’m sure there are sensible ways I could asynchronously load some dependencies and split that up to be more manageable.

Now that I have my builds working with parcel…I guess I don’t need all those webpack dependencies:

yarn remove css-loader file-loader mini-css-extract-plugin style-loader ts-loader webpack webpack-bundle-analyzer webpack-cli webpack-dashboard webpack-dev-server react-hot-loader
rm webpack.config.js

In conclusion

I wrote this article partially as a way to poke fun at myself. I hope I read this in a few years when some other new tooling comes along and threatens as superior to something I love using right now. Maybe one day a new library will emerge and take over React as my favorite library to write front-end applications. One thing I know for sure is that I need to keep my mind open for that day.

The other reason I wrote this article was to hopefully appeal to people who may be thinking the same things I did. Maybe you are a webpack connoisseur like myself and you can’t imagine going zero-config. We fought long and hard for those config files after all! We expertly curated each line of that configuration, and we’re damn proud of it. If you fall into this group like I do, I hope you at least try this tool and see what you think. Maybe you’ll start some small project next month, remember this article, and try parcel out before you go copy/pasting your last webpack config into that new repo.

A final note: I’m going to happily continue use webpack in my projects, but I’ll probably start looking at Parcel as an alternative when starting something new and wanting to get off the ground fast.

Thanks for reading! I hope to see comments below on what you think!