UglifyJS 3 Released | Hacker News Reader

UglifyJS 3 Released

github.com

60 pointspastelsky46 comments

There is a separate branch for ES2015+ here: 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...

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

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.

Babili is interesting for sure, but it's at version 0.0.12, clearly marked as beta, requires a bleeding edge Babel, and is 4-6 times slower than Uglify and produces larger output bundle in every single benchmark case with popular libraries on the Babili page itself.

So yes, there is clearly still plenty of reasons to use boring old Uglify.

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.

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.

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

If the concern is Uglify slowing down the dev cycle, you could turn it off for development builds.

Definitely not a confusing repository name :-)

What was improved with this release?

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

> He also changed the screw_ie8 option to be called ie8

That's a shame, I always enjoy that silly bit of humour every time I scan my uglify configs!

I totally get why it's safer to not do that sort of thing, nonetheless it does have a certain charm when done sparingly. I wonder if the change was in response to some specific feedback / complaints?

Maybe in Victorian times using the word 'screw' would be considered offensive. The explanation is likely much more inoccuous. Using negative variable names is confusing and leads to programmer errors.

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.

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

https://github.com/mishoo/UglifyJS2/issues/1875

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

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.

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.

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.

it now mangles property names.

but still to see if as good as the custom solution we have. it's something we did since early 2000 and save us a good 30% of size. but dangerous as hell.

UglifyJS2 also supports this with the --mangle-props option [1]. Is there something different about how this is done in UglifyJS3?

[1] https://github.com/mishoo/UglifyJS2/blob/master/README.md#us...

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

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

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.

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.

Which is exactly the approach ClojureScript takes: it writes the annoying annotations for you.

Well... then you're writing Clojure/Lisp, not JavaScript.

Nothing wrong with that as such but it's a completely different thing.

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.

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.

Interesting. 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.

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

https://github.com/babel/babili#benchmarks

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

The Closure Compiler doesn't use Rhino anymore.

https://groups.google.com/d/msg/closure-compiler-discuss/9WM...

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

My experience too. 5k saved once gzipped was not worth the extra 2-5 minute compression time.

Support for pure annotations was added.

https://github.com/mishoo/UglifyJS2/commit/1e51586996ae4fdac...

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

See https://github.com/mishoo/UglifyJS2/issues/1261

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.

>How much does these uglifiers slow down the code for a the client?

I thought minification is good for the client. Smaller payload, easier for browser to parse the code because it doesn't have any unnecessary white space, comments and characters. Also not the best solution to security, but does obscure the code to make it harder for malicious client to read through the code.

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

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

What minifiers?

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

Syntactic Sugar Sculptures!

Sadly it still only supports ES5.

ES6 is supported behind a flag

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

Huh, thanks for the heads up. Could have sworn that was in there.

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

So.. there are options :D

Reply on news.ycombinator.com