Closure 23

5 Nov 2009   | Uncategorized

Tags: ·

Today we finally announced and released Closure (or Closure Library as the JS library is officially known as).

History

Me and Dan Pupius started the JS library at Google a long time ago. At the time there was a lot of good JS code at Google but there was really no order to it and the code was spread out all over the code base. This of course made it hard to discover which in turn lead to the same code being reimplemented over and over. As you might guess the code that existed was not very consistent and sometimes did not even work in the presence of other code. Closure was an attempt to bring a closure to this mess. The name is also a play on the programming language feature as well as the desire to make our js library be a closure of all the existing js code at Google.

At the time we were considering using Dojo as our base for this new library. We were very impressed with Dojo but back then Dojo was too unstable and we had heard too many horror stories of upgrade migration head aches. We also looked at MochiKit which was more stable but it did not really solve any of our problems. (*)

Today

We have had more than 400 Google engineer contributing code to Closure. The code is constantly evolving but I feel like it has stabilized a lot over the last year or so. It is used by almost all of Google’s web applications and the amount of QA and usage these apps have is unheard of for any web application.

I’m very happy that Nathan and Daniel took upon themselves to release this because neither me nor Dan has had the bandwidth to do it.

Future

I hope we can see more code being shared among the different open source JS libraries out there. We would love to be able to goog.require some Dojo code (especially their data model code) and I’m sure they would love to be able to dojo.require our data structures and i18n code.

Closure Compiler

Closure relies heavily on the Closure Compiler to concatenate files, doing static type analysis, as well as code optimizations such as inlining and dead code removal. Closure Library is great for prototyping but it gets slow real fast due to all the network request that are done at startup as well as downloading all the code that you do not really need. The compiler solves both these problems.

Third Party Code

We ended up using both Dojo (we use Acme for goog.dom.query) and we use MochiKit’s Deferred in goog.async.Deferred.

  • http://thejit.org Nicolas

    Thanks for releasing and working on this code :)

    Actually, I have a (design?) question:

    I feel like the inheritance pattern used in Closure is a little bit, well, not so developer friendly:

    You need to explicitly “call” the constructor for the Super class with SuperClass.call(this, etc) instead of using some special property like this.__super();

    Also, you have to do that “extra” step to augment the current class with the Superclass’ methods with the inherits function.

    Is there a (perhaps performance) reason why you chose to do this instead of using something like the MooTools Class class?

  • http://thinkweb2.com/projects/prototype/ kangax

    Very nice, Erik!

    Now if only Closure didn’t rely on browser sniffing so often ;)

  • http://pupius.co.uk Dan Pupius

    kangax: object detection has it’s own issues. It means you can’t compile out browser specific code. In some cases, for example getting rid of IE code, this can reduce the JS size by 5% or more.

  • Alex Russell

    Congrats! Closure is impressive, all the moreso for the tight compiler integration.

  • http://lazutkin.com Eugene Lazutkin

    Great stuff! Looking forward to cooperation between Dojo and Closure.

  • http://www.aaronboodman.com/ Aaron

    Nicolas: one reason not to have something like this.__super() is that it requires an extra property be stored to point back to the parent on every object instance.

  • Pingback: Ajaxian » Google releases Closure, the tools behind the JS geniuses()

  • Fredrik

    Really like your move! when inspecting google code in the past it was obvious you had developed a compiler/linker tool. I hope to have time to try it out in the not too distant future.

    Regarding MochiKit, don’t forget the Dom-helper. I added a note about it here also:
    http://groups.google.com/group/mochikit/browse_thread/thread/532e95132a4eeb29#

    Lycka till I fortsättningen!

  • http://thinkweb2.com/projects/prototype/ kangax

    @Dan I was surprised to see a lot of unneeded sniffs for webkit in dom.js, for example. Do you ever compile out that code too? I’m also curious how this browser-specific separation happens: is browser type determined based on userAgent, before sending files to a client?

  • Pingback: Māris Fogels (mars) 's status on Saturday, 07-Nov-09 21:51:32 UTC - Identi.ca()

  • http://erik.eae.net Erik Arvidsson

    Nicolas: __super cannot be implemented efficiently. MooTools and others inspect all methods and check their source for __super and then wraps the current function in another function that sets this.__super, calls the original function and then restores super.

    Aaron: I wish it was that simple. Just putting a __super on every instance will break when you have more than one layer of inheritance.

    Kangax: Like Dan said, object detection does not allow us to compile out non needed code. This is very important for our iPhone apps. We used to support Safari 3 and 2 and it’s DOM support was just really bad. We have removed most of that code but I wold not be surprised if we can remove more WEBKIT checks. We discussed trying to compile out the object detection code by keeping a huge mapping between user agents and their support.

    Fredrik: DomHelper was inspired by MochiKit. Deferred was a straight port. goog.iter was inspired by Python and I did look at the MochiKit API (but not its code) to make sure we got the most important helper functions.

  • http://blog.louisgray.com Louis Gray

    Erik, thanks for your code, your writeups and sharing with the community. I had a great conversation with Mihai Parparita, and shared his observations on Closure in a post today. I was of course more than happy to link to this post.

    The Story of Google’s Closure: Advanced JavaScript Tools
    http://blog.louisgray.com/2009/11/story-and-impact-of-closure-googles.html

  • http://billhiggins.us/ Bill Higgins

    > At the time we were considering using Dojo as our base for this new library. We were very impressed with Dojo but back then Dojo was too unstable and we had heard too many horror stories of upgrade migration head aches.

    When was “back then”?

  • http://erik.eae.net Erik Arvidsson

    Bill: I believe Dojo was at 0.1 or 0.2 at the time.

  • Pingback: Closure Compiler – Google Code | Amasijo()

  • http://www.cinsoft.net/mylib.html David Mark

    Are we looking at the same script(s)? It’s an outdated pipe dream. Full of browser sniffing, as well as other poor inferences, inefficiencies and bad practices. Doesn’t matter if the “compiler” is designed for browser-specific filtering and it is tied to the client side sniffing. That was a mistake too. Not surprising at all that neophytes in 2005-6 would produce something like this. ;)

    Anyone who thinks this is a good thing is sadly mistaken. It actually manages to make jQuery look good. So look again. :)

  • Pingback: Getting Closure: Don’t just use it, don’t just abuse it on Dion Almaer's Blog()

  • Pingback: Google Closure: 糟糕的JavaScript – JS More()

  • Pingback: Google Closure: 糟糕的JavaScript – ALuan()

  • http://www.crowdersoftware.com T.J. Crowder

    @Erik:

    Re inheritance: Not trying to pimp anything here, but there are reasonably efficient ways to set up inheritance without running into decompilation or strict mode issues and without creating functions on-the-fly at call-time. I describe one in this blog entry: http://blog.niftysnippets.org/2009/09/simple-efficient-supercalls-in.html
    Something along those lines, which works uncompiled and so meets that need, could then be taken a step further with compiler support replacing/optimizing some of the runtime plumbing…

    – T.J. :-)

  • http://yelirekim.com Mike Riley

    I usually don’t take time to post snarky comments like this, especially on subjects that I’m not quite qualified to weigh in on, but here it goes:

    How in the name of god do any of you expect to provide meaningful feedback as to closure’s shortcomings in a blog comment? It’s unfathomable that between ~400 google engineers, over a period of several years, they wouldn’t have at some point at least considered or attempted to flesh out every issue to the point that it couldn’t be resolved in a short (chest beating) comment flame ;)

    Great work on this Google team :)

  • Pingback: Google releases Closure, the tools behind the JS geniuses - Wasif Hafeez()

  • Pingback: Closure « DesignerLinks()