Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Support ES6 in JS optimization (Babel? Acorn?) #6000
With Babel, we can:
We would need to migrate the few JS optimizer passes that run on general JS, which includes JSDCE. But that shouldn't be too hard. (The great majority of JS optimizer passes only run on asm.js, so they aren't blocking us from using ES6 etc.)
How good is babel-minify? I assume we'd still need closure compiler in this case? How do those integrate?
Also, is babel the best tool in this space these days? A few years ago there were a bunch of JS ASTs and optimizers, I haven't followed this space closely for a while.
Babel has almost all the market share in transpiling/polyfilling. It shouldn't be too hard to add an emcc option to take a list of browsers, pass that to Babel, and then have it automatically transform any unsupported syntax.
Babel-minify is pretty good, but it's not that stable. But it is implemented just as a bunch of babel plugins, so that problematic ones can be easily disabled. It doesn't support asm.js. Probably it could be supported, but I haven't determined yet which plugin(s) are the problematic ones.
uglify is used way more, but IMO has toxic development practices.
If you want to output ES6, then (I think) Closure Compiler isn't an option. If you like saschanaz's idea about conditional compilation, then Babel would probably be an excellent choice.
No objection with using Babel for conditional compilation, but please make sure it is possible to disable transpiling/polyfilling/minifying. I hope Babel does not strip comments as I need some type annotations in comments for Closure Compiler.
Closure Compiler can already output ES6 code, though less optimizations are available in ES6 mode and async function is not yet supported. Commit history shows that Closure Compiler team is actively working on ES6 mode to enable more optimizations. Not sure if they are working on async function.
referenced this issue
Jan 9, 2018
added a commit
Jan 13, 2018
This was referenced
Jan 13, 2018
referenced this issue
May 11, 2018
changed the title from
Use Babel to support ES6 in JS optimization
May 31, 2018
Talking to @yurydelendik today, we had some thoughts on this topic:
I know hardly anything about this all, but it looks like many JS projects use related but slightly different parsers. Babel for example uses its own parser, but it is based on Acorn, and it outputs its own AST format, which in turn is based on ESTree (which Acorn uses).
I don't know how much these all overlap, but I'd expect a large extent. There's probably only a few cases where the differences are relevant to Emscripten, and as most of these tools do let you change parser, I'd expect they also expose the parser to each traversal/transformation function so the differences could be handled.
If the Emscripten passes could be ported to use the Acorn/ESTree APIs, then that should give lots of flexibility for the future.
One step in preparation would be for someone to do an audit of all the current passes to write up a list and give a brief explanation. Then we could more easily see what was essential vs optional, what needs to be handled in Emscripten (METADCE) vs what could be handed off to an independent tool, etc.