Use babel for transpiling rather than closure compiler

[sbc100]

We recently switch from using closure-compiler with WHITESPACE_ONLY to closure-compiler with SIMPLE_OPTIMIZATIONS. However this had the negative side effect that all input need to be free of closure compiler warnings, and this turned out not to be practical for all users. See #20810 for more on this

When selecting a transpilation tool use I also evaluated swx (written in rust) and esbuild (written in go). esbuild was rejected because the simply don't support ES5
(evanw/esbuild#297). swx was rejected because it almost doubled the side of our node_modules directory by adding two 50mb binary files.

Fixes: #20810

[kripken]

Agreed on the logic of selecting babel. This is not a code path that needs to be super-fast since normally we don't need to transpile for older browsers, so picking something simpler and smaller seems best.

[kripken]

Any changes to code size or compile times?

[kripken]

Why did this change?

[sbc100]

babel doesn't strip comments by default when transpiling.. and we have comments that contains the string ".. let ..." making this hacky check fail. I think its find to drop it rather than try to get clever here.

[kripken]

I see. sgtm

[tomayac]

LGTM, with a suggestion for slightly improving the version checking function.

[sbc100]

In terms of performance it does looks like babel is slow on large inputs. I measured using multitime -n2 ./emcc -sINCLUDE_FULL_LIBRARY -sLEGACY_VM_SUPPORT -O1 test/hello_world.c -v and got the following results:

babel: time 7.778, size 666625
closure compiler: 6.249s size 499042

I think the size difference here is because we are doing SIMPLE_OPTIMIZATIONS in the closure case so there is DCE happening.

If I run the same thing with -O2 and --closure=1 then I get:

babel: time 8.706s, size 61776
closure compiler: 7.855s size 47129

So I guess the babel polyfills could be more expensive or less DCE friendly.

[RReverser]

In terms of performance it does looks like babel is slow on large inputs.

Yeah this is pretty much the problem that swc is meant to fix.

[RReverser]

swx was rejected because it almost doubled the side of our node_modules directory by adding two 50mb binary files.

I wonder, could you install it lazily on first emcc invocation that needs transpiling? There is an existing precedent in fetching libraries via -s USE_* and that way all users who don't need transpilation, don't get the size increase, while others get faster transpilation.

[sbc100]

In terms of performance it does looks like babel is slow on large inputs.

Yeah this is pretty much the problem that swc is meant to fix.

We don't care that much since most folks won't be using this path, and using closure was already really slow.

[tomayac]

The last part seems broken: "canvas size is screen size".

[sbc100]

This is just a formatting change to the existing changelog entry. I don't want to mess with it as part of this PR really.

[kripken]

Slower speed is not great, obviously, but it seems fine to me here, since it's not a big regression compared to closure, and it avoids a large regression in the total sdk size.

[sbc100]

swx was rejected because it almost doubled the side of our node_modules directory by adding two 50mb binary files.

I wonder, could you install it lazily on first emcc invocation that needs transpiling? There is an existing precedent in fetching libraries via -s USE_* and that way all users who don't need transpilation, don't get the size increase, while others get faster transpilation.

I don't think it worth the extra engineering effort to build that out. The cost of adding babel to node_modules is pretty marginal (~20Mb uncompressed).

I'd also like to move away from the linker doing magical extra work like downloading and building stuff.

[sbc100]

Hopefully as a followup we can now remove some of our own pollyfills that we have accumulated over the years.