What does Google Closure Library offer over jQuery? [closed]

Considering

business background
community support
available extensions
default set of features
simplicity of use
and reliability

why do you prefer one over the another?

Solution 1:

I'll try to add my piece of information.

More than another JS lib

As I understand it, Google Closure is not only another JS library, but it is also a set of tools that will allow you to optimize your JS code. Working with jQuery gives you good tools and a lightweight library, but it does not minify your own code. The Closure compiler will. The closure inspector may also be useful, as sometimes minified code has a different behavior than the original one, and is a pain to debug. It integrates with Firebug and support unit tests, which are both developers' best friends nowadays.

Documentation

I guess that as any new library VS a well established one, it will lack the availability of tons of extensions and tutorial that jQuery has. However, being pushed by Google should ensure that support and reliability will be both pretty good. The current documentation and tutorial both seem really good, too.

Features

The features of Closure look decent, though, and its modular architecture is promising, too. I guess Google has been using it internally for a long time, which means that you could expect all basic features (and more) to be implemented, and probably in a very optimized and scalable way. They are trying to present it as the STL of JavaScript, so they should have polished it.

After looking at the features more closely, it seems that this may be a step forward for web-applications development compared to existing libraries as jQuery. It guess it benefits internal developments at Google, but things like detecting the online state (see goog.events.OnlineHandler), easy integration of AJAX requests and JS actions in the browser history (see goog.History), or the legions of great widgets they provide (see goog.ui package) may help all of us building even more awesome webapps ;) !

It comes with templates features that integrates with Java (who said GWT ?), so this may also be another plus for Closure.

Ease of use

Finally, it looks pretty simple to use. The syntax may be a bit more verbose than the short $ jQuery function, but with IDEs and auto-completion, it's not a real problem. Moreover, I'd say we can expect a good integration in IDEs like Eclipse, coming from Google.

EDIT: as requested, let me say a few words about the GWT reference. Google Web Toolkit is a Java library that allows to create AJAX-enabled web interfaces and that generates (and optimizes) the required JavaScript code. As Google Closure allows to create Templates that can be used both client- and server-side (using JavaScript and Java), my guess is that it will soon be possible to use them jointly (if it's not already the case).

Solution 2:

In my brief look at the API I find the differences between jQuery and Closure to be striking.

jQuery is basically just a simplified way to do many frequent operations in a cross-browser way.

Closure is a framework that is very new, in that they provide a cross-browser way to use the <canvas> tag, for example, and they have added new events.

So, this is adding onto what we typically do with javascript, they are taking many operations that people want to do and putting them into the API.

For example, they have an event to tell if the online state has changed. So you can tell if the system is online.

They have javascript functions that use tools such as Google Gears, which continues with the fact that they have extended what can be done with Javascript.

It will take me a couple of days to digest all the changes, but I can see that this could have a big impact on web applications that can be developed.

Solution 3:

The biggest advantage of Closure Library is that is is designed for Closure Compiler. This opens completely new possibilities for JavaScript development...

The compiler has several cool features:

It compiles readable JavaScript into compressed machine-readable JavaScript - it has the best compression ratio in "ADVANCED" mode.
Documentation of the code with JSDoc Tags is important: the compiler reads it and you get warnings during compilation for typos in documentation, wrong use of a @constructor, wrong type of a variable, misuse of a field annotated with @private and @protected, etc.
If you write a reusable JavaScript library, such as OpenLayers or Google Maps, you formally export your public API - and the compiler optimizes your internal code.
The end applications can be compiled together with the library - and then the unused parts of the library are removed from the produced code. Dependencies are solved automatically by the compiler.
Compiler accepts constants to remove unwanted functionality - this allows compilation only for particular browser such as Mobile WebKit, for only one of Quirks mode or Strict mode, compilation without support of IE6, etc.
Debugging with FireBug is possible even for the compiled version of the source code.
Compiler supports generation of dynamically loadable modules, which can significantly speed up loading of the end application, because the code for advanced functionality can be loaded only when it is required.

For details have a look at: http://blog.klokantech.com/2010/12/closure-compiler-for-openlayers-3x.html