updated on

testing the parcel bundler with vue

Introduction

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?

The history of bundling

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 🤓

  1. In the beginning, bundling wasn’t a thing: just reference javascript/CSS files in your HTML and you were done (the good ol’days in a way (but damn I hated IE6))
  2. Then we began to take care of file sizes and we minified them with non-JS tools (Google Clojure compiler for example)
  3. 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)
  4. Then node.js came and we used its UNLIMITED POWER ⚡️ to handle dependencies & tooling
  5. Then Browserify came and we began to bundle our Javascript that way:
    better dependencies management and the possibility to split our JS code in multiple files
  6. Then building tools like Grunt or Gulp let us coordinate all those build step together.
    It staid that way a couple of time…
  7. 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.
  8. 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 💪).
  9. Then appeared CLI for each framework to simplify the use of webpack.
    Tools configuring tools to use other tools.
  10. 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:

And we still need to support legacy browsers.

I’m pretty sure it’s still every dev’s dream to use a thing that just works in every situation (“building” appeared in javascript fatigue posts quite often).

On a side note, the web-community is pushing forward for native tools.

After all:

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)

Why bundling vue

If we look at the vue’s single file component we can see that:

So it’s a good candidate for testing Parcel’s ability to bundle anything 😎

Parcel

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):

1
2
3
4
5
6
const options = {
  outDir: "./dist", // The out directory to put the build files in, defaults to dist
  outFile: "index.html", // The name of the outputFile
  publicUrl: "./", // The url to server on, defaults to dist
  target: "browser" // browser/node/electron, defaults to browser
};

That’s it.

I hope you’re not afraid of the void 🌑.

Main use

Just specify an entry file (either HTML, JS or CSS) and it will crawl all its dependencies and bundle them.
That’s it.

You may have to install other NPM packages by I’ve found that Parcel tries to install some of them for you. That’s such a good idea!

Also being able to run a Hot Module Replacement server in development is quick way to start coding a web-application.

Transform configuration

Parcel will pass down some configuration to the tools that it uses under the hood:

This can lead to some strange issues sometimes…

Also be aware that as for now (august 2018) Parcel relies on Babel 6 and not on Babel 7 (still on beta but working fine)

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).

Code splitting

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 👌

Where simplicity breaks

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 .vue files in production mode for example…

When building from an html file:

  • Parcel can’t simply ignore assets: a manifest.webmanifest file will be converted to manifest.b01ff217.js…
  • 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 html file for the dev (it was my entry point)
  • write another production html file and shift my entry point to my JS file so that it doesn’t parse my HTML code

Things I didn’t test

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.

Conclusion

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.