Allow ES6 in emscripten output

[sbc100]

We have a lot JavaScript code that emscripten generates and currently we limit all of it ES5 in order to maximize the portability of the output code.

However, given that non-ES5 runtime as rare (citation needed?), and that there are tools such as babel for converting ES6 to ES5 it seems like the wrong tradeoff to ask all emscripten JavaScript code to avoid modern features for this reason.

I recently ran across this in #11979 where the use of an ES6 feature would save code size and (I think) performance for the vast majority of our users.

Also see #11858

I propose that we remove this restriction and allow all ES6 features in emscripten output. The remained question is now we support user who need ES5 output. Do we:

A. Do nothing. Assume that our users who want to target older engine are well versed in running babel themselves and put the burden on them.
B. Add a compatibility option -s MIN_ES_VERSION=5? Or just -s ES5? This would most likely mean taking an internal dependency on babel and running it as part of the post-link process.

We could also do a hybrid approach where we poll our users and ask how many would want option B? Or at least we cpi;d delay the implementation of option B until we know we there a non-zero number of such users?

Please excuse me if this is a duplicate issue. I'm fairly sure I've seen similar a one but I couldn't find it in a search for ES6 or ES5.

[curiousdannii]

ES5 is pretty much only needed for IE now. Probably that means mostly only for enterprise intranet type situations? I'd support using ES6+ features in output and saying that anyone who needs it to be ES5 can transpile it themselves.

Could remove stuff like the Promise polyfill too.

[kripken]

Here is caniuse: https://caniuse.com/#feat=es6

Looks like e.g. Edge 14 lacks full support, not sure when it was released though, wikipedia page is incomplete. Firefox and Chrome seem fine (2017 / 2016). For Safari we should check iOS too.

@Brion I believe you support older versions - thoughts?

[curiousdannii]

There's also https://kangax.github.io/compat-table/es6/

Edge 14 was released Aug 2016 and has only 0.02% browser share. Doesn't it get automatic OS updates?

iOS seems to have close to full support since version 11.

[kripken]

Thanks @curiousdannii , and looks like iOS11 is from 2017, which is good.

I think Edge's releases have been decoupled from Windows since 2019, so those get automatic updates, but maybe older windows versions don't, I'm not sure. But 0.02% indicates you are right I think.

In general I think we should delay this until we are ready to emit ES6 by default. That is, we already have some defaults for MIN_$BROWSER, and we should probably update those. When they indicate ES6 in all of them, then I think we can make the switch to the "write ES6, depend on babel for legacy". The reason is that running babel like that will have some overhead to build times, which it would be nice to avoid in default builds (but is fine for special builds with legacy support).

It's possible we can do all this now - depending on what we find with ES6 support, and what we decide on how old is "legacy". We don't have exact rules for that since it's hard to be precise given how complex the ecosystem is. We should probably look at other tools targeting the Web to see what they do, e.g. does the TypeScript compiler emit ES6 by default? It looks like no, it's still ES3, but OTOH we do emit wasm by default, and maybe they have reason to be more cautious.

I do think we should add babel integration, if we do this. It should be pretty simple, like our closure integration using npm.

[sbc100]

That makes sense to me.

So the first thing we have to do is push the MIN_$BROWSER up to X where X includes ES6.

[sbc100]

Actually we our policy could be more fine grained. I think we could start with just requiring a few features from ES6 by default:

1. spread/rest (...) operator
2. arrow functions
3. let

I think just those three would give a good win on code side, performance and maintainability.

[kripken]

It it's necessary we can be more fine grained perhaps - I think we already are by using fetch for downloading wasm, since we realized all browsers with wasm support have fetch support anyhow. But that does get more complicated. Is there a big difference in browser support between ES6 and those 3 parts of it?

@dschuff pointed out that wasm-supporting browsers may also support ES6 anyhow, so this may only be relevant for wasm2js, which could make this simpler.

[jvail]

Just an observation from someone trying to decide which build flags to use (only slightly off-topic):
It is bit confusing that with EXPORT_ES6=1 em emits code with require(...) and __dirname in node which makes it effectively unusable as node module in node 14.

[curiousdannii]

@jvail You can subscribe to #11792 to get notified when that eventually gets fixed.

[sbc100]

Here is caniuse: https://caniuse.com/#feat=es6

Looks like e.g. Edge 14 lacks full support, not sure when it was released though, wikipedia page is incomplete. Firefox and Chrome seem fine (2017 / 2016). For Safari we should check iOS too.

Our min Edge version is 44.. which has full support according to that site. So I can't see any MIN_XXX_VERSIONS in our settings that don't already default to a version that fully supports ES6.

@Brion I believe you support older versions - thoughts?