State of YUI Compressor

By YUI TeamOctober 16th, 2012

YUI Compressor has been a great tool for obfuscating and compressing JavaScript and CSS files for several years, but as the web continues to evolve and change, so do the tools we use to develop it. YUI Compressor will be going through a deprecation process as the YUI team moves to using a custom-wrapped UglifyJS for JavaScript compression and a more fully updated and maintained version of CSSMin for CSS compression. This will allow YUI to move beyond the limitations of the current YUI Compressor as well as take advantage of the current state of the art in compression. As a JavaScript library, we are always striving to remove non-JavaScript tools from our system. Having a full JavaScript stack allows our full team and every contributor to update, extend, and help maintain our tools. Which, for us, is a huge win!

The new compression utilities are wrapped into a single node package called yuglify and new issues can be filed against this project on GitHub. To be clear, this is not a “new compressor” project, this project contains a few tweaks and configuration options that allows us to use UglifyJS & CSSMin in a standard way across our tools. In fact, this new module was pulled directly from existing Shifter tasks to allow for better portability and re-use across any NodeJS tool.

We have migrated the existing YUI Compressor website to its new location on GitHub (pending some redirects from the old site) as well as previous releases. We are considering migrating all of the current open tickets from the site over to GitHub’s issue tracker but will only do so if any new community maintainers wish us to.

Not only are our tools evolving but the way we are open-sourcing development is as well! For the first time ever, we will be opening the YUI Compressor project to external community members, including commit access to the repo. We are working to implement a governance model that defines committer access across our product offering. Stay tuned for more details on the YUI Governance Model in the next few weeks. We are very excited to be starting this new chapter in the evolution of our project, and we invite to you participate in this new process and help us continue to build the best toolset for web development.


  1. Absolutely the right move. I haven’t run the numbers in a while, but YUICompressor was well behind the curve of the other, more actively maintained JavaScript and CSS Minifiers. It was a great project, and was absolutely state of the art in what was publically available when it was first released, but it has languished, and it’s worth now just moving on.

  2. I am currently using the old YUI Compressor in my own project. Now with the new one introduced, how to migrate?

  3. @Khoa – There is no “new one”, there is no “replacement”. It’s being deprecated in favor of new tools developed by others.

  4. @Dav: YUI Compressor is still there and still works. However, you know, when something new introduced, we just want to taste it, and then migrate if suitable.

  5. I suggest you try to use CSSO ( instead of CSSMin. It’s better.

  6. Khoa, just `npm -g i yuglify` to get Dav’s wrapper around both UglifyJS and CSSMin. Per Dav’s instructions on the github page for yuglify, it’s as simple as `yuglify path/to/file.js` to be left with path/to/file-min.js or css

  7. UglifyJS doesn’t seem to do as good of a job as Closure Compiler. What made YUI team pick Uglify?

  8. From my tests Uglify does a better job than Closure & less config. It wasn’t a trivial thing to get YUI to compress with Closure due to creating the configs for known variables. The way YUI defines itself locally then exports itself in CommonJS environments meant that I needed 2 separate configs for the library & that was overhead that I didn’t need nor want to support for the long term.

  9. There are A LOT of opensource projects using yui compressor. Many of them using it just as a compile-time tool for js minification. is one I can think of at this time. This news is important to them.

  10. Donald, Closure Compiler makes a lot of assumptions when it compresses that simply fail with YUI’s use-case. The biggest one is that YUI does not compress the entirely library as one file, it compresses each module indepedently. This means that a large number of Closure Compiler’s optimizations (that it can do because it assumes that JS files are mostly large and monolithic), don’t apply for YUI.

    Closure Compiler is great, if your application is built the way Closure is.

  11. [...] Compressor 是壓縮 JavaScript、CSS 的程式, 但是看起來已經不維護了(詳見: State of YUI Compressor), 建議改成使用 yUglify [...]

  12. All due credit to Dav and the YUI crew; yuicompressor has been a key part of my toolchain for years, which is what prompted me to get my employer to sign the license assignment so that we could push some of our changes back upstream.

    While I’m sure yuglify will be a great tool, I continue to be satisfied with yuicompressor and how it fits into our workflow.

    For those interested, I will continue to support yuicompressor via my github fork,

  13. @Joey Feel free to email me (davglass AT gmail DOT com) and we can discuss you maintaining Compressor ;)

  14. [...] we announced that we were deprecating our use of YUI Compressor. Many people still rely on Compressor for their day to day work and are still using it in their [...]