I started working on Parcel in order to solve two main problems that I have found with existing module bundlers like Browserify and Webpack: performance, and configuration experience.
- 🚀 Blazing fast bundle times — multicore compilation, and a filesystem cache for fast rebuilds even after a restart.
- 📦 Out of the box support for JS, CSS, HTML, images, file assets, and more — no plugins to install.
- 🐠 Automatically transforms modules using Babel, PostCSS, and PostHTML when needed — even node_modules.
- ✂️ Zero configuration code splitting using dynamic import() statements.
- 🔥 Built in support for hot module replacement
- 🚨 Friendly error logging experience — syntax highlighted code frames help pinpoint the problem.
The first reason I was motivated to build a new bundler was performance. I’ve worked on some pretty large apps with thousands of modules, and was always disappointed with the speed of existing bundlers. Large apps can take minutes to build, which is especially frustrating during development.
Many bundlers have focused on fast rebuild performance with delta builds, and this is great. However, initial build performance is also very important for both development and production/CI builds.
Parcel solves this problem by using worker processes to compile your code in parallel, utilizing modern multicore processors. This results in a huge speedup for initial builds. It also has a file system cache, which saves the compiled results per file for even faster subsequent startups.
Zero Configuration Experience
The second reason I built Parcel was to help with the pain of managing configuration. Most other bundlers are built around config files with lots of plugins, and it is not uncommon to see applications with upwards of 500 lines of configuration just to get things working.
This configuration is not just tedious and time consuming, but is also hard to get right and must be duplicated for each application. Oftentimes, this can lead to sub-optimized apps shipping to production.
Parcel is designed to need zero configuration: just point it at the entry point of your application, and it does the right thing. Parcel has out of the box support for JS, CSS, HTML, images, file assets, and more — no plugins needed.
Parcel’s zero configuration experience extends beyond file formats as well. Transforms like Babel, PostCSS, and PostHTML are also applied automatically when Parcel detects a .babelrc, .postcssrc, etc. This even works for third party code in node_modules for that module only, so application authors don’t need to know how to build each module they import, and the build doesn’t slow down running Babel over every file unnecessarily.
Finally, advanced bundling features like code splitting, and hot module reloading are supported out of the box as well. In production mode, Parcel automatically enables minification, with other optimizations like tree-shaking to come in the future.
Future Looking Architecture
One advantage of starting a fresh project is that I was able to design a more modern architecture for Parcel that is more extendible, and more flexible, all while requiring zero configuration from users, and supporting advanced features like code splitting and hot module reloading.
In Parcel, any type of file can be a first-class citizen. It is easy to add new Asset types, which represent input files, and Packagers which combine assets of similar types together into output files.
For example, there is a CSS Asset type, which analyzes and produces CSS code, and a CSS Packager which combines CSS assets together into a final bundle. Similar types exist for JS, HTML, and more. In this way, Parcel is completely file-type agnostic.
You can read more about how Parcel works on the website.
Try it out!
Parcel is just getting started, but many applications already work out of the box with zero configuration! So try it out — delete your webpack/browserify configuration, uninstall those plugins, and try Parcel. 😎
Let me know how it goes! You can find me @devongovett on Twitter.