Live data from Hacker News

Closure Compiler: a tool for making JavaScript download and run faster

developers.google.com

31–40 of 77 posts

Re: Closure Compiler: a tool for making JavaScript download and run faster

#32

Why is the closure library not as popular as other alternatives (ex: jquery)? It looks like a solid library, used by gmail, google docs and other google apps, I'm guessing is the java requirement for the compiler.

The Java requirement is a real pain. If someone made an npm package that took care of the Java requirements, we'd probably all be using Closure rather than something like Uglify. Closure usually does slightly better minification wise, but it's a pain to work with.

Re: Closure Compiler: a tool for making JavaScript download and run faster

#33

Why is the closure library not as popular as other alternatives (ex: jquery)? It looks like a solid library, used by gmail, google docs and other google apps, I'm guessing is the java requirement for the compiler.

Because really taking advantage of it (enabling advanced compilation options) requires using a fairly specific subset of the language otherwise it will DCE half the project. Integration with "regular" javascript libraries can also be annoying.

ClojureScript uses Closure as an optimisation backend, since the primary cljs compiler is already in java.

Re: Closure Compiler: a tool for making JavaScript download and run faster

#34

Why is the closure library not as popular as other alternatives (ex: jquery)? It looks like a solid library, used by gmail, google docs and other google apps, I'm guessing is the java requirement for the compiler.

The Java requirement is a real pain. If someone made an npm package that took care of the Java requirements, we'd probably all be using Closure rather than something like Uglify. Closure usually does slightly better minification wise, but it's a pain to work with.

Huh? I mean I'm a little confused. The js ecosystem is full of transpilers, build tools, frameworks, and a bunch of package managers but installing java is one too many?

Re: Closure Compiler: a tool for making JavaScript download and run faster

#35

Why is the closure library not as popular as other alternatives (ex: jquery)? It looks like a solid library, used by gmail, google docs and other google apps, I'm guessing is the java requirement for the compiler.

When playing with this library, I had the same thought because it provides such powerful static analysis. JSDoc generation is nice. There's even externs for common libraries like Node.js core [1].

I stopped working with it (for now at least), because I couldn't figure out how to get my Node.js library to compile correctly. So at least for me the learning curve was a barrier to use it.

[1] https://github.com/dcodeIO/node.js-closure-compiler-externs

Re: Closure Compiler: a tool for making JavaScript download and run faster

#36
I've been using Closure Compiler with ADVANCED_OPTIMIZATIONS (which does the dead-code removal) for soundslice.com for several years. It is truly awesome!

Check out 39:30 in my 37signals talk at http://37signals.com/talks/soundslice to find out more about it.

The downside is that, in order for the dead-code elimination to work properly, you need to make sure to "export" things that aren't explicitly called in your JS module. For example, if your JavaScript module just provides some functions that are called by a web page, you'll need to make sure those function calls are "seen" by the compiler so that it doesn't delete them. It just takes a bit of time and thinking to set this up; I believe it originally took me a day to do so for Soundslice.

Re: Closure Compiler: a tool for making JavaScript download and run faster

#37

Earlier quoted context omitted.

The Java requirement is a real pain. If someone made an npm package that took care of the Java requirements, we'd probably all be using Closure rather than something like Uglify. Closure usually does slightly better minification wise, but it's a pain to work with.

Huh? I mean I'm a little confused. The js ecosystem is full of transpilers, build tools, frameworks, and a bunch of package managers but installing java is one too many?

Well all those build tools are usually npm packages, and are easily managed as dependencies using package.json (hence why there are so many being used). Adding Java and and a secondary set of dependencies isn't really worth the 5% decrease in minified file size that closure might give you.

I did try to use closure instead of uglify in a project recently - closure was a real pain to deal with compared to tools with equivalent functionality that are written in JavaScript. Cross-language ecosystem tools rarely work well it seems.

Re: Closure Compiler: a tool for making JavaScript download and run faster

#38
Having used both this an Uglify... I can't recommend this.

It's slow. Like... really slow to build. Uglify takes ~10seconds on my code whereas CC took around 10 minutes. Plus the performance benefits - while real - provides very little useful speedup that the V8/whoever JIT won't do anyhow. Even in tight loops.

It's VERY cool, but will add minutes to your deploy/compile time for very little practical benefit. If you're doing a ton of data processing on the client (WHY??) then I guess it might be useful... maybe.

That said - I'm glad it exists. It's a technological benefit even if it's not practically that useful. Those who compare it to the C++ optimization flags are being hyperbolic however: C++ isn't a JIT compiled language so it's Apples to Oranges.

Re: Closure Compiler: a tool for making JavaScript download and run faster

#39
post #13

Earlier quoted context omitted.

Have a look at the advanced compilation option: https://developers.google.com/closure/compiler/docs/api-tuto... Basically when enabled it will rewrite normal property access, e.g: `myObj.foo` to something like `a.b` but wont shorten string literal access, e.g `myObj['foo']` just becomes `a.foo` which you would use for any API's you want to export. For a real-world example I use string literals for declaring jquip's p…

How did it know it could leave out the `this.nodeType` check?

If it can prove that it will always be 1 (ie by code not shown) it will be removed.

Re: Closure Compiler: a tool for making JavaScript download and run faster

#40

Having used both this an Uglify... I can't recommend this. It's slow. Like... really slow to build. Uglify takes ~10seconds on my code whereas CC took around 10 minutes. Plus the performance benefits - while real - provides very little useful speedup that the V8/whoever JIT won't do anyhow. Even in tight loops. It's VERY cool, but will add minutes to your deploy/compile time for very little practical benefit. If you'…

10 minutes? I'm sorry this is just FUD. I've seen very large ClojureScript projects that generate nearly 100,000 lines of JavaScript and even with advanced optimization (the slowest mode by far) I've never seen it take longer than a minute and a half.

As far as Uglify compression performance, in my experience it consistently generates a final production file twice as large as Closure if you're following the Closure conventions. And Uglify doesn't do the fancier things like code splitting + code motion.

Post reply on HN