[sillysaurus3]

I'm not sure dead code elimination works in that situation. Consider:

  var obj = {
   a: ...
   b: ...
   c: ...
  }

If a, b, and c are functions, there is not necessarily a way to determine at compile time whether they will be used at runtime.

  var prop = webrequest();
  obj[prop]();

In that scenario, a, b, and c cannot be eliminated. But it would be worth testing Google Closure Compiler to see what it does in what scenarios.

I've heard ES6 modules solve this problem, but it seems like dynamic access to an ES6 module might still be possible, which would cause the same problems for DCE. Perhaps no one writes code that way, so it doesn't necessarily matter. But what about eval?

There are lots of tricky corner cases. It seems better to use small atoms than a monolithic package.

[mdavidn]

In simple mode, Closure Compiler would rename the local variable "prop" but not alter the properties.

In advanced mode, Closure Compiler would globally rename properties and statically eliminate dead code. In your example, it would remove a, b, and c and break the dynamic invocation.

This behavior is all outlined in Closure's documentation with examples.

[1]: https://developers.google.com/closure/compiler/docs/limitati...

[ssalazar]

Im not really sure how this is an argument against DCE. If theres no way to tell at compile time if these functions will be used, then you have to include them in the final delivered code, whether or not you are using monolithic or micro packages or dead code elimination.

DCE will help you if you pull in huge-monolithic-package and only use one function from it. In that case its basically the same as if you had used the micro package.