Garrett Bluma

Web Developer

Google Closure Review

Friday, January 29th, 2010

Google Closure Logo

So when Google released their Closure library almost three months ago I thought to myself:

“Huh, that looks pretty cool. A modular, lightweight framework that has great UI tools. What’s not to love!?”

I wanted then to write a post back then detailing how excited I was about it, but enough people wrote good pieces early on ( here, here, and here) and I didn’t want to add to the noise.

In the meantime, I decided to use Google’s Closure in one of my projects. I needed to build an RIA (Rich Internet Application) type website that needed to dynamically pull in a lot of data. Having gotten through most of that project I feel like I can substantiate a review of the framework.

Great for UI, not so great for the basics

I initially got exicited about Closure becuase of the quality of UI elements that Google was distributing with the API. I assumed that everything has this same level of abstraction from the nitty-gritty and would simplify my code.

The failings of Closure exist in the simple tasks not the complicated ones, adding HTML to the DOM, doing an Ajax request, and even element selection. I’ll go into detail about each of these.

HTML Insertion

It’s easy to use element.innerHTML, but some work needs to be done to allow those added element to respond to events in all browsers. For example, IE6 will not register an event fired by an element created via innerHTML. If, however, that innerHTML is applied to an element outside the DOM and afterwards added via appendChild, then it works.

The following is a comparison of the same code:

Raw Javascript (5 steps)


var html = "<ul><li>a</li><li>b</li><li>c</li></ul>";
var el = document.getElementById( 'id_of_element' );
var container = document.createElement( 'div' );
container.innerHTML = html;
el.appendChild( container );

Google Closure (4 steps)


var html = "<ul><li>a</li><li>b</li><li>c</li></ul>";
var el = goog.dom.$('id_of_element');
var fragment = goog.dom.htmlToDocumentFragment( html );
el.appendChild( fragment );

jQuery (2 steps)


$('#id_of_element').html(
    "<ul><li>a</li><li>b</li><li>c</li></ul>"
);

Doing an Ajax Request (specifically JSON):

Here is a quick example of handling an Ajax request w/ some minor JSON validation. You don’t use eval() do you?

Raw javascriptTo be fair I don’t know if this one works


// Assumes we have a valid XmlHttp object via GetXmlHttpObject()
xmlHttp=GetXmlHttpObject();
xmlHttp.open("GET","form.php?format=json",true);
xmlHttp.onreadystatechange = function() {
    if (xmlHttp.readyState == 4) {
        var data = !(/[^,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]/.test(
	    text.replace(/"(\\.|[^"\\])*"/g, ''))) &&
            eval('(' + text + ')');
        // …
    }
});

Google Closure (4 steps)


goog.net.XhrIo.send( "form.php?format=json", function( event ) {
    if ( event.isSuccess() ) {
        var data = event.target.getResponseJson();
        // ...
    }
);

jQuery (2 steps)


$.getJSON('form.php?format=json', function(data) {
    // ...
});

Element Selection

I’ll admit, this is an unfair test since jQuery will always win this one. But the point is that Google doesn’t even try to make this easier for the programmer. Aside from some convenience functions there is nothing special. In my mind this proves the point that Google is much more focused on solving the complex problems and not the simple ones.

Raw Javascript


var el = document.getElementById('id_of_element');
var myDivs = []; // … just not worth writing this by hand

Google Closure


var el = goog.dom.$('id_of_element');
var myDivs = goog.dom.getElementsByTagNameAndClass('div','menu-item');

jQuery


var el = $('#id_of_element');
var myDivs = $("div.menu-item");

Conclusion

It’s not that Google Closure is bad, it’s not. And don’t discredit it because I don’t want to use it. There are a ton of great applications for it and I am very happy they released it. The main issue as I see it, is that just isn’t designed for rapid development — a feature I put high emphasis on. I don’t want to downplay any of their hard work but from my perspective I don’t see as much value in it as I used to.


  • Johannes
    Hm, not sure the application you developed was that rich.

    Just to make a few points:
    - Google's Code is designed for use across multiple frames while loading the library only once where you have to load jQuery in every frame.
    - If you want to play fair, compare the code that the compiler produces and not the actual source code
    - jQuery is primarily designed for DOM manipulation not for complex things (it doesn't even have any notion of inheritance, or classes built-in)
blog comments powered by Disqus

Categories