blog

Introducing Closure Tools

Thursday, November 05, 2009

Millions of Google users worldwide use JavaScript-intensive applications such as Gmail, Google Docs, and Google Maps. Like developers everywhere, Googlers want great web apps to be easier to create, so we've built many tools to help us develop these (and many other) apps. We're happy to announce the open sourcing of these tools, and proud to make them available to the web development community.

Closure Compiler
Closure Compiler is a JavaScript optimizer that compiles web apps down into compact, high-performance JavaScript code. The compiler removes dead code, then rewrites and minimizes what's left so that it will run fast on browsers' JavaScript engines. The compiler also checks syntax, variable references, and types, and warns about other common JavaScript pitfalls. These checks and optimizations help you write apps that are less buggy and easier to maintain. You can use the compiler with Closure Inspector, a Firebug extension that makes debugging the obfuscated code almost as easy as debugging the human-readable source.

Because JavaScript developers are a diverse bunch, we've set up a number of ways to run the Closure Compiler. We've open-sourced a command-line tool. We've created a web application that accepts your code for compilation through a text box or a RESTful API. We are also offering a Firefox extension that you can use with Page Speed to conveniently see the performance benefits for your web pages.

Closure Library
Closure Library is a broad, well-tested, modular, and cross-browser JavaScript library. Web developers can pull just what they need from a wide set of reusable UI widgets and controls, as well as lower-level utilities for the DOM, server communication, animation, data structures, unit testing, rich-text editing, and much, much more. (Seriously. Check the docs.)

JavaScript lacks a standard class library like the STL or JDK. At Google, Closure Library serves as our "standard JavaScript library" for creating large, complex web applications. It's purposely server-agnostic and intended for use with the Closure Compiler. You can make your project big and complex (with namespacing and type checking), yet small and fast over the wire (with compilation). The Closure Library provides clean utilities for common tasks so that you spend your time writing your app rather than writing utilities and browser abstractions.

Closure Templates
Closure Templates grew out of a desire for web templates that are precompiled to efficient JavaScript.  Closure Templates have a simple syntax that is natural for programmers.  Unlike traditional templating systems, you can think of Closure Templates as small components that you compose to form your user interface, instead of having to create one big template per page.

Closure Templates are implemented for both JavaScript and Java, so you can use the same templates both on the server and client side.


Closure Compiler, Closure Library, Closure Templates, and Closure Inspector all started as 20% projects and hundreds of Googlers have contributed thousands of patches. Today, each Closure Tool has grown to be a key part of the JavaScript infrastructure behind web apps at Google.  That's why we're particularly excited (and humbled) to open source them to encourage and support web development outside Google. We want to hear what you think, but more importantly, we want to see what you make. So have at it and have fun!

66 comments:

David Kavanagh said...

Very cool. I'll have to see how it can help with my own apps!

mjr said...

Thanks for making these tools available to the world.

volnet said...

It must be a nice one instead of Microsoft Ajax library!

Chris said...

Sounds very cool, look forward to having a play with this and integrating it into an Umbraco project :)

Rob Russell said...

Sounds cool, but please stop taking over commonly used jargon (chrome used to be a term for talking about a part of a browser window and now closure is going to have the same kinds of ambiguity).

Yëco said...

Well... I just can say THANKS!!!

This tools are a huge help for the community, thanks for making this available to everyone.

Markus Kohler said...

Very cool!

Xavier said...

That's awesome guys! Gonna check it out...

Les said...

The Tree demo is not working
http://closure-library.googlecode.com/svn/trunk/closure/goog/demos/tree/demo.html

djfroofy said...

Holy NIH on possibly the largest scale ever batman! ;)

Alexander Fairley said...

I'm a fanboy too.

Ben Anderson said...

+1 Rob Russell

"Sounds cool, but please stop taking over commonly used jargon (chrome used to be a term for talking about a part of a browser window and now closure is going to have the same kinds of ambiguity)."

What's up with the naming?

bcherry said...

All over this. Been looking for a good RTE besides YUI, now I've got an excuse to plug one in and dive into Closure :)

cs44 said...

Loving how "Dojo-like" the API feels. Good stuff!

Denis Sokolov said...

I was suprised to read that and very excited to test the tool.

Finally, I thought, somebody has wrote a very good JS minifier, since it is from Google.

I run to the tool, run some tests and the results are not... very promising. Even at advanced level of compression, it runs quite behind Dead Edwards's packer.
(http://dean.edwards.name/packer/)

Take a look at packer and grab some ideas.
:)
Good luck!

a said...

Is the Google JS lib meant to be a replacement for a library like jQuery, or will the two function in harmony? Are there any plans for a translator or translators?

Obviously the compiler is most effective with Google's library. Is the compiler also effective in optimizing code written for existing libraries like jQuery, prototypejs, scriptaculous, mootools, etc?

Sunny said...

Great news! Now I won't be able to see the source code on the web and learn anymore!

khurram said...

Awesome stuff!

A few questions regarding GWT vs. Closure -

1. How does Closure compare to the optimized javascript that is generated by GWT (Google Web Toolkit)?

2. Does GWT use some form of the Closure Compiler under covers?

3. Does it makes sense for GWT developers to look at Closure?

4. Is there any integration planned to make it easy for GWT developers to use Closure widgets and other UI libraries?

Nam Nguyen said...

very cool! thanks for this announcement!

kingless said...

offering a Firefox extension? How about Chrome?

BenKeen said...

+2 Bob Russell. 'sup with the name? ... very confusing indeed.

Gavin said...

Congratulations everybody! Closure is a GREAT library and I'm glad to see it get out in the wild.

live2hack.info said...

Nothing about Chrome - FireFox + Firebug - best dev&test platform now. :)

Matthias said...

Funny to see a UI library from Google. While your products and sites are known to be functional and compatible, they are also famous for being among the ugliest from a design and UI perspective.

edsley said...

good tool to use.

Carter said...

awesome i love all the open source stuff yall are doing blog post to follow on my blog

Shelby Pratt said...

@Denis Sokolov :

I'm sure they're quite aware of Packer.

While packer is useful for obsfuscation, you do not gain much by the compression. The way it works, using eval and string substitution, exchanges computation time for file size. This gives poor performance where it counts, on netbooks, IE6 or phones.

Packer is only useful for compression when saving bandwidth is more critical than reducing execution time, i.e. not often.

റെമിസ് രഹനാസ് | Remiz Rahnas said...

I'm exited to get my hands on it. Google did it again.

Cedric Middlebourne said...

Thanks for a very useful set of tools and services

Vishnu Kumar Agarwal said...

How effective & accurate itz compressor is, if we compare with Yahoo! YUI Compressor [1] which is well tested & always give me good results.

Any comparison / results / stats will be appreciated.

Thanks,
Vishnu

[1] http://developer.yahoo.com/yui/compressor/

Emerson4br said...

Thanks!

satyakaran said...

i have used page-speed and optimized my website according to that.
but I could not use the javascript profiler in that. I could not understand that. may be I need to give that more time.

Carlos Martins said...

This will definitely be quite useful! :)

V Srini said...

This is really cool; this would be THE standard tool set for any serious Java Script developer.

Kir Maximov said...

Really cool. Thanks, really.

Emanuele Ciriachi said...

Amazing stuff! Gonna test those ASAP - and perhaps I will be using them regularly.

Denis Sokolov said...

@Shelby Pratt

I am sure they are aware of it as well. :)

Packer is hardly useful for obsfucation, simply because obsfucation is hardly useful for anything at all. :)

"Packer is only useful for compression when saving bandwidth is more critical than reducing execution time, i.e. not often."
This statement, while is thoughtful, is hardly substantiated. I am pretty sure, that you, as well as I, have not calculated the exact loss of execution time versus download time the packer provides.
Obviously, the results may be that the execution time loss is huge. In that case, surely packer is the wrong choice. However, it might be that the time needed to unpack the script is very very short. In that case, 0.5seconds, saved by the size compression really matters and mean, that we choose packer.

Now, shall we perform real tests on packer'ed code, what do you think? :)
I'm thinking about writing a test in JS itself, with measuring time to eval('') the packed code vs. google-compiled code.
However, I am afraid that eval() is not very scientific.

Awef said...

Hello there.
Yahoo released a similar set of tools long time ago. YSlow, YUI, etc.

bbeausej said...

Thank you so much for releasing this guys!

Sean O said...

@Awef: Others have released similar search engines a long time ago: Yahoo, Excite, Lycos, etc.

Andrea Matesi said...

great FOSS addition!

andy said...

Nice work. Looking forward to checking this out!

Gallomimia said...

Big time kudos to google for putting out code for the developers of the world. It's acts like this that make the world of computing and internet a better place.

Bruno Souza said...

Hell yeah!!!!!
God bless open source.

Pakorn T. said...

Cool!

FX said...

cool' good for dev mania :)

Luca Greco a.k.a. "rpl" said...

This should raise an compile error, isn't it?

function hello(name) {
return
alert('Hello, ' + name)
}
hello('New user');

Compiled:

function hello(){}hello("New user");

HEMANTH G said...

Great work and thank you, I'm excited to check these out.

David Buzatto said...

I loved Closure Compiler. I think that is just one thing missing - The option do compress CSS files. I´m using in my project and I'm getting 62,5% of compression in my JS files. It's better than YUI compressor ;)

nosredna said...

"Take a look at packer and grab some ideas."

Packer was great for its time, but most have abandoned it for good reason, as it must unpack. That's why minification is now preferred. That's why, for example, jQuery switched from a packed version to a minified version.

nosredna said...

I am having great luck, except I have a couple scripts which do not work after being compiled on "advanced." These scripts are cool with JSLint and no warnings are given to me by the compiler. Anyone else having similar problems?

Manu said...

Good good.

But is there a way to compress the entire web-page (HTML+CSS+Javascript)? Many pages on the internet use client-code which are nearly 20-30% extra-sized. You can see unnecessary HTML tags, setting style attributes (CSS) which are default and Javascript which is not so efficient.

There are tools to compress HTML and now you've a tool to optimize Javascript. But we need something more - something which looks the webpage in a holistic approach and optimizes it.
If there is a 20% project on those lines, please fund it and build it!

cute said...

can i use this for blogger template..
Science Update

sunny said...

hmm... this seems to be an another foot of google in the market...

Suresh Babu said...

Lets see how this cool app fits to my needs..

Satish said...

nice stuff. but in a very big API, it may be a problem of code readability.. Apart from that, it is a nice way of doing things writing less code.

Matthew said...

An alternative view point to the praise that's being heaped here: Google Closure: How Not To Write JavaScript

drawk said...

Please add closure compiled libraries of all the libraries on google ajax apis hosting. Save on some bandwidth for everyone.

Matteo Caprari said...

I had a look at the networking function of closure-library and found it's quite good. I posted my findings at Learning Closure. Ajax with goog.net.*.

Jordan23Shoes said...

***ATTENTION***

Make $$$ to sell Exclusive sneakers without spending a dime. GUARANTEED!!! up to 25% commission

If you use the internet, PLEASE do not overlook this offer :)

DBJ said...

Closure compiler was not able to swallow this :

function X(x,y,z) {
return {
a : x , b : y , c : z , total : x + y + z
}
}
var t = X(1,2,3).total ;

Any ideas ?

budu said...

Is there any plan to make a Google Group or Wiki for Closure Tools. Started experimenting with it, it's awesome, but I have lots of questions. Specifically, what is the best way to organize/get images and stylesheets for ui widget? For now I'm retrieving them directly from the demos, there's surely a better way!

Nabil said...

nice! thanks for this announcement!

Yuri said...

Google should be able to afford better JavaScript programmers if they are serious about it...

http://www.sitepoint.com/blogs/2009/11/12/google-closure-how-not-to-write-javascript/

Jeeba said...

Well it appears that Dmitry Baranovskiy disagree the way Closures is made, but this is the first version of it, i would think of this like a beta. Certainly this library will not work with unsafe code like undefined = 0 in the global , but Dmitry give those dudes in Google some javascript lessons. Anyway i will test this library in my hobbyist web game http://xeno.iasoftgroup.com

I use jquery and raphael with no problems on the game, but lets see how Closures perform

oscar said...

I love jQuery, every time I test it against newest jQuery wins. I'm dowloading Closure now and I promise to test it, the only winner here must be the user.

Post a Comment