Parcel Version 2 was publicly released on October 13 of 2021 - as seen in their blog post and also on Twitter by the creator of Parcel, Devon Govett.
Version 2 of the Parcel build tool is simple and efficient.
During a year and a half - as a new web developer learning mostly Javascript, HTML, CSS and React - I was searching for the perfect build tools to create web applications and web sites.
Well, it was almost impossible to find one that did "everything" simply and efficiently. By "everything" I mean that it provides out-of-the-box:
- Dev server for Javascript, HTML, CSS based projects.
- Default loaders to handle regular web site and web apps requirements like loading images, SVGs, multiple CSS and JS files, etc.
- Optimized production builds - without any complex configs that can waste hours of your day each time you start a new project.
- Speed and performance.
- Proper usage of HTML and CSS files rather than everything handled by Javascript.
Parcel v2 replaced a Webpack 5 project in 10 minutes.
No jokes. I had a project using Webpack 5 and a super complex configuration which took me days to setup!
I went on the Parcel website and read the get started guide for web apps which took 1 minute. Then in my project, I deleted my node_modules folder and every dev dependencies I had related to Webpack in my package.json file. Then I installed Parcel as stated in the guide, setup the scripts in package.json then ran the npm install command. Then I executed npm start a few times to see console error messages which were super easy to understand.
After 10 minutes, the project was fully replaced with Parcel v2. Isn't that incredible?! Seriously, I was telling myself that this could never be possible. I mean - how could you replace days of work setting up my custom Webpack configurations and then simply replace it with a new module bundler called Parcel...? Well, it worked. Incredible and awesome.
Automatic Image Optimization with production builds.
Believe it or not, we are now at this awesome point in time where the build tool is able to let you declare a HTML element with multiple image sources (including AVIF images) and it will automatically optimize them when you run the production build command. This is insane. I previously had to manually setup a gulp workflow with imagemin and other complexities which I really had trouble with most of the time because you kind of never remember what you did in previous projects to set this up. Parcel v2... simply declare your HTML, put the original image in your project's preferred folder, run a command. Done.
Smaller Javascript and CSS minified bundles than with my previous Webpack v5 setup.
Not only is it extremely handy, fast and enjoyable - it also produced ~10kb less of total shipped Javascript and CSS. Then if you also count the automatic image optimizations which took another ~10kb off my previous images. That is around 20kb less shipped code in the production build with zero real efforts on my side.
Automatic caching helpers with file names hashing.
Parcel will reorganize your file names in production builds so that they include a hash like this index.f7b8de4d.js. This helps to cache those files for a very long time without worrying that you users will get old cached results. In fact, by hashing your file names, each production build that modified a file's content will generate a new hash which automatically invalidates the cache and ensure your users get the latest content you wanted to provide to them. That's awesome too.
Conclusion
So, I found that Parcel v2 provides out-of-the-box ideal modern default configurations for my web development needs. I am not affiliated with Parcel in any way. I just discovered it the day it was released publicly on Twitter.
Maybe you could try it and be as impressed as I am today. Honestly, when you spend hours, days, months, years searching for something and then you finally find it, it's an extremely satisfying feeling.
Thanks to all contributors in the Parceljs.org project. This new release is my new go to build tool for starting new projects.
Disclaimer 1: For purely React based projects I will keep using Next.js because its extremely good at it (and built especially for it).
Disclaimer 2: I did my tests on a MacBook Air M1 which greatly influenced the general speed of build times compared to my Windows machine.
Top comments (0)