Faster builds

[Rich-Harris]

See #1730. Not ready for merge, this is just to track progress. So far, this

• transpiles all files to ES5 at the start of the build process, rather than transpiling test files towards the end - this is much more efficient
• updates to latest version of babel (formerly 6to5) - we'd got quite far behind
• uses a whitelist, rather than a blacklist, of babel transformations. This is a) faster and b) should prevent unwanted things creeping into our builds
• removes es6-transpiler from the equation - all transformations are now done with babel
• updates to the latest version of sorcery, which is almost 3x faster (this was one of the major bottlenecks).

Needs an npm install, obviously.

[martypdx]

Awesome stuff.

Maybe this change is alreday doing this, but I think the dev build should avoid bundling in lieu of something like https://github.com/ModuleLoader/es6-module-loader. The one (and perhaps only) thinkg the require.js build had going for it was granular level reloads. IMO it's the achilles heel of browserify.

Questions on whitelist:

• let still sucks, yes?
• ES6 classes & generators - out because performance or isn't IE8 compat or requires dependent module for polyfill (like regenerator), or some combination of these?

[Rich-Harris]

Maybe this change is alreday doing this, but I think the dev build should avoid bundling

It isn't at the moment. I did try this some time ago and it was excruciatingly slow because you effectively need to do the same work in the client (i.e. the ES6 modules have to get converted to SystemJS, which involves a full-blown parse/transformation step, and I'm not sure that it's able to save any of that work between reloads), but with the added overhead of a few hundred requests (plus the extra code complexity). At this point I'm fairly convinced that the best route is to make esperanto smarter about not re-analysing modules, though I can be persuaded.

let still sucks, yes?

It's a bit unpredictable... it's on the whitelist (es6.blockScoping), we could turn it off and just use var if we find it causes problems.

ES6 classes & generators

More that we're just not using them at the moment, and a longer whitelist means a slower build. There are a few places it might be nice to use class, though I'm not sure what the overhead is. Generators feel like they would probably cause similar headaches to for...of etc, though that's really just a gut feeling - I'm not sure what the perf/IE8 implications are, haven't actually tried them out yet.

[martypdx]

you effectively need to do the same work in the client (i.e. the ES6 modules have to get converted

What I'm thinking is do the ES6 transpile and module on the server, but then do something like browserify external require to create individual files. Concat file names to a file of script tags (that can only run with files added remove). And then a do a shim require that bootstraps things. Just thinking out loud...

[Rich-Harris]

I think I've actually broken the back of it - on my machine initial builds now take around 8 seconds, with rebuilds around ~1.5-2 seconds.

Esperanto was indirectly slowing things down by generating a source mapping for every character. It now only generates mappings for the start of each AST node, which means a) the sourcemap is much smaller, b) the subsequent sorcery transformation is much quicker because it doesn't have hundreds of thousands of mappings to trace, but c) the mappings are still accurate down to the character rather than the line, unlike browserify :)

There's still room for improvement but I don't think it's painful any more - I'll merge this in and close #1730 for now.