The entry point for getting started with a library is usually a small "Hello World" application.
I'm not impressed at all with Google Closure's Hello World example.
Not sure if it's just a bad example, or if it shows very well what the library is about.
Widget's base classes
Ext JS's class hierarchy for UI components such as the Tree widget is:
Google Closure's class hierarchy for UI components is:
Equivalents of the
goog.events.EventTargetclass seems to be the equivalent of Ext JS's
goog.ui.Componentseem to be the equivalent of Ext JS's Ext.Component class.
Ext.Panelclasses, which handle components layouts, can't be found in the Google Closure's hierarchy since Google Closure seems to be missing a layout manager.
One of many reasons that made me a fan of Ext JS is its powerful layout manager that wasn't included in Yahoo UI's library at the time I started using Ext JS.
Google Closure doesn't seem to have a layout manager included at all, which is a big turn off for me. I couldn't live without it anymore.
Google leaves the layout part completely up to you, so you still have to hack your CSS or HTML tables right, to place your widgets where you want it to be.
Google Closure's event handling logic is placed into the
events.EventTargetclass, whereas Ext JS's event handling logic can be found in the
It looks like that you can only specify a handler and the event name in Google's solution.
Ext JS's solution seems to be more powerful, since you can specify optional options such as scope, delay, single, buffer and target.
Moreover I like Ext JS method names more, especially the "on" shortcut for the addListener method. Google Closure's names are
addEventListenerfor adding listeners, and
dispatchEventfor firing events, which is the equivalent of Ext JS's
Documentation aka API reference
For me the Ext JS documentation in terms of look and usability is clearly superior to a lot of other open-source software projects, including Google Closure's documentation.
Google Closure's documentation browsing is a bit odd, since the class references are placed on the bottom right, which you constantly have to scroll to. The two panel solution of Ext JS's documentation definitely makes browsing easier.
The actually documentation pages for each classes don't seem to be much different then those of Ext JS or other API references.
I can't tell how helpful Google's documentation is though, since as mentioned above I haven't worked with Google Closure yet.
Ext JS's documentation has been doing a good job for me since I started using Ext JS.
Library's Age & Developer community
I don't know how long Google Closure has been existing within Google, but it just has come to see the light of the outer-Google world.
Ext JS has been out since 2007 and already built up an impressive big developer community which supposedly consists of over 500,000 developers (See statistics and history in this presentation).
You never can underestimate Google in terms of reach and brand power, but looking at Apple's iPhone vs. Google Android, a new library from Google doesn't necessarily mean that all developers will jump on it right away or ever.
Compressor aka Minifier
There's a thread in the Ext JS forum where the difference in results between the Google Closure Compiler and the YUICompressor used by Ext JS are discussed.
After first tests, the well-known forum user "Condor" points out, that the output of compressing the ext-all-debug.js file with the compiler was 20 KB smaller than the output with the YUICompressor. Not sure what the YUICompressor output's file size is and if he actually tried to point out that is it much less or not. For me it sounds as that there's no big difference. Though he mentions that more optimizations may be reached when compiling the library files together with your application code files.
Ext GWT vs. Ext JS vs. Google Web Toolkit vs. Google Closure
I'm a little confused that Google now advertises Google Closure as the base library for all their AJAX applications like Gmail, since they stated before, that it's Google Web Toolkit, see Google Web Toolkit's description "Java software development framework that makes writing AJAX applications like Google Maps and Gmail easy for developers ...".
I wonder if Google Web Toolkit is to Google Closure what Ext GWT is to Ext JS, where GWT allows writing an application in one language (Java) using the JS library features.
Ext JS is released under a dual license, which let's you use it in a GPL-based open-source application for free or in a closed commercial application for $329 per developer or less with volume discount.
Google Closure is freely available under the Apache License. jQuery creator John Resig apparently would have preferred the MIT license, since he just tweeted "I wish that Google Closure (the lib) was under the MIT license, can't really borrow code from it for jQuery, otherwise."
There are developers that avoid Ext JS because of the costs and license, others may choose Ext JS especially because of it and its commercial support.
The preference and choice is up to the developers and companies.
If you aren't a license expert yet, check out this comparison between the different type of licenses.
The reason I checked out Ext JS at the first place was that I looked for a Microsoft Excel-like grid functionality for one of my client's application.
I was instantly hooked by the Ext JS grid.
Unfortunately, Google Closure doesn't seem to have such a widget. The only feature for manipulating data in tables that I could find was the goog.ui.TableSorter class. I guess this speaks for itself. People who need powerful grid functionality such as sorting, column reordering, column resizing, data and pagination handling or fixed headers won't find that in Google Closure right now. You certainly can develop it on your own if you want to, or maybe one day there will exist a Grid widget plugin based on Google Closure.
As with all examples, Ext JS provides for this widget better examples in terms of quantity, complexity and design. See all Ext JS tree examples here.
Going into the details of each tree implementation would go too far for this blog post. I only wanted to point out that there's a tree widget in Google Closure.
Examples a.k.a. demos
One thing I always liked about Ext JS are the extensive and impressive examples that they provide. See for yourself here. You pretty much can build your own Ext JS application by just searching for the functionality you need within the examples and take the code from there.
Google Closure also provides a bunch of examples here (click on the "Demo" tab on the right).
It may be due to the libraries young age or due to it current capabilities, but the examples are by far not as complete and complex as Ext JS's examples.
Usage examples a.k.a. references
Certainly, you can't beat the usage references of Google's Closure library, which is supposedly used in Gmail, Google Docs and Google Maps.
There aren't many well-known public websites that use Ext JS. Number one reason probably is that Ext JS is more used for internal applications. Ext JS definitely has an impressive client list though which you can see here.
The three best and public accessible Ext JS implementations I know of are Marketo, Zipwhip and Kohive. These applications give you a good sense of what's possible with Ext JS.
Disclaimer: Kohive is a client of mine, but that's not why I call it one of the best implementations. Take a look at it yourself. Moreover I didn't create the cool design, interface and architecture.
Ext JS's default design and template is certainly more shiny than that of Google Closure.
One problem I see with Ext JS's default design frequently is that designers and Mac users are turned off by Ext JS's Microsoft Windows-like design. As you see in the implementation examples above, it certainly can be customized to your preferences. Ext JS's 3.0 introduced some changes such as a separate structural and a visual CSS file that helps you with that.
The fact that Google Closure has a namespace or package called testing sounds promising and shows that Google is taking unit testing more seriously than Ext JS.
It's certainly debatable what importance unit testing plays in an UI library, but I believe that there are definitely methods in the libraries that could and should be tested by unit tests, so this part goes to Google Closure.
Not sure how well-tested the Google Closure library is for real though.
I think there's no doubt that we can call Google Closure a competitor of Ext JS as Ext JS is a competitor of Google Closure. This doesn't mean that anybody has to worry here.
Ext JS is already an established company with an established product and community and a super smart team. Google also doesn't need to worry since it doesn't live from it.
Ext JS has already shown that it can live very well side-by-side with other similar and free libraries such as the YUI library.
A lot depends on how both companies keep developing, maintaining and supporting their products in the future and how Google Closure is adapted by developers.
But Google already has shown that it isn't a "killer" for everything, as some people may assume, see Google Base, Google Notebook and Google Android.