Hacker News Reader

Comment by cromwellian | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

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.

Reply on news.ycombinator.com