In this era of libraries needing a build step (even if you can use them without it, c’mon it’s better to do so) I want to talk about the parcel bundler.
The baseline is: Blazing fast, zero configuration web application bundler.
How this holds up?
I feel like it’s important to know from where we came before talking about what Parcel is trying to solve.
That’s my personal take about how we get there 🤓
- Then we began to take care of file sizes and we minified them with non-JS tools (Google Clojure compiler for example)
- Then we began to use CSS preprocessor which add a lot of handy stuff (mainly variables, selector nesting & import) with non-JS tools (Ruby-Sass for example)
- Then node.js came and we used its UNLIMITED POWER ⚡️ to handle dependencies & tooling
better dependencies management and the possibility to split our JS code in multiple files
- Then building tools like Grunt or Gulp let us coordinate all those build step together.
It staid that way a couple of time…
- Then React appeared.
Even if it was just one step further from previous frameworks (like backbone or angularJS), the full component way of doing things made people want to bundle thing, not on a language basis, but on a component basis.
- Thus webpack appeared.
Doing an amazing job with the drawback of a sometime tricky configuration (and the team is really pushing hard to solve this 💪).
- Then appeared CLI for each framework to simplify the use of webpack.
Tools configuring tools to use other tools.
- And recently Parcel appeared with a no configuration promise
It’s not that we don’t like simple stuff anymore (no one likes build steps), it’s more that our needs vs. what the browser can natively do aren’t matching:
- no CSS variables until recently
- also things that will never land in browsers like:
And we still need to support legacy browsers.
On a side note, the web-community is pushing forward for native tools.
- document.querySelectorAll is just jQuery‘s idea natively implemented
- JS arrow functions is inspired by Coffeescript’s functions
- JS modules, and CSS custom properties as talked before ⏪.
Maybe Web Components will be the native solution’s equivalent for React/Angular/Vue (Even if I think they will stick because of how much other benefits they can provide)
If we look at the vue’s single file component we can see that:
- Templates can be HTML or Pug template
- Style can be CSS, PostCSS, less, SASS/SCSS or Stylus with the support of style scoping or not
So it’s a good candidate for testing Parcel’s ability to bundle anything 😎
There isn’t a lot of things to learn about Parcel.
They said simplicity and simplicity it is: look at how little options there are!
Mainly (copied & trimmed from the official doc):
I hope you’re not afraid of the void 🌑.
Just specify an entry file (either HTML, JS or CSS) and it will crawl all its dependencies and bundle them.
Also being able to run a Hot Module Replacement server in development is quick way to start coding a web-application.
Parcel will pass down some configuration to the tools that it uses under the hood:
This can lead to some strange issues sometimes…
That’s a small common problem among the “under the hood” solutions (CLI included), you never know what’s going on before reading the
package.json (or some github issues).
Like every bundler, Parcel supports it.
They rely on a future addition to the JS language to do so.
As it is in stage 3 the syntax won’t change in the future and it’s safe to use it now without thinking about refactoring due to specifications change after 👌
I was able to set up a development vue application in an instant.
Every things that Vue supports seems to work seamlessly.
So that was a real time saver and a good entry point in Vue’s ecosystem.
But the promise of “simplicity” as some drawbacks:
- when you have a problem it’s most likely you’ll have to wait for a new version
- I had some problem with building & minifying
.vuefiles in production mode for example…
When building from an html file:
- Parcel can’t simply ignore assets: a
manifest.webmanifestfile will be converted to
- no PWA support, and since every resource is parsed, you can’t include a PWA file generated by workbox (same as above)
I resolved myself to:
- write a simple
htmlfile for the dev (it was my entry point)
- write another production
htmlfile and shift my entry point to my JS file so that it doesn’t parse my HTML code
Bundling a node.js application with it.
It’s useful if you share a lot of code between the client & the server and you want your server code to run as fast as possible.
There is a target parameter for it. But I’m not sure if I can do variables or module replacement with it.
When I was building my universal web-application (bad idea, don’t do it at home, use next.js or nuxt) I had to really refine my build configuration.
I don’t know if it would have been possible by using Parcel only.
Parcel is very promising and very young.
The team is doing an amazing job ❤️ and is pushing the bundling step in a good direction: simple and working 🎉.
I won’t advice it (yet) for big projects. I think, for now, frameworks’ CLI are more reliable.
BUT in the future, if I’ll be able to use the same simple bundle tool for all my projects I’ll go for it! (I’m a lazy 🐮 having to read yet another CLI doc isn’t my stuff).
I really hope they will keep up with the hard work of developing an ambitious open source projects like that.