Why Do We Need Google Closure?

3

Posted on : 01/04/2010 | By : Jimmy Vu | In : Development News

Why Google Closure?

When a new JavaScript library arrives, a question is often raised reasonably: “Why does the world need another library?” while we’ve already had too many good ones like jQuery, Prototype, Mootools, YUI… you name it.

To find the right answer, just have a look at the package offered by Google under the name of Closure project. We’ll find there three sub-projects:

  1. Closure Compiler: a JavaScript optimizer. This is not a “yet another JavaScript compressor”, it can do more: Besides compressing your codes it can analyze your code and remove “dead” parts, correct wrong syntax, check variable references/types, warn about common pitfalls. The really good news is it comes with a Firebug extension, called Closure Inspector, that allows us to debug compressed code by linking obfuscated lines to original ones.
  2. Closure Library: a JavaScript library (as we expect) intended for use with  Closure Compiler. Basically it can do all the common tasks like other libs such as DOM manipulation, server communication, animation/effect and encloses a large set of reusable UI widgets and controls.
  3. Closure Templates: is not just a client-side JavaScript template engine like Pure but can be used in server-side with Java.

Closure Library is a big library with more than 400 JavaScript files well organized into Java-like directory structure. We’ll find there something like packages, classes/sub-classes with Java-doc syntax description (in fact, you know, there are no true packages/classes in JavaScript.)

Google don’t boast the library in term of better speed or DOM manipulation techniques, the advantages of Closure lie in application deployment. Powered by Closure Compiler, application using Closure Library can be highly object-oriented in development while can be compact, fast and safe in production. An example is worth a thousand words, so let’s see official “Hello World” application in development and deployment.

1. JavaScript

+ Get and put the lib into a directory called closure-library-read-only

+ Create a JavaScript file (hello.js):

1
2
3
4
5

goog.require('goog.dom');
function sayHi() {
    var newHeader = goog.dom.createDom('h1', {'style': 'background-color:#EEE'}, 'Hello world!');
    goog.dom.appendChild(document.body, newHeader);
}

The most notable line is the first line that dynamically includes goog.dom for DOM manipulation (which is defined in dom/dom.js file). All other “packages” can be included in the same way.

2. HTML

Now, create a HTML to display the result (hello.html):

<html>
    <head>
        <script src="closure-library-read-only/closure/goog/base.js"></script>
        <script src="hello.js"></script>
    </head>
    <body onload="sayHi()">
    </body>
</html>

We’ll need to add base.js which is a bootstrap file to load other JavaScript files required and of course the hello.js file we’ve just created.

3. Deployment

The above example works as long as you don’t mind to deploy 400+ files and let the application load all necessary JavaScript files (12 files weighted 356KB as captured image from Firebug below).

Google Closure JS Files Loaded

However, thinking of an application with hundreds of JavaScript files required, usability would be a nightmare for this approach and that’s why Google provides a tool named Dependency Calculation Script to relief the pain. The tool, as its name implies, can calculate dependencies for application and create a single JavaScript file. Using the tool in conjunction with Closure Compiler to remove redundant code you will end up with perfect result: all-in-one, small, fast and safe JavaScript file.

Here is how to create the final script:

closure-library-read-only/closure/bin/calcdeps.py -i hello.js \
  -p closure-library-read-only -o compiled \
  -c compiler.jar \
  -f "--compilation_level=ADVANCED_OPTIMIZATIONS" \
  > hello-compiled.js

Note: Because the advanced optimization functionality of Closure Compiler is to include only code portions that are called in file, before running above compilation command you’ll need to modify script hello.js slightly to execute onload function as follows:

1
2
3
4
5
6
7
8
9

goog.require('goog.dom');
function sayHi() {
    var newHeader = goog.dom.createDom('h1', {'style': 'background-color:#EEE'}, 'Hello world!');
    goog.dom.appendChild(document.body, newHeader);
}
 
window.onload = function(){
    sayHi();
};

And don’t forget to remove onload call from HTML:

<html>
    <head>
        <script src="hello-compiled.js"></script>
    </head>
    <body>
    </body>
</html>

Now, look at the final result: a 3KB JavaScript file loaded in 64ms vs 356KB in 414ms respectively of un-optimized version that interprets to more than one hundred times better in size and seven times better in loading speed. (FYI, gzipping output, we’ll have less than 1KB file load only).

Google Closure JS File Load Optimized

Conclusion

I neither see Closure Library as yet-another-JS-lib nor see Closure Compiler as yet-another-JS-compressor. They together provide a complete solution to create and deploy sophisticated web apps with confidence.

It would not be a surprise that Google developers are using similar tools internally to create great web apps like GMail, Wave so it makes sense that we can utilize Closure to build a web application with the same level of efficiency, completion and beauty.

Related Reading:

Share this :

  • Stumble upon
  • twitter

Comments (3)

Dario said on 31-01-2010

Interesting, thank you.

Sonny Tan said on 06-01-2010

How does Closure compare with jQuery in term of flexibility?

Jimmy Vu said on 06-01-2010

Did you mean about plugins? I don’t thing Google Closure is ideal for plug-n-play plugins like jQuery for it doesn’t provide fixed set of core modules.

However, you can create a plugin/widget and let user compile it for production if they think it’s OK to include its dependencies.