For one of our JS bundles it's a substantial improvement over YUI's Compressor.
Original: 459220
YUI: 241920
Google: 209929 -- 13% improvement
YUI + gz: 66164
Google + gz: 61297 -- 7% improvement
Caught a few non-fatal syntax errors too. We serve hundreds of thousands of those a day, so that's already committed to our tree and on the way to testing.
I definitely plan on switching jQuery over to using this compressor - excited by the output. However it appears as if it crashes when you push the latest nightlies of jQuery in. Not sure what's up with that.
I'm pretty sure this is what Steve Yegge was talking about on the most recent StackOverflow podcast he was in.
If that is accurate, it's a JavaScript compiler that supports a way of partially compiling to allow very tight integration with an IDE (or editor). Yegge's point was that an IDE or editor should not have to re-invent the wheel and a compiler should be able to provide sophisticated feedback about syntax, objects, variables, scope, etc.
Would anyone who already knows this tool, or is taking the time to learn it, care to explain what they mean by "compiles web apps down into compact, high-performance JavaScript"? I assume this is a JS-to-JS translator. How exactly are they transforming the JS?
I mean, of course, besides the obvious things they mention: minification, removing dead code, and some error checking.
When you turn on advanced mode they do automatic inlining, variable substitution, and they don't respect the globalness of anything unless you specifically force something to be global.
YUI Compressor assumes anything not in a function is global, so it won't rename top level objects. Closure in advanced mode will trample through your globals and property names like rhinos mating in a field of daises.
I get concerned that these minimisers and js to js compilers will introduce subtle bugs and changes into the behaviour of my code. Is that concern warranted?
Closure advanced mode will absolutely screw with your code.
Closure simple mode and YUI Compressor won't change the behavior of your code. They just rename completely encapsulated objects with shorter names and remove unnecessary semicolons.
This is one of the things I've been wondering about. I'd like to look at ways to get Closure to be more holistic in it's approach.
YUI Compressor has always been safe. I think the concern I have is that the new, exciting features here are the unsafe ones and, obviously, those are the ones that are dangerous.
I'd be really interested in seeing how we can make features like this safe again. For example, by scraping a page, rather than just a JavaScript file to see which methods are genuinely unused instead of those unused in an undefined context of an unlinked JS file.
(short version: inconsistencies between Closure renaming my_object.attribute to a minified a.a while in other places you use my_object['attribute'] which it can't minify to be a.a. You end up with a.a = 3 and a['attribute'] = {something else}).
Ah. This is a classic problem with transforming JS. We've run into something similar with Parenscript (but were able to correct it, rather than say "just don't write code that does X").
This is indeed an unfortunate name. The word 'closure' was, at first, used to describe a concept in programming: http://en.wikipedia.org/wiki/Closure_(computer_science).
Then Clozure and Clojure came along. Now, I can see how these two are related to the aforementioned concept, but I simply can't see what these 'Closure tools' have to do with the concept of closures. Yet the name would suggest that they do. Is there anybody from Google that would care to explain?
It's not quite as bad as PrototypeJS -- the most ironically named library ever. The whole point of it is to force Class-based bullshit onto the only pure Prototype-based language anyone uses. It's named after the concept it's designed explicitly to stamp out.
Note that the word closure has meaning in set theory and other areas of mathematics relevant to computer science. SICP explicitly avoids using what wikipedia calls a 'computer science closure' for this reason.
"Closure" being a general concept in programming, I always disliked the name "Clojure". Same thing as Google Chrome, everyone is now confused when you talk about browser chrome as a general thing.
I agree that "Clojure" is kinda a silly name, but what else are you gonna call it? I assume Henly wanted a name that conveyed its functional and/or Lisp roots, and the fact that it's on the JVM.
Let's try some names using the usual JVM language conventions:
JLisp works, but it's boring, and Jisp sounds kinda suspect. Parenjases is just silly. Or maybe LLBeans for "lazy lisp beans"...but that's just getting too cute.
In case people are wondering, here is how the Clojure name came about:
"Clojure is pronounced the same as the word "closure". The creator of the language, Rich Hickey, explains the name this way: "I wanted to involve C (C#), L (Lisp) and J (Java). Once I came up with Clojure, given the pun on closure, the available domains and vast emptiness of the googlespace, it was an easy decision.""
At least this is how it is outlined in this document:
Naming is a pretty powerful thing. If you name your crap with regular nouns, what's left for others there?
Like, suppose you build a crappy GUI system and just dub everything based on simple self-describing words such as windows, word, notepad, internet explorer, you might end up wildly successful yet for reasons other than technical superiority.
Thats a terrible argument... He did indeed "announce Clojure to the world" before Google did, and now we all associate the phonetic name with him. Treat "closure" as a project name and pick a different product name, Google.
Even without the near-collision with 'Clojure', the full-collision with the 'closure' concept is problematic. They should prepend or append a 'G' or 'JS' for clarity (to both humans and indexers). EG:
I'm getting disillusioned with software naming. Everyone wants a cool name that's fun to say, but all the names mean other things too, and quite a few don't describe the project very well.
Why is it called Closure? Does it close stuff? Does it pass functions and bindings? What could possibly have inspired them to use this particular name?
I suspect the confusion will only affect people that don't need the specific implementations...
People that want Closure for their JS goodness will know which it is, similarly for Clojure and Clozure lisps. And I generally search out new tools by description rather than name, so the naming issue becomes more of a marketing issue than anything else, and given the name space, it does seem a relatively hot area at the moment...
At least they didn't go for something like GJST...
It took me a while to figure this out, but there's a lot more than "just" a js compiler. Since nobody here commented about it, I guess I'm not the only one that didn't see it.
I think there is way to much attention on the compiler. It's neat but not that big of a deal.
The key here is that they released their widget library. Tons of great stuff with very high code quality. This also includes the document editor from google docs which is by leaps and bounds the best engineered WYSIWYG editor out there.
Wow, I have been seriously missing this outside google-land. So happy it's released; it's a fantastic set of tools, even if you only use the compiler as a glorified lint.
Well, is there any real different between a first-class function and a closure that closes over nothing?
Is it possible for a language to support closures without first-class functions? How common is it to have first-class functions without closures? (I think Python sort of had this arrangement, but I think this is fixed now.)
A closure is just a (function, bindings) pair, so Python certainly has closures. The problem with Python is that there is no syntax for assigning to variables declared in an arbitrary scope, because there are no explicit declarations. As far as I understand, implicit local variables are what causes the problems in Python, not anything about closures, really. This causes other problems, too, such as those PG described here [1], under the heading "Implicit local variables conflict with macros".
The nonlocal statement causes the listed identifiers to refer to previously bound variables in the nearest enclosing scope. [1]
While certainly a big improvement, we still can't access variables in arbitrary scopes, just local, nearest non-local, and global. To me, this seems a significantly more complex way of specifying variable scope than just declaring it explicitly.
Haskell does not semantically have closures at all, because functions have only their arguments -- no scope to close over.
Lexically, there's where clauses to scope function definitions, but that gets desugared very early, and is really not the same thing at all anyway (the name binding is completely static).
Upvoted for two reasons - Making me laugh out loud, and for letting me know that I am not the only one getting confused.
Other commentators have mentioned the confusion with Rich's Clojure, and despite Rich's stand that is be pronounced like you would pronounce "closure", I usually still say it with the emphasis on the "J", esp. to Lisp-savvy folks.
[On a side note, and I am nitpicking here, but it's just Clojure, vs Clojure for the JVM, considering Clojure for the CLR is very close to 1.0]
I've been curious about some of the tools behind Google's javascript power. The Closure Library coupled with the compiler looks really useful for creating complex and fast web apps.
This is wonderful news; I'm really grateful to Google for opening this.
We already knew that Google's major javascript apps were not using GWT. I always had reservations about GWT because I think javascript is a very nice language. (Just the language - not necessarily the DOM or implementations).
While java seems like a step backwards.
The main thing missing from javascript is some stricter checking, and it looks like Closure Tools provides this.
i DONT get this attitude of Google. even MS uses jquery but the open source king Google do not. is this so hard to improve upon Firefox or Ubuntu or even much less complex jquery?
Google uses (and hosts free for everyone) jQuery. You can even use their new compiler to get a smaller version of jQuery. The widget library has some overlap with jQuery, but does so much more and has been in progress since well before jQuery UI (Google bought Writely in March 2006 and jQuery UI didn't come out until September 2007).
MS uses and hosts free too. what is your point? i'm talking about progressing current successful open source projects. fyi, its library has overlap with jquery core too!
It's non-trivial to switch an existing system over to a new JS library. I tried most recently last month, but there're a bunch of engineering constraints that made it apparent, even to me, that it was a bad idea.
JQuery is still used a lot for prototyping, where we don't face these engineering constraints.
Original: 459220
YUI: 241920
Google: 209929 -- 13% improvement
YUI + gz: 66164
Google + gz: 61297 -- 7% improvement
Caught a few non-fatal syntax errors too. We serve hundreds of thousands of those a day, so that's already committed to our tree and on the way to testing.