Treeshaking

[borkdude]

Continuation of treeshaking discussion: #24 (comment)

[thheller]

Here is an example of what kind of optimizations the Closure Compiler will do if you let it.

class Example {
  constructor(foo, bar) {
    this.foo = foo;
    this.bar = bar;
  }

  getFoo() {
    return this.foo;
  }

  getBar() {
    return this.bar;
  }

  doSomething() {
    return this.foo + 1;
  }
}

console.log(new Example(1, 2).doSomething());

Running this through esbuild with --minify (or terser) you get

class Example{constructor(o,t){this.foo=o,this.bar=t}getFoo(){return this.foo}getBar(){return this.bar}doSomething(){return this.foo+1}}console.log(new Example().doSomething());

Which is exactly what it says on the box. Minified. Nothing more. Maybe there are options to make it do more but I haven't found them.

The Closure Compiler in ADVANCED mode via npx google-closure-compiler --js test.js -O ADVANCED gives you

console.log(2);

I actually had to add the console.log since otherwise the Closure Compiler just eliminates everything. I'd say that is substantially different and more than just minified, and also more than Tree Shaking would ever do. Obviously, this is not applicable to library code since nothing of the library would be left.

I'm not even saying this to defend the Closure Compiler in any way. There are big huge trade-offs you have to make to get all of this. The other authors are correct when making different decisions. Sometimes these optimizations are not worth doing.

I'm just trying to emphasize this since this is something you need to be aware of when talking about :advanced output. It'll do way more than just shortening variable names and removing whitespace.

Back to the subject of Tree Shaking and cherry. The Closure Compiler is actually capable of outputting ESM code on its own nowadays. See

• https://github.com/google/closure-compiler/blob/3c7d61a10032d6042288ff18a724005b768965c1/src/com/google/javascript/jscomp/CompilerOptions.java#L2979
• https://github.com/google/closure-compiler/blob/3c7d61a10032d6042288ff18a724005b768965c1/src/com/google/javascript/jscomp/ConvertChunksToESModules.java#L34-L67.

However, so far this isn't capable of creating named exports (AFAICT). It just uses import/export to remove the need for the $APP hack I did in shadow-cljs. This would probably be the place to add this though. Would be nice if this was actually possible. Might be worth looking into instead of trying to rewrite the output after the fact?

[borkdude]

Also pulling @jo-sm into this discussion :)

I'm aware of the sophisticated logic that Closure performs. Cherry isn't a replacement for the whole-program optimizing that Closure does: it's just an extra tool that might enable extra use cases (similar to how babashka, nbb, SCI enabled more use cases on top of the "normal" tooling). The idea is to emit ES6 code that the less sophisticated JS tooling can still tree-shake.

[thheller]

FWIW I got curious to see how esbuild handles tree-shaking and changing the ESM output shadow-cljs produces might help.

a.js with

let a = 1;
let b = 2;

export { a, b };

index.js with

import { a } from "./a.js";

console.log(a);

does indeed shake the b out and yields

$ npx esbuild --bundle index.js --minify --tree-shaking=true --format=esm
var o=1;console.log(o);

but

let a; a = 1;
let b; b = 2;

export { a, b };

produces

$ npx esbuild --bundle index.js --minify --tree-shaking=true --format=esm
var o;o=1;var e;e=2;console.log(o);

So, the b is no longer removed.

I guess that confirms that changing the output may indeed help tree-shaking. I'm unsure why they don't support this pattern in the first place, but I guess they are being very conservative and a late-assignment is enough to bail. webpack appears to have the same behavior.

I can maybe address this by creating different output, so rewriting after the fact isn't needed.

[thheller]

Well, that is expected. Should also be true when just running the closure compiler alone, without running esbuild first. ADVANCED will still do its thing properly with the extra information provided by the tree.mjs. You could also try what terser does with this?

I just pushed another update to master which seems to cover most cases. Turns out using their ES_MODULES output just required one additional setting. I'll do a few more tests and then make a release. I do not expect the changes to help esbuild much but maybe it does.

[borkdude]

Thanks. I can test with master in an hour or two.

[borkdude]

@thheller Got some time to test now. I'm getting lots of

Imported symbol "g_" in chunk "nbb_reagent_dom_server.js" cannot be assigned
--- reagent/dom/server.cljs:23

etc again now when compiling nbb.

[thheller]

Can you test with pseudo-names? Otherwise its very hard to figure out what h_ might be.

[thheller]

Hmm, yeah I can reproduce this. These all appear to be CLJS dynamic vars used in binding. I'll see if I can figure something out.

[borkdude]

I’ll be back in an hour. Meanwhile you can try the nbb repo with the shadow-esm branch if you wish.

On Sun, 7 Aug 2022 at 15:45, Thomas Heller ***@***.***> wrote: Can you test with pseudo-names? Otherwise its very hard to figure out what h_ might be. — Reply to this email directly, view it on GitHub <#36 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACFSBUBO6LQUYQLMBXUPGLVX64ZHANCNFSM55PWJAXA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- https://www.michielborkent.nl https://www.eetvoorjeleven.nu