7 ms·

I've switched to google-closure-compiler-js, which eats ES6 by default.

by imcotton 9y ago

paulddraper 9y ago
In my experience: slightly smaller js, and significantly slower.
- frik 9y ago
  Closure compiler understands your code, it is using Java based Rhino Javascript engine. And using "advanced mode" it is really good - just make sure you read the docu to understand advanced mode! edit: What you meant with "it barely understands your code" is probably: if you compress just one JS and they access third party libraries, you have to write some annotation OR import their object namespaces (the annotation style is a bit weird in JS world and looks like Java Doc comments, but you can completely avoid it as I mentioned; read the documentation) Closure Compiler compiles from JavaScript to better JavaScript. It parses your JavaScript, analyzes it, removes dead code and rewrites and minimizes what's left. It also checks syntax, variable references, and types, and warns about common JavaScript pitfalls. UglifyJS and co don't understand Javascript, they do regex/string replace operations which is faster, but you get bigger code output and less warranty as they don't understand JS.
  - abritinthebay 9y ago
    It barely understands your code. To get any real benefit out of it you have to write your JS using Googles special rules, idiosyncrasies, and idioms. Then you'll get a lot of use out of it.
    - moomin 9y ago
      Which is exactly the approach ClojureScript takes: it writes the annoying annotations for you.
      - abritinthebay 9y ago
        Well... then you're writing Clojure/Lisp, not JavaScript. Nothing wrong with that as such but it's a completely different thing.
  - deleted 9y ago
    [deleted]
  - Silhouette 9y 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 9y ago
      Uglify 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.
  - iso-8859-1 9y ago
    The Closure Compiler doesn't use Rhino anymore. https://groups.google.com/d/msg/closure-compiler-discuss/9WM9LvXLhlk/PI5BhvFjr6cJ https://groups.google.com/d/msg/closure-compiler-discuss/9WM...
  - paulddraper 9y ago
    > And using "advanced mode" it is really good Yep. This is what CC was really made for. Most people don't want to write adv mode compatible JS, but it can pay off big. ScalaJS produces adv mode compatible JS, and uses Closure Compiler on it.
- abritinthebay 9y ago
  My experience too. 5k saved once gzipped was not worth the extra 2-5 minute compression time.

I've switched to google-closure-compiler-js, which eats ES6 by default.

paulddraper 9y ago

In my experience: slightly smaller js, and significantly slower.

frik 9y ago
Closure compiler understands your code, it is using Java based Rhino Javascript engine. And using "advanced mode" it is really good - just make sure you read the docu to understand advanced mode! edit: What you meant with "it barely understands your code" is probably: if you compress just one JS and they access third party libraries, you have to write some annotation OR import their object namespaces (the annotation style is a bit weird in JS world and looks like Java Doc comments, but you can completely avoid it as I mentioned; read the documentation) Closure Compiler compiles from JavaScript to better JavaScript. It parses your JavaScript, analyzes it, removes dead code and rewrites and minimizes what's left. It also checks syntax, variable references, and types, and warns about common JavaScript pitfalls. UglifyJS and co don't understand Javascript, they do regex/string replace operations which is faster, but you get bigger code output and less warranty as they don't understand JS.
- abritinthebay 9y ago
  It barely understands your code. To get any real benefit out of it you have to write your JS using Googles special rules, idiosyncrasies, and idioms. Then you'll get a lot of use out of it.
  - moomin 9y ago
    Which is exactly the approach ClojureScript takes: it writes the annoying annotations for you.
    - abritinthebay 9y ago
      Well... then you're writing Clojure/Lisp, not JavaScript. Nothing wrong with that as such but it's a completely different thing.
- deleted 9y ago
  [deleted]
- Silhouette 9y 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 9y ago
    Uglify 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.
- iso-8859-1 9y ago
  The Closure Compiler doesn't use Rhino anymore. https://groups.google.com/d/msg/closure-compiler-discuss/9WM9LvXLhlk/PI5BhvFjr6cJ https://groups.google.com/d/msg/closure-compiler-discuss/9WM...
- paulddraper 9y ago
  > And using "advanced mode" it is really good Yep. This is what CC was really made for. Most people don't want to write adv mode compatible JS, but it can pay off big. ScalaJS produces adv mode compatible JS, and uses Closure Compiler on it.
abritinthebay 9y ago
My experience too. 5k saved once gzipped was not worth the extra 2-5 minute compression time.