Thursday, November 05, 2009

Introducing Closure Tools

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!

75 comments:

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

    ReplyDelete
  2. Thanks for making these tools available to the world.

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

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

    ReplyDelete
  5. 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).

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

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

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

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

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

    ReplyDelete
  10. +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?

    ReplyDelete
  11. 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 :)

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

    ReplyDelete
  13. 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!

    ReplyDelete
  14. 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?

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

    ReplyDelete
  16. 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?

    ReplyDelete
  17. very cool! thanks for this announcement!

    ReplyDelete
  18. offering a Firefox extension? How about Chrome?

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

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

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

    ReplyDelete
  22. 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.

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

    ReplyDelete
  24. @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.

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

    ReplyDelete
  26. Thanks for a very useful set of tools and services

    ReplyDelete
  27. 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/

    ReplyDelete
  28. 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.

    ReplyDelete
  29. This will definitely be quite useful! :)

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

    ReplyDelete
  31. Really cool. Thanks, really.

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

    ReplyDelete
  33. @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.

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

    ReplyDelete
  35. Thank you so much for releasing this guys!

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

    ReplyDelete
  37. Nice work. Looking forward to checking this out!

    ReplyDelete
  38. 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.

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

    ReplyDelete
  40. cool' good for dev mania :)

    ReplyDelete
  41. 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");

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

    ReplyDelete
  43. 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 ;)

    ReplyDelete
  44. "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.

    ReplyDelete
  45. 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?

    ReplyDelete
  46. 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!

    ReplyDelete
  47. can i use this for blogger template..
    Science Update

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

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

    ReplyDelete
  50. 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.

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

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

    ReplyDelete
  53. 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.*.

    ReplyDelete
  54. 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 ?

    ReplyDelete
  55. 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!

    ReplyDelete
  56. nice! thanks for this announcement!

    ReplyDelete
  57. 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/

    ReplyDelete
  58. 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

    ReplyDelete
  59. 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.

    ReplyDelete
  60. Thank you for google closure.
    I think the source of this Html file is wrong:
    http://code.google.com/closure/library/samples/notepad2_2.html
    you should include notepad2_2.js into the html file's source.

    ReplyDelete
  61. Wow, google should have done this years ago... I love the UI widjets and controls only they are missing a few things like selectable and resizable. I'm sure those will be added in the following versions.

    for people having problems with their scripts after compiling them in advanced mode be sure to look in http://code.google.com/intl/iw/closure/compiler/docs/compilation_levels.html

    And there is the context menu UI widjet missing, but other than that I think it's a great library and will grow into something that is bigger and better.
    It just takes time to get to what JQuery and other libraries have achieved, it took them years, and google is just releasing theirs now to the giant google community.

    I'm going to use some controls in my quest after a complete online OS(Shedokan OS).

    ReplyDelete
  62. Thanks for sharing.
    I'll try now !

    ReplyDelete
  63. Thanks really waiting for this!!, For years.

    ReplyDelete
  64. 404 Not Found -
    Closure Library Docs -- (Seriously. Check the docs.)
    - http://closure-library.googlecode.com/svn/trunk/closure/goog/docs/index.html

    ReplyDelete
  65. So, does the name "Closure" come from the automatic translation of packages/classes/subclasses into the use of javascript closure?

    ReplyDelete
  66. looks awesome.. waiting to get hands on..

    ReplyDelete
  67. Is there ant task available for this tool?

    ReplyDelete