Break stuff. Now.

Stepping into ES6

Because ES6 will be the future

January 1, 2015

So it's Christmas vacation, the new year to be exact. While others are partying and getting fat with food, I am... I don't know... 12 hours into trying to convert the module system we use at work from RequireJS to Browserify. And while I'm at it, I'll just throw in ES6 support as well...

Which I just succeeded 5 hours into the first day of the new year.


So I did a bit of research on how to get Browserify into Django. I don't want the way most developers use Browserify, where you have a watcher task monitoring the files and rebundling after changes. This presents a weird overhead, especially to those who are not into the weirdness of front-end tooling. What I wanted was minimal configuration, everything handled by packages, and where a regular developer can just write code into a file, pop it in a page and refresh.


What I got was django-pipeline-browserify, a Browserify compiler django-pipeline package as base. This was the perfect tool since pipeline takes care of the compilation. All the developer needs to do is have pipeline point to an entrypoint file where browserify will start compiling. All the rest will be as easy as require()ing files as if it were normal JS.

The Twist

Since we're dealing with JS and ES6 is coming in fast, probably standardized by the middle of 2015, I just had to pop it into the setup so that we can start ahead of the pack. What I got was a transform module called 6to5ify, which uses the 6to5 transpiler, whose transpiled code is very readable.


Now, the 12 hours wasn't a result of slacking off. It was actually because of gotchas that I didn't anticipate in the tooling. First off is that Browserify makes scripts act like Node.js modules. Even the module resolution is crazy similar to Node.js, where it looks local first and climbs up to ancestors.

The next thing that caught me was how django-pipeline works. What happens is that django copies the entire static folder to a temporary location, transforms the files there and serves them.

The problem was, my package.json was outside static, which also meant node_modules directory was also outside. This resulted in 6to5ify not being found by Browserify. The solution was to create a secondary package.json inside static for the modules Browserify will be using. Why a second? Because the first package.json, which is at the root of the project, housed modules for unit testing. I didn't want to use symlinks nor duplicate dependencies in 2 places.


With the setup in place, I finally got rid of RequireJS complexity and also allowed me to write my very first, non-REPL, ES6 code in an actual project. The very first code was:

[1,2,3].forEach(x => alert(x));

...because lambdas were the simplest to create and easiest to remember.

What's next

Hmm... here's a checklist of what I aim to do:

  • Get rid of Bower entirely and use npm for package management. Makes it easier for devs, since npm ships with Node.js already and most libs are on npm anyways.

  • Transform all our components over to Browserify-compatible ones. While our component syntax will not change, the requirement for a transform we use is to have a custom extention. It will merely be a rename operation.

  • Convert to ES6 where possible. ES6 syntax provides some nice shorthands which can simplify the code. Most notable are lambdas and module syntax.