Hacker News new | ask | show | jobs
by SpencerWood 3484 days ago
Why would I use this over babel?
7 comments

The advanced compilation mode does some pretty powerful dead code removal and minification [1]. I guess that is available from plugins in Babel as well but Google has been using it for Gmail, Google.com etc, so it's quite battle tested.

[1]: https://developers.google.com/closure/compiler/docs/api-tuto...

Dead code removal relies heavily on writing JS in a style that allows for static analysis. Dynamic requires, heavy usage of closures, knowledge of external/global variables are all things that prevent a lot of commonjs code from being removed. https://developers.google.com/closure/compiler/docs/limitati... has more information if you're interested in the assumptions that the compiler makes.

Interestingly, we're finally starting to see these ideas get more mainstream as people adopt es6 modules and publish bundled code with explicit externs in tools like Webpack 2 and Rollup.

Works very nicely as an LLVM of sort for alt.js languages though, as they can generate JS in such a way that it matches clojure's constraints and requirements.
In my experience Babel minified better than Closure Compiler with less maintenance of the externs on my part.
Only possible in simplified mode. I highly doubt Babel comes close with full optimizations turned on in a nontrivial codebase.
With what plugins? Babel without any plugins or with the common ES2015 plugins doesn't do any minification.
Perhaps you meant UglifyJS or Babili instead?

Babel can be used in the same toolchain as Closure Compiler, they're not mutually exclusive or redundant as they perform different tasks.

They do different things.
It's not the same as Babel. You'd use it instead of Webpack, for example.
afaik babel isn't about performance, but linguistic traits.
you like lisp