4 ms·
Unfortunately, as abritinthebay noted, Closure Compiler doesn't really understand JS and compile it to better JS. It understands a certain style of JS with some
by Silhouette 10y ago
Unfortunately, as abritinthebay noted, Closure Compiler doesn't really understand JS and compile it to better JS. It understands a certain style of JS with some significant limitations and compiles it to better JS as long as it actually runs in your browser.
We used it for a while but we've now completely abandoned it. The overheads of complying with its rules were significant, but worse, it sometimes produced output that didn't run in some older browsers where the original code did. Now, that might really not be Closure Compiler's fault, if the output it produced was technically equivalent to the input according to the JS standards. However, the fact is that we can't ship code that runs into bugs in production and whether those bugs come from the tools or the browsers does not change this.
We fixed that problem by removing the Closure Compiler step from our build process and switching to Uglify. It took a little time, but not much. It gave a handy speed-up in the development process, since CC is relatively slow. But most important of all, it has reliably produced working code from working code.
- lobster_johnson 10y agoUglify has actually gotten better the last few years, but Closure is still faster on multi-core machines. Here's Closure vs. Uglify on one of our apps: $ wc -c index.js | grep -v total 9320511 index.js $ cat index.js | time closure-compiler \ --warning_level quiet \ --third_party \ --jscomp_off es3 \ --compilation_level SIMPLE_OPTIMIZATIONS \ --language_in ECMASCRIPT5 > index.js.closure 2>/dev/null 33.54s user 0.93s system 369% cpu 9.336 total $ cat index.js | time closure-compiler \ --warning_level quiet \ --third_party \ --jscomp_off es3 \ --compilation_level ADVANCED_OPTIMIZATIONS \ --language_in ECMASCRIPT5 > index.js.closure-advanced 2>/dev/null 33.54s user 0.93s system 369% cpu 9.336 total $ cat index.js | time node_modules/.bin/uglifyjs \ --screw-ie8 --mangle --compress - > index.js.uglify 2>/dev/null 18.88s user 0.24s system 103% cpu 18.475 total $ wc -c index.js.*. | grep -v total 1750478 index.js.closure 1515331 index.js.closure-advanced 1763350 index.js.uglify $ gzip -9 index.js.* $ wc -c index.js*.gz | grep -v total 369749 index.js.closure-advanced.gz 397468 index.js.closure.gz 387896 index.js.uglify.gz This is Closure 20170218 (Oracle Java 8), uglify-js 2.4.19 (Node 6.8.1) on a quad-core MBP Pro 2015. Note the total times. Closure is heavily parallelized, and is twice as fast as uglify by using all 4 cores at almost 100% utilization. If you only have one core, though, Closure will be much slower. Of course, YMMV. It's true that Closure does a lot better if you use Google's Closure style, but it's not true that you have to. Without those tricks, Closure still produces code that's as compact as Uglify.
- Silhouette 10y agoInteresting. I'm running on a multi-core Windows box here, and if anything we see the opposite effect. However, our scripts are all quite simple, so I suspect the total is probably dominated by startup time rather than actual processing time with both tools. For us, it's the difference between a mildly irritating second or two vs. hardly noticeable at all, not the tens of seconds for the project you were looking at there.
- carrotmirror 10y agoMy experience with Closure and Uglify matches the benchmarks seen here: https://github.com/babel/babili#benchmarks https://github.com/babel/babili#benchmarks
- lobster_johnson 10y agoRan them on my machine; Closure is a bit slower, but not hugely so (still within a second of Uglify): https://gist.github.com/atombender/a10c8ad409abb6c4995a603749b0ef29 https://gist.github.com/atombender/a10c8ad409abb6c4995a60374...