41–50 of 77 posts
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.
how does this compare to uglifier?
It doesn't change string access, but it does rewrite dot access so you have to use dot access except when dealing with e.g json.
It doesn't work with the with statement, or code that is run with eval. You have to specifically export functions that should be used outside the code, otherwise they may be inlined, renamed or deleted.
Finally to get the most out of it, you have to write jsdocs for its types (at which point it can now do things like inlining functions).
[1]: https://github.com/babel/babel/issues/1828 [2]: https://github.com/babel-plugins/babel-plugin-dead-code-elim...
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'…
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.
https://github.com/clojure/clojurescript/wiki/Rationale#goog...
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'…
Secondly, this isn't about strictly speeding up runtime performance, but startup latency. The biggest use of Javascript compilers is shrinking download size. The effects of even a 10% code size reduction are readily apparent in 95%tile latency graphs. On mobile web, it's even more of a benefit.
Third, on a large codebase, like Gmail, Docs, Maps, etc the type checking provided by Closure is invaluable.
Forth, Closure provided a good module system for JS for far longer than any alternative, and like GWT, it's over 10 years old. That module system allows for cross-module code motion optimizations, that make it easy to structure your code for maximum readability and productivity, but to ship it down the wire in a way that only the code that is needed immediately is retained, and "dead code" is moved into late loaded modules.
Have a look at https://photos.google.com/ Most of the files loaded are tiny. Why? They're globally optimized, uglified, and dead-stripped together, but code is moved around between fragments depending on when, not if, the code is needed.
Soap Box Time: The way your message goes over the top reminds me of a frequent irritation I have with part of the JS community, I guess I'd call it the "tools derangement syndrome". People who chafe at any structure imposed, be it optional types, syntactic-sugar Classes in ES6, IDEs, build processes, dismissing the benefits, or overplaying the downsides.
That's fine if you don't have a lot of code, but if you have a big enough project that Closure would take a long time to optimize, you are exactly the kind of scale of project that needs a type checking globally optimizing compiler.
Closure compiler is extremely practically useful. Without it, Gmail, Maps, Docs, et al would be far larger applications that consume more resources. It's simply the best Javascript optimizer on the market by far.
Earlier quoted context omitted.
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 eq…
Closure advanced mode will do a lot better than 5% compared with Uglify.
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 c…
As for twice as large - never seen that. Uglify routinely gets to between 10-20% larger than advanced optimized CC in my experience.
I mean if you're writing directly for CC you might get better but that's because a lot of that will directly make it harder for most other minifiers (go figure)
Like I said tho CC is great, I'm glad it exists. It CERTAINLY does more than Uglify... I just don't see any practical benefit.
It's an awesome technological achievement though.
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'…
There is definitely something amiss with your setup if you had a Closure compile take ten minutes. That is absolutely not the norm. On an old laptop processing thousands of lines of JS, I've never had it take more than a minute.
Earlier quoted context omitted.
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 c…
Not FUD - you just clearly don't have a large enough project. I'm dealing with a lot more JS than you. Like.. a LOT more. I wish I had only 100k lines. As for twice as large - never seen that. Uglify routinely gets to between 10-20% larger than advanced optimized CC in my experience. I mean if you're writing directly for CC you might get better but that's because a lot of that will directly make it harder for most ot…
10-20% is a huge difference. On an 1M JS app, that would be an extra 100-200k of JS downloaded. That will seriously increase latency, especially for those in developing countries.