3 ms·

Odd that 7 years later, and JS build tools still don't match the level of optimization you get in Closure Compiler. IMHO, the speed of the build tool is less o

Odd that 7 years later, and JS build tools still don't match the level of optimization you get in Closure Compiler. IMHO, the speed of the build tool is less of a priority than the speed of the code it produces. You pay the cost of the build tool mostly in integration tests or production builds but shouldn't pay it during development. However your users pay for inefficiencies times the number of times the app is loaded. The state of JS tooling is woefully behind other languages and IMHO still behind the state of the art 5 years ago. Any non trivial sized app for example will require global dead code analysis and method and field level pruning as your dependencies grow over the lifetime of your app, all apps tend to bloat from unneeded code pulled in.

sotojuan 10y ago
Ironically it exists in compile-to-JS languages. I think ClojureScript uses Closure (naming accident), but the PureScript compiler does dead-code analysis and removal. Elm doesn't yet, but it's on the roadmap and partially finished.
thelarkinn 10y ago
I think closure compiler is the perfect example of how saving extra 100kb is has never been worth the poor user experience. Despite the pain in setting up webpack, the result is an excellent collection of features that goes beyond just JavaScript.
- cromwellian 10y ago
  By "user" you mean developer, but you're trading off compile time pain for you, and saddling everyone else with downloading an extra 100kb, which on mobile networks or in developing countries is unforgivable.
  - thelarkinn 10y ago
    True, which is why we haven't ignore this and are hoping to add features like scope hoisting (and personally I'd love to pass the AST program that webpack's parser creates right in to closure compiler js to see how "advanced" it can compiler) and other features. Because in the end, the api possibilities that webpack provides for plugins makes the tool limitless.
    - cromwellian 10y ago
      Closure Compiler also has pluggability, however the plugins must be written in Java, which is a downside for the JS ecosystem. For example, asset packaging wise, there's stuff like GSS Compiler integration, where goog.getCssName('foo') is translated into an obfuscated short className, while the GSS compiler optimized, prunes, and combines GSS. GWT was the same way, asset packaging was a core feature even in 2009. For example, it would automatically compile CSS, UI templates, and images, auto-optimizing them, and auto-sprite-sheeting everything, while packaging things into as few HTTP requests as possible. The real issue is that to do this in a safe way for JS requires coding conventions be adhered to, or the adoption of TypeScript and annotations. Closure's advanced mode will break JS that tries to get too fancy with dynamism.
- deleted 10y ago
  [deleted]

sotojuan 10y ago

Ironically it exists in compile-to-JS languages. I think ClojureScript uses Closure (naming accident), but the PureScript compiler does dead-code analysis and removal. Elm doesn't yet, but it's on the roadmap and partially finished.

thelarkinn 10y ago

I think closure compiler is the perfect example of how saving extra 100kb is has never been worth the poor user experience. Despite the pain in setting up webpack, the result is an excellent collection of features that goes beyond just JavaScript.

cromwellian 10y ago
By "user" you mean developer, but you're trading off compile time pain for you, and saddling everyone else with downloading an extra 100kb, which on mobile networks or in developing countries is unforgivable.
- thelarkinn 10y ago
  True, which is why we haven't ignore this and are hoping to add features like scope hoisting (and personally I'd love to pass the AST program that webpack's parser creates right in to closure compiler js to see how "advanced" it can compiler) and other features. Because in the end, the api possibilities that webpack provides for plugins makes the tool limitless.
  - cromwellian 10y ago
    Closure Compiler also has pluggability, however the plugins must be written in Java, which is a downside for the JS ecosystem. For example, asset packaging wise, there's stuff like GSS Compiler integration, where goog.getCssName('foo') is translated into an obfuscated short className, while the GSS compiler optimized, prunes, and combines GSS. GWT was the same way, asset packaging was a core feature even in 2009. For example, it would automatically compile CSS, UI templates, and images, auto-optimizing them, and auto-sprite-sheeting everything, while packaging things into as few HTTP requests as possible. The real issue is that to do this in a safe way for JS requires coding conventions be adhered to, or the adoption of TypeScript and annotations. Closure's advanced mode will break JS that tries to get too fancy with dynamism.
deleted 10y ago
[deleted]