Beyond simply shortening variable names, Closure Compiler with ADVANCED_OPTIMIZATIONS, does three other important steps:

• aggresive renaming – not only renaming local variables and functions, but it renames GLOBAL variables and functions. In this way, it can ruin your public API
• dead code removal – it removes functions you are not using and segments of unreachable code. This can be fine for some apps, but it is definitely risky for JavaScript libraries, that expose some functions which are supposed to be called only by client code.
• function inlining – inserting the function’s body instead of the function call, where appropriate

So it is true that without some additional work, the ADVANCED_OPTIMIZATIONS option will just ruin your code and your public API. Of course the solutions are at hand, but the question is if they worth the effort.

Keep your public API

If you provide ONLY the code below to Google Compiler, it produces empty output:

function hello(name){
    alert("Hello " + name);
}

What? Empty output? Well… yes, as you never call your function. Instead, for the next code:

function hello(name){
    alert("Hello " + name);
}
hello('jslog');

it produces the following output:

alert("Hello jslog");

This is smart! But we want to preserve our API (by the way, in the tutorial for Google Closure Compiler Advanced Optimizations, Google says on this page that the hello function is preserved, while it is NOT – see section Removal of code you want to keep and try the code online at Closure Compiler UI Tool)

So if the hello method above would be part of the public API, it would break third parties using it. Google proposes a solution for this: export the public objects/functions into the global namespace using the window object:

function hello(name){
    alert("Hello " + name);
}
hello('jslog');
window['hello'] = hello;

//and the output is:
function a(b){alert("Hello "+b)}a("jslog");window.hello=a;
//so the hello function is kept as a property on the global window object

Instead, if you use:

window.hello = hello;

you get

function b(c){alert("Hello "+c)}b("jslog");window.a=b;

which is surely not what you want. So make sure you use the window['public_name'] notation. You should also standardize the way you access properties in your objects, either using the array notation, or the dotted notation, otherwise the compiler could be mislead by a mix of the two. But sometimes we just need to use both, as properties may be automatically generated at runtime.

Other problems with the Google Closure Compiler ADVANCED_OPTIMIZATIONS are separately compiling blocks of code with dependencies to external JavaScript. The solution for this is

• using either exports like the above or with the goog.exportSymbol() or
• using extern files specifically provided as a compilation option

In any case, I think this is just a bit too clumsy.

Moreover, having a class and export all its properties/functions is quite a job to to if your app is already a large one. Just have a short example:

MyClass = function(name) {
  this.myName = name;
};
MyClass.prototype.myMethod = function() {
  alert(this.myName);
};
window['MyClass'] = MyClass; // <-- Constructor
MyClass.prototype['myMethod'] = MyClass.prototype.myMethod; <-- export mechanism

//the above compiles to
MyClass=function(a){this.b=a};MyClass.prototype.a=function(){alert(this.b)};window.MyClass=MyClass;MyClass.prototype.myMethod=MyClass.prototype.a;

Conclusions

After this short overview of the ADVANCED_OPTIMIZATIONS flag, I really think most people won't need it. If you already have a large library, having it compiled with advanced optimizations would be a total nightmare, as it would require a review of all public methods and properties and additional work for each. And the gain? Just a few kilobytes. I have tried compiling ExtJS Core with advanced optimizations and got aprox 62 KB, while with simple optimizations it is 74 KB. Not very well for the amount of effort it would require, in my opinion.

But if you still think advanced optimizations is for you, you are probably wanting to optimize a lot, and you should first start seaching for other ways to optimize - first, make sure you combine all your js code into one file. It's better to have one js file of 100KB rather than have 10 files each of 5 KB. So make sure you are doing every other possible optimization before moving to the advanced optimizations flag.

After all, it's up to you to decide if it's worth the effort!

PS: You can follow me on twitter @extjslog.

Google has launched a fantastic JavaScript “compiler” – Google Closure Compiler. The name is misleading, but the tool is great. This stands behind the famous apps from Google, like GMail, Google Maps, etc. Well, let’s see this in action.

What the compiler does is to minimize and obfuscate your JavaScript code. It has three levels of optimization: whitespace only, simple and advanced. There is nothing special about the whitespace only optimization. It’s clear what it does so let’s analyze a bit the other options! In this post I will introduce the simple optimizations option, and in a later post I will write an explanation about the advanced optimizations level.

Simple Optimization Level

This is the level you should play with first. It minimizes your code and also obfuscates it. Nothing new to this point. The good news is it also optimizes it and removes unreachable code or unused code.

// say we have this code... sayHi doesn't appear to be very useful
function hello(name) {
  function sayHi(){
     return "hi"
  }
  alert(name);
}
hello('New user');

After “compilation” the code becomes:

function hello(a){alert(a)}hello("New user");

Notice the name of the global hello function remained unchanged. This is good as this is our external API, and we don’t want to break it. Closure Compiler also renames parameters, local methods and identifiers. The name parameter has been renamed to a, and notice the unused sayHi method was removed.

Let’s see other samples as well:

function hello(name) {
  function sayHi(){
     return "hi"
  }
  return "greetings";
  alert(name);
}
hello('New user');

has been compiled to

function hello(){return"greetings"}hello("New user");
//with one warning (not part of the generated code):
//JSC_UNREACHABLE_CODE: unreachable code at line 8 character 2
//  alert(name);
//  ^

Wowww… that’s impressive. Notice the parameter to the hello method has been removed, as it is unused!

But what really got me is the “compilation” step. After all the name is not that misleading. Look at this

function hello(){
   alert('hello world'
}

Well.. it’s obvious. But try and put that in your browser, and it will break your coolest app. You can avoid that with Google Closure. Here is the result:

Number of errors: 2

JSC_PARSE_ERROR: Parse error. missing ) after argument list at line 4 character 1

JSC_PARSE_ERROR: Parse error. missing } after function body at line 4 character 1

Maybe this is one of the best parts of this “compiler”.

I have tried some tests with the Google Compiler against some libraries. Here are the results:

I though the results would be significantly better with ‘closure’, but you can see the difference is not that big. ExtJS uses YUICompressor for minification and obfuscation. Maybe so does jQuery. So you can still use YUICompressor confidently. It would just be interesting to test on code which is badly written, with many unreachable statements and unoptimized.

I have done the tests with jQuery and ExtJS using the compiler.jar Google offers. Simply run the compiler from command line on the library files, which have to be previously annotated with the following comments at the beginning of the files (these comments tell Google Compiler how to make the compilation):

// ==ClosureCompiler==
// @compilation_level SIMPLE_OPTIMIZATIONS
// ==/ClosureCompiler==

java -jar compiler.jar --js=ext-core-debug.js --js_output_file=ext-core.pack.js

You can also use the webapp UI Google offers at Google Closure Compiler Home.
I’ll come up with more details about the ADVANCED_OPTIMIZATIONS compilation in a later post.

Successful compilations!