3 ms·

Point 1 was addressed years ago by Google Closure Compiler, which used "dead code elimination". Also, the Haxe language, which compiles to JS, has DCE. Micro-

Point 1 was addressed years ago by Google Closure Compiler, which used "dead code elimination". Also, the Haxe language, which compiles to JS, has DCE. Micro-modules is certainly a solution if you don't want to use pre-processing or compilers. So is copy/pasting, or manually writing your own util libs, which seems safer than relying on third parties to provide one-liners for you.

nathancahill 11y ago
Eh, to date, a large part of the JS community still recommends including .js files in script tags in HTML. So, while this has been possible for a while, there hasn't been widespread adoption.
sillysaurus3 11y ago
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 11y ago
  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/limitations#restrictions-for-advanced_optimizations https://developers.google.com/closure/compiler/docs/limitati...
- ssalazar 11y ago
  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.
danneu 11y ago
Javascript must be written specifically to anticipate Google Closure Compiler's dead code elimination. Since the vast, vast majority of Javascript doesn't work with it, the issue certainly wasn't addressed years ago.
- jestar_jokin 11y ago
  "Addressed" doesn't mean "solved!" ;) Yes, you're right, making use of dynamic behaviour will break DCE.

nathancahill 11y ago

Eh, to date, a large part of the JS community still recommends including .js files in script tags in HTML. So, while this has been possible for a while, there hasn't been widespread adoption.

sillysaurus3 11y ago

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 11y ago
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/limitations#restrictions-for-advanced_optimizations https://developers.google.com/closure/compiler/docs/limitati...
ssalazar 11y ago
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.

danneu 11y ago

Javascript must be written specifically to anticipate Google Closure Compiler's dead code elimination. Since the vast, vast majority of Javascript doesn't work with it, the issue certainly wasn't addressed years ago.

jestar_jokin 11y ago
"Addressed" doesn't mean "solved!" ;) Yes, you're right, making use of dynamic behaviour will break DCE.