Closure Compiler: a tool for making JavaScript download and run faster
31–40 of 77 posts
Re: Closure Compiler: a tool for making JavaScript download and run faster
#32Why 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.
Re: Closure Compiler: a tool for making JavaScript download and run faster
#33Why 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.
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
#34Why 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
#35Why 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.
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
#36Check 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
#37Earlier 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?
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
#38It'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
#39Earlier 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?
Re: Closure Compiler: a tool for making JavaScript download and run faster
#40Having 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'…
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.