
UglifyJS 3 Released - pastelsky
https://github.com/mishoo/UglifyJS2
======
tomByrer
There is a separate branch for ES2015+ here:
[https://github.com/mishoo/UglifyJS2/tree/harmony](https://github.com/mishoo/UglifyJS2/tree/harmony)

The new primary committer, alexlamsl, is good about responding to bugs &
pushing out new versions fast:
[https://github.com/mishoo/UglifyJS2/issues?q=is%3Aissue+is%3...](https://github.com/mishoo/UglifyJS2/issues?q=is%3Aissue+is%3Aopen+label%3Aharmony)

But there is still no CHANGELOG. He is aggressive at updating the docs, so
you'll have to look at diffs yourself.

------
kjsthree
You can handle es6+ with the harmony flag but if you're already using Babel is
there any reason to use Uglify over Babili?

I believe Babili generates minified/mangled output directly from the Babel AST
which would be way more performant during the dev cycle.

~~~
abritinthebay
Because Babili rarely works on Production code (in my experience).

I'm sure some people can get it to work but on anything vaguely complex it
always errors out for me.

It's alpha software for a reason.

~~~
bmpafa
Similar experience. Tried it once last week & it was exceptions all the way
down. Dunno why Babili is attractive w/ battle-tested uglify still making big
moves.

~~~
abritinthebay
If you _start_ a project with it it probably works fine (in that you can fix
as you go).

------
sotojuan
Definitely not a confusing repository name :-)

------
scotth
What was improved with this release?

~~~
mjpuser
Here are the commits. Looks like the biggest backwards compatibility issue
comes from the "Drop Angular" commit. He also changed the screw_ie8 option to
be called ie8 now. A few bug fixes, too, but I'm definitely paraphrasing here.

[https://github.com/mishoo/UglifyJS2/compare/v2.8.23...v3.0.0](https://github.com/mishoo/UglifyJS2/compare/v2.8.23...v3.0.0)

~~~
gavinpc
Uglify is a mature and widely-used package. I use it and I love it. It's been
years since uglify2, and I was excited to see this.

But... it appears that there are no release notes for version 3, apart from
the three negative points at the top of the README: backwards incompatible,
twice as slow on the latest Node, and still no ES6 ( _edit_ out of the box).
No rationale for (or detail of) the breaking change is given. Really bizzare.

~~~
pygy_
Given the (rude and unhelpful) reply from the team, I suppose it was a
premature release.

[https://github.com/mishoo/UglifyJS2/issues/1875](https://github.com/mishoo/UglifyJS2/issues/1875)

~~~
Thorncorona
The issue opener's phrasing was probably why the response was also rude.

~~~
lucideer
While the issue opener is quite brisk and curt, they hardly goes as far as
overt rudeness. The blank non-response is astoundingly rude and dismissive in
contrast.

~~~
carrotmirror
Give me a break. The project maintainer is volunteering his time to help the
javascript community and is doing a fantastic job fixing dozens of bugs and
adding new optimizations and features - often the same day as issues are
opened. Rather than nag him, step up and review the commits yourself and make
a pull request implementing a ChangeLog.

~~~
lucideer
Exactly. And asking the opener (or somebody in general) to do so would've been
a reasonable and polite response.

Unceremoniously closing the ticket on the other hand seems to me to indicate
the maintainer really doesn't care.

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

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

~~~
frik
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.

~~~
Silhouette
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
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.

~~~
carrotmirror
My experience with Closure and Uglify matches the benchmarks seen here:

[https://github.com/babel/babili#benchmarks](https://github.com/babel/babili#benchmarks)

~~~
lobster_johnson
Ran them on my machine; Closure is a bit slower, but not hugely so (still
within a second of Uglify):

[https://gist.github.com/atombender/a10c8ad409abb6c4995a60374...](https://gist.github.com/atombender/a10c8ad409abb6c4995a603749b0ef29)

------
iso-8859-1
Support for pure annotations was added.

[https://github.com/mishoo/UglifyJS2/commit/1e51586996ae4fdac...](https://github.com/mishoo/UglifyJS2/commit/1e51586996ae4fdac68a8ea597c20ab170809c43)

This will enable removing unused transpiled classes from e.g. Babel.

See
[https://github.com/mishoo/UglifyJS2/issues/1261](https://github.com/mishoo/UglifyJS2/issues/1261)

------
angry-hacker
How much does these uglifiers slow down the code for a the client? Especially
if you're using a mobile or slow arm machine? I started to think about these
things when u started using an arm based chromebook. Stupidly bloated js heavy
sites started to stand out. Facebook is unusable, slightly better if you
disable extensions.

~~~
koolba
Minification makes code both faster to download (less total bytes) and faster
to execute (less memory usage for symbols and dead code elimination).

~~~
angry-hacker
Well, in most cases my test with minifiers is that output code performs worse
than uncompressed code.

~~~
Klathmon
What minifiers?

Some do very much trade speed for size, but in my experience the opposite is
overwhelmingly true.

------
DonHopkins
Syntactic Sugar Sculptures!

------
Touche
Sadly it still only supports ES5.

~~~
abritinthebay
ES6 is supported behind a flag

~~~
phpnode
Nope, it's supported in the Harmony branch, which is still under development

~~~
abritinthebay
Realized I was thinking about Uglify-ES which _also_ came out.

So.. there are options :D

