While playing around with WebAssembly and rust, I stumbled across a plugin for an asset bundler I hadn't heard of before. Admittedly, my initial thought was "Dammit, why couldn't they just use webpack?" After all, webpack has served all my needs in the past and has seemingly become the defacto standard. "Time to roll up my sleeves and learn how to configure this thing..." I thought.
The first thing that struck me about Parcel is that there is no configuration file. In theory, I thought, that's great, but inevitably I'll need fine-grained control over something.
(Narrator: "He has yet to encounter such a scenario.")
Indeed, I've only used Parcel for two personal projects thus far, but I haven't had to configure anything at all. Everything Just Works™, and I've used it to do some relatively exotic things:
- Compiling rust to WebAssembly and bundling the resulting artifact
- Bundling and exposing markdown files as React components
And then some not-so-exotic things, which are all supported out-of-the-box: Javascript, TypeScript, CSS, HTML, etc.
More than just zero configuration
Zero configuration is a huge selling point, but it's not the only thing Parcel has going for it. Whereas bundlers like webpack transform javascript files exclusively, Parcel can transform anything (correction: webpack 4 can now transform other types of files). Any file type not supported out-of-the-box can be supported by way of plugin. The practical implication here is that you can use any type of file as your entry point, not just javascript. This allows for a more natural way of bundling assets. For example, I can specify an HTML file as my entry point, and it will recursively locate and bundle all assets from there.
Parcel accommodates this by operating at a fundamentally higher level than its counterparts–It actually parses supported file types and transforms the resulting abstract syntax tree. When it encounters a javascript file, it transforms import and require declarations. When it encounters HTML, it will transform script and link tags. When it encounters CSS files, it transforms import and url declarations.
Oh and it's f***ing fast
According to the README on Parcel's github page, it's twice as fast as webpack when not caching assets, and nearly an order-of-magnitude faster when caching assets. It caches assets by default, and I have yet to encounter a situation where I've needed to turn off caching. Anecdotally, the numbers check out.
So, next time you're in need of an asset bundler, you should seriously consider Parcel.
Oldest comments (7)
Webpack is slooooow at building indeed. I'm holding off to see if webpack 4 it's going to be faster...
Webpack 4.5 is pretty fast. Some definite improvements there.
Is there an upgrade guide around? Altough I think I should probably just start from scratch with the webpack configuration and copy over the source directory...
It seems like the actual webpack API hasn't changed very much, but the ecosystem has changed a lot so you might have to hammer on your dependencies for a while (especially if you're using a lot of plugins/loaders).
Yeah I heard about the plugin system changing, I have a few plugins with the locked version due to the fact they are incompatibile with Webpack 4.
I'll give it a try when I have some downtime. The builds on the CI are slow exactly because of webpack :D
Just a small nit!!! It's inaccurate to say that webpack only transforms JavaScript (with webpack 4 now). webpack 4 out of the box brings the capability to handle and express any type of module or file in a unique and agnostic way.
This powers our JSON treeshaking, WASM support and also the ability to statically code-split CSS bundles!!! The implementation is what also helped webpack 4 (without full caching and parallelism yet too 😉).
We look forward to seeing these numbers that you mention for build performance however!
Sean - webpack team 🔥
Added a correction :)