Late last year, Google releasedClosure
Tools, a trio of open source technologies aimed at
developers writing large scale JavaScript applications. Included
in the initial release were Closure Compiler, a sophisticated
JavaScript compiler, Closure Library, a massive library of
JavaScript code designed for use with the Compiler, and Closure
Templates, a templating system implemented in both JavaScript and
Java.

The sales pitch was certainly compelling. Closure had been
used internally at Google since 2005, with contributions from over
400 engineers. This was the technology that powered Gmail, and
several other high profile Google applications (Docs, Reader,
Calendar, Maps and Wave amongst them). Google pitched it as their
"standard library" for JavaScript-based applications. It
would have be reasonable to expect that the hype meter would have
been off the charts.

Despite this, the response was rather tepid. The
announcement spread broadly, but the standard response seemed to
be "so what?". Not much has changed in the six-plus months
since its release, either. In the past 30 days, there have been a
grand total of three questions tagged with google-closure
on Stack
Overflow. During the same time period, there have been
3,161 questions about jQuery.

So, what's the problem? Is it the confusing name (a closure
is a JavaScript language feature)? "Anti-hype" due to the
fact that it was released by Google? Exhaustion from the rapid
pace of new JavaScript library releases? A lack of conceptual
documentation? Or, is it just too complex to actually use?

I think all of these may be factors to some degree, but the
real reason is much simpler: it's simply not the right tool for a
lot of applications. That's not intended as a criticism of Closure
Tools, it's just that it was designed with far different goals
than other popular libraries like, say, jQuery and Prototype.

For small applications, blogs, design galleries, or static
content sites which just need some simple form validation, Closure
is probably overkill. It is a perfectly suitable
solution, as the Closure Compiler enables an efficient footprint
for applications of any size. However, the learning curve is quite
steep, there are far fewer examples, and you need to find a way to
integrate the compiler into your workflow. With a library like
jQuery, you just add a script reference (if using a CDN,
you don't even need to upload it to your server) and start coding
away.

So aside from large Web applications from Google, who is
Closure for? Having studied Closure exhaustively for the past few
weeks, I would suggest that it is an excellent option to consider
for any "medium-plus" sized application, regardless of the
back-end "technology stack". These applications will almost
always involve multiple developers, and are likely to contain at
least 100 kilobytes of non-library source code. If there is no
build system in place to combine scripts, an average page in an
application of this size probably references 5 to 10 external
scripts, if not more.

If your application has reached this level of complexity (or
you project it to), this is a good starting point where the
benefits of Closure start to become significant. The impact of
Closure Compiler on your code's execution speed and size (and, if
your scripts aren't being combined, HTTP request overhead) will be
significant, and you're likely to be in position to benefit from a
large portion of Closure Library as well. As your application
grows, so do the benefits. Let's take a closer look at the two
primary components of Closure Tools (we'll not be covering Closure
Templates).

Closure Compiler

The Closure Compiler is the arguably the flagship component
of Closure Tools. The Compiler supports two primary optimization
modes: "minification" (whitespace-only or simple) and
"advanced compilation".

A JavaScript minifier is nothing new. There have been high
quality minifiers available for several years. A JavaScript
compiler isn't even necessarily new, as compilers from other
languages to JavaScript have also been floating around for some
time. What is unique about Closure Compiler is that it is a
JavaScript-to-JavaScript compiler, capable of performing
optimizations to JavaScript code that were previously unheard
of.

Closure Compiler can be used as a standalone component
against an existing JavaScript codebase, or in concert with
Closure Library, which has been explicitly designed for maximum
optimization when used with the compiler. It's easier to
understand the power of these advanced compilation features by way
of a simple example. Consider the following script:

After running this through the compiler in advanced mode
(which you can easily try for
yourself), we're left with the following:

alert("Hello, friend!");

The result speaks for itself. The compiler eliminated dead
code, inlined functions, optimized string concatenation, and left
us with a significantly smaller but functionally identical
result.

Hey, where'd my functions go?

It might seem strange or abitrary that in the examples
above, the unused functions simply disappeared in the output. The
compiler considers this removal perfectly safe and reasonable
because it assumes that you have provided it with the entire
source code for your application. If you want one of your
functions to be available outside of the context of your core
JavaScript code (say, from a script element in
an HTML page), you need to explicitly tell the compiler to export
it. See the compiler
documentation for details.

This isn't to say that there won't be any function calls in
your final compiled output if you don't export anything. Closure
Compiler will only inline code when it considers it
appropriate. When not inlining, functions will typically be
renamed. If the compiler chose not to inline our
hello function, for example, the output
would look something like the following:

function a(b){alert("Hello, "+b+"!")}a("friend");

I'm supposed to debug that?

If your reaction to the above code is one of terror, you are
probably not alone. Anyone who has written large systems in
JavaScript knows that debugging code is an inevitable part of the
process. The significant optimizations provided by Closure
Compiler might make your code smaller, but they also make it
extremely difficult to map back to the original code. If you
experience a runtime failure that only happens in the compiled
code, what do you do?

Fortunately, Closure Compiler is capable of creating a
source map, which enables areas of the compiled code to be
definitively traced back to the original source from which it was
compiled. Even better, you don't have to work with the source map
file itself, as Google provides Closure
Inspector, a Firebug extension (yes, Firefox only for now)
which integrates into your standard debugging experience.

Is that it?

While Closure Compiler is an excellent tool for optimizing
code size and execution speed, that's not the only value it
provides. It also supports a huge number of JSDoc
annotations which enable it to help you find bugs in your
code (these also allow the compiler to even better optimize your
code). For example, we could redefine our
hello function from above with a type
annotation as follows:

Here, we have told the compiler that we expect a single
parameter of type string. Now, let's add some
problematic calls to the function:

hello();
hello(3.14);

Now, when we compile this code, the compiler issues the
following warnings.

JSC_WRONG_ARGUMENT_COUNT: Function hello: called with 0 argument(s).
Function requires at least 1 argument(s) and no more than 1 argument(s).
at line 5 character 5
hello();
^
JSC_TYPE_MISMATCH: actual parameter 1 of hello does not match formal parameter
found : number
required: string at line 6 character 6

With large programs in particular, these warnings can help
you quickly isolate hard to find bugs that would otherwise only be
visible at runtime. The only downsides are the need to add the
JSDoc tags to your code comments (though these are also quite
useful as documentation when reading the code), and the need to
"cast" from time to time, as below:

Closure Library

Closure Library is a massive library of JavaScript code
optimized for use with Closure Compiler. In theory, pairing it
with the Compiler is optional. And in fact, this is an incredibly
important feature in development environments, as it makes the
compilation step optional and dramatically speeds some stages of
development. In production, however, use of the compiler is
not optional, as the uncompiled library code is very
large, and the strategy used to include the files is not designed
to be efficient.

So just how big is Closure Library? The following chart
provides some indication. This is the uncompressed, non-minified
JavaScript on-disk file size of a few popular libraries (excluding
test code), as reported by du. The file
sizes include comments and indentation, so it is not meant to be
indicative of the actual number of "lines of code". All
libraries shown are the current stable versions at the time of
this writing:

So yes, the library is indeed massive. But is it any good?
For starters, there are no "versions" of Closure Library.
The code is simply updated periodically in a public Subversion
repository, which is fed from Google's internal source control
system. That doesn't mean that it's "prerelease" (or
"beta") quality, it simply means that Google is confident
enough in the quality of the code that the latest release is
always considered to be (in their own words) "very
stable". Many parts of Closure Library are actively in
production at Google, and it comes with a massive suite of unit
tests. At the end of the day, it's up to you and or your
organization to determine if it is "stable" enough for your
needs. Having spent a large amount of time in various modules of
the Closure Library code recently, my personal opinion is that it
is uniformly well designed, well documented, and very well
written.

So what's in there, taking up all of that space? A
surprising amount is in comments, believe it or not. Closure
Library is exhaustively documented, and most of the
documentation is inline. This makes browsing the code a great
strategy for learning more about Closure. As far as the code
itself is concerned, some portion of the library is dedicated to
things that would be broadly useful in any JavaScript project,
including those that do not target Web browsers (array,
crypt,
date,
math,
string,
and more). A bigger portion of the code is exclusively designed
for JavaScript applications targeting browsers (dom,
editor,
fx,
history,
style,
ui,
useragent,
and more). A good starting point for understanding what's
available in Closure Library is the demos
folder (index),
where you'll find examples for things as basic as event
handling, and as exotic as a popup
"emoji" picker. Lastly, Closure Library also includes
selected third party code. For example, Dojo's Query
implementation is exposed as
goog.dom.query.

Closure Library code is modular, with related code organized
into "namespaces". This organization is well suited for large
scale projects with large teams. Another advantage of this
namespacing strategy is that Closure Library is extremely unlikely
to interfere with existing libraries, as all of the library code
is organized under a single global symbol
(goog). Note that this does not necessarily
mean that other libraries will not impact the behavior of Closure
Library. Existing libraries that pollute the global namespace
unpredictably, or modify the prototypes of built-in JavaScript
types could cause Closure Library code to behave undesirably (as
it would with any other third party library). To put it more
succinctly, Closure Library plays well with others, provided that
they too play well with others.

The downside to the namespacing strategy is that your code
ends up being more verbose. There are many ways to control for
this. You might decide that your application won't need to
interoperate with other libraries, and can safely add aliases for
commonly used functions in the global namespace. For example, if
goog.dom.getElement is too much typing for your
taste, you can selectively trade off namespacing by simply adding
a global alias as $:

goog.exportSymbol('$', goog.dom.getElement);

There are, of course, risks to modifying the global
namespace in this fashion, so it's undoubtedly a good thing that
the Closure Library designers left the decision to us.

Closure Library vs. jQuery, Prototype

So if we don't modify the global namespace, what does
Closure Library code actually look like? This is probably easier
to understand by example. Following are ten simple code examples
comparing the syntax of Closure Library to two other popular
libraries: jQuery and Prototype. I created these examples by
looking through a few codebases built on top of the libraries,
choosing the most popular examples which corresponded to
functionality common to all three. My intent is not to make one
library look better than the other, but rather to compare the
style and syntax. The examples are functionally equivalent.

In general, the Closure Library examples are more verbose
than the equivalents written using jQuery and Prototype. After
being run through the compiler, they will be more compact at
runtime, but there is some extra visual overhead to deal with when
reading and writing Closure Library code. Of course, as discussed
above, Closure Compiler helps a great deal when writing this code,
as it can find bugs before you run them in the browser.

All of these libraries are quite easy to work with for such
trivial examples as those above. The real benefits of Closure are
found in larger codebases. If you're working on such a codebase,
or are about to, I strongly suggest giving Closure Tools a
look.

Comments

We use GWT instead of Closure. When we started developing Closure was freshly released and since it's used in Google Docs, Gmail, etc. we were strongly considering it.

In the end there were a few features in GWT that made it worth to write Java instead of Javascript:

* UiBinder (http://code.google.com/p/google-web-toolkit/wiki/UiBinder) Which is Templating + CSS Sprites + much more

* Deferred Binding (http://code.google.com/webtoolkit/doc/1.6/FAQ_Client.html#What_is_Deferred_Binding?) GWT automatically compiles multiple .js files, each for a different browser/locale combination. It's extremly easy to add another parameter to it, like - in our case - iPad support. If you visit letsannotate.com on your iPad we switch out the View Classes to provide a touch optimized experience.AFAIK Closure has no equivalent to deferred binding

* MVP architecture: When we were evaluating GWT vs. Closure it became clear that Patterns and Best Practices for developing large applications are much more readily available for GWT than for Closure. (e.g. http://code.google.com/events/io/2009/sessions/GoogleWebToolkitBestPractices.html)While Closure was used to write GMail, there seems to be no agreed upon best practice for navigation, MVP separation and so on. This is where GWT shines the most. It's incredibly easy to architect an application that's capable of growth, simply because Google tells you how to do it. While the API reference for Closure Library is comprehensive, I didn't find any such documentation.

All in all I'd currently recommed GWT for Web App development over Closure, but that might change in a year or two if Google (or someone else) releases similiar best practice code for Closure.

Thanks for a great introduction of Google Closure tool. Yes, it's an overkill for light applications. I prefer jquery over Google Closure.

Sunday, March 25, 2012 8:19:42 AM by Dave Fisher

Closure is pretty easy to use, but I run into situations all the time where I need to need to compile again just to make a small change. I get annoyed by that (for example with Chrome Extensions). Overall I find the framework very easy to use. Once you find an example Ant build file for closure builder. :)

The Google Closure tools is one of the best tools that helps programmers/developers to make web applications using this Google Clousure tools. This clousure tools was developed by Google developers for using this tool in their web applications like gmail, google docs and google maps and many more.