New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support ES6 in JS optimization (Babel? Acorn?) #6000

Open
saschanaz opened this Issue Dec 29, 2017 · 9 comments

Comments

Projects
None yet
4 participants
@saschanaz
Collaborator

saschanaz commented Dec 29, 2017

With Babel, we can:

  • use ES2015+ freely and replace Module['print']('fetch-worker sent a message: ' + e.filename + ':' + e.lineno + ': ' + e.message); into Module['print'](`fetch-worker sent a message: ${e.filename}:${e.lineno}: ${e.message}`);, etc.
  • use JS-syntax-compatible conditional compilation (#5732)
@curiousdannii

This comment has been minimized.

Contributor

curiousdannii commented Dec 29, 2017

Can also replace a lot of custom minification (including DCE) with babel-minify.

@kripken kripken added the help wanted label Dec 29, 2017

@kripken

This comment has been minimized.

Owner

kripken commented Dec 29, 2017

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.

@curiousdannii

This comment has been minimized.

Contributor

curiousdannii commented Dec 30, 2017

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.

@rongjiecomputer

This comment has been minimized.

Contributor

rongjiecomputer commented Dec 30, 2017

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.

@saschanaz

This comment has been minimized.

Collaborator

saschanaz commented Dec 30, 2017

Closure Compiler can already output ES6 code

Its wiki says no:

You cannot use it as an output language yet; for now you need to transpile down to ES5 or ES3.

But anyway I think the purpose here is to input ES2015+, not output.

@kripken

This comment has been minimized.

Owner

kripken commented May 15, 2018

We should remember to look into source map support when investigating Babel (see #4224, currently our source maps break when the JS optimizer is run - hopefully with Babel there's a good way to avoid that).

@kripken kripken changed the title from Use Babel to Use Babel to support ES6 in JS optimization May 31, 2018

@kripken kripken changed the title from Use Babel to support ES6 in JS optimization to Support ES6 in JS optimization (Babel? Acorn?) Jun 29, 2018

@kripken

This comment has been minimized.

Owner

kripken commented Jun 29, 2018

Talking to @yurydelendik today, we had some thoughts on this topic:

  • As a high-level goal, we want emscripten to both emit something that fits well into web bundler build systems - for the library use case - but also can emit a fully optimized output by itself - for the application use case.
  • It would be nice to use DCE from Babel etc., so we don't do it ourselves, but that is somewhat at odds with the application use case of emitting a fully optimized output by ourselves. On the other hand, that's why we support closure advanced (which is especially good for the application use case, where nothing else is being built but what closure sees when called by emcc). But still, we need some amount of JS opt passes for our metadce and other specific optimizations. That's pretty minimal, though, and we probably just want to keep doing what we are, and not invest in new big things there.
  • To replace our current JS optimization which uses Uglify1, another option is Acorn (used by webpack and others). It provides an AST and is fast, and supports ES6 - so it should be possible to migrate the JS opt passes we need to there. It's also probably easy to include in emscripten (whereas I think Babel is larger and has more dependencies, but I'm not sure).
@curiousdannii

This comment has been minimized.

Contributor

curiousdannii commented Jun 29, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment