Hacker News Reader

Comment by thelarkinn | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com