Introducing Closure Tools(googlecode.blogspot.com)
googlecode.blogspot.com
Introducing Closure Tools
http://googlecode.blogspot.com/2009/11/introducing-closure-tools.html
70 comments
Here's another data point:
I downloaded jquery-1.3.2.js and jquery-1.3.2.min.js from http://docs.jquery.com/Downloading_jQuery#Current_Release
> wc -c jquery-1.3.2.js
120763
> wc -c jquery-1.3.2.min.js
57254
> java -jar compiler.jar --js jquery-1.3.2.js | wc -c
55340
Using Google's compiler saves an additional 4% over the existing minified version
(disclosure: I used to work for Google)
I downloaded jquery-1.3.2.js and jquery-1.3.2.min.js from http://docs.jquery.com/Downloading_jQuery#Current_Release
> wc -c jquery-1.3.2.js
120763
> wc -c jquery-1.3.2.min.js
57254
> java -jar compiler.jar --js jquery-1.3.2.js | wc -c
55340
Using Google's compiler saves an additional 4% over the existing minified version
(disclosure: I used to work for Google)
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.
Out of curiousity, I threw together a quick comparison using SlickSpeed and the latest jQuery/Prototype frameworks.
http://bit.ly/1Ei4o8
If someone wants to contribute a jQuery version compiled with advanced opts, I'll be happy to add it to the list.
http://bit.ly/1Ei4o8
If someone wants to contribute a jQuery version compiled with advanced opts, I'll be happy to add it to the list.
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.
Cool to see it out in the wild.
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.
Cool to see it out in the wild.
Yes here's the link http://blog.stackoverflow.com/2009/04/podcast-50/
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.
I mean, of course, besides the obvious things they mention: minification, removing dead code, and some error checking.
Take a look here: http://code.google.com/closure/compiler/docs/api-tutorial3.h...
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.
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.
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.
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.
If the Closure "compiler" changes the behavior of a program, that means it's generating incorrect code. Can you give an example?
Check out http://code.google.com/closure/compiler/docs/api-tutorial3.h...
(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}).
(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").
What an unfortunate name. Perhaps, in the confusion, it will help to actually promote Rich Hickey's wonderful work.
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.
So depressing.
So depressing.
Depressing? Don't talk to me about depressing. I'll be over in the corner rusting for the next nine million years.
-- Marvin
-- Marvin
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.
It was called Closure before Rich announced Clojure to the world.
"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.
I think I probably would have gone with Jambda.
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.
I think I probably would have gone with Jambda.
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:
http://java.ociweb.com/mark/clojure/article.html
"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:
http://java.ociweb.com/mark/clojure/article.html
"what else are you gonna call it?"
How about "Armadillo"?
How about "Armadillo"?
Years ago, i wrote a compressor for javascript.
I called it "Arnold" because it was strong and squeezed javascript into a smaller shape.
I called it "Arnold" because it was strong and squeezed javascript into a smaller shape.
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.
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.
What about http://www.clozure.com/clozurecl.html? I believe it was Clozure before Clojure was released (but I could be wrong).
How about the Closure web browser which predates both Clozure and Clojure?
http://www.cliki.net/Closure
http://www.cliki.net/Closure
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:
GClosure, JSClosure, ClosureG, or ClosureJS
GClosure, JSClosure, ClosureG, or ClosureJS
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?
Picking a name for a software project is one of the few areas where a developer gets to kick loose and be completely creative, and even fanciful.
Personally, I love picking names that recast old words in a new way, and think Closure is a great name for this project.
Personally, I love picking names that recast old words in a new way, and think Closure is a great name for this project.
"Clozure" is taken as well.
http://www.clozure.com/clozurecl.html
Any other consonants that can be shoe-horned into that slot?
http://www.clozure.com/clozurecl.html
Any other consonants that can be shoe-horned into that slot?
Clo-de-jour?
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...
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...
Despite the closeness in name, aren't they pronounced differently? I've always pronounced "Clojure" with a hard "j," rather than like "closure."
Edit: Turns out soft "j" is order of the day, there's a whole discussion about it: http://groups.google.com/group/clojure/browse_thread/thread/... - so confusion can continue to reign ;-)
Edit: Turns out soft "j" is order of the day, there's a whole discussion about it: http://groups.google.com/group/clojure/browse_thread/thread/... - so confusion can continue to reign ;-)
I think most of the intended audience will not find 'Closure' confusing, because they are unaware of the concept that already has that name.
The overlap of people interested in Clojure and people interested in Closure is rather small.
The overlap of people interested in Clojure and people interested in Closure is rather small.
"I think most of the intended audience will not find 'Closure' confusing, because they are unaware of the concept that already has that name."
Pretty sad to expect that so many people working with JavaScript will not know what a closure is.
Not that you're wrong; I honestly don't know, but would hope things aren't so bad.
Pretty sad to expect that so many people working with JavaScript will not know what a closure is.
Not that you're wrong; I honestly don't know, but would hope things aren't so bad.
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.
We can now use all the google fancy widgets (from gmail, gdocs, etc). Check this: http://closure-library.googlecode.com/svn/trunk/closure/goog...
We can now use all the google fancy widgets (from gmail, gdocs, etc). Check this: http://closure-library.googlecode.com/svn/trunk/closure/goog...
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.
How many lint-like tools use a full AST? pylint yes, but I doubt the original did.
Given your experience with the tool, any tips or best practices?
I already use lint in my build system, this looks like a good companion as well.
I already use lint in my build system, this looks like a good companion as well.
IIRC, the framework is largely based on dojo, so if you're familiar with that you'll have an easier time getting used to it.
Don't remember many specifics, I just remember liking it. Good luck!
Don't remember many specifics, I just remember liking it. Good luck!
Using this code on the code here (except for processing.js):
http://github.com/cburroughs/minification-compare/tree/maste...
Latest full release of yuicompressor vs closure at SIMPLE_OPTIMIZATIONS level:
Latest full release of yuicompressor vs closure at SIMPLE_OPTIMIZATIONS level:
----- TOTALS -----
base: yui-compressor-2.4.2
('abs diff:', '768050', 'gz: ', '184071')
('% change: ', -0.56976157623774126, 'gz: ', -0.51009685330672982)
challenger: closure-compiler
('abs diff:', '814830', 'gz: ', '193817')
('% change: ', -0.60446432545511197, 'gz: ', -0.53710493134361448)So now there is Clozure common lisp, Clojure for the JVM, and now Closure.
I was already getting the first two mixed up.
I was already getting the first two mixed up.
I am never going to be able to refer to an actual closure again and have anyone understand what I'm talking about, am I?
I already find that hard enough - I've found that people tend to conflate first-class functions with closures.
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.)
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".
1. http://www.paulgraham.com/arclessons.html
1. http://www.paulgraham.com/arclessons.html
Python 3 has read-write closures. Check out the nonlocal
declaration.
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.
1. http://docs.python.org/dev/3.0/reference/simple_stmts.html#t...
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.
1. http://docs.python.org/dev/3.0/reference/simple_stmts.html#t...
Interesting. Thanks.
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).
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).
Of course Haskell has closures, there's always a scope to close over:
f x = (\y -> x + y)
f x = (\y -> x + y)
That's still just high-level lexical sugar - the 'scope' is not captured, just rewritten. After desugaring, there is no scope left, even lexically.
It's completely different from a 'closure' in a language that has variables.
It's completely different from a 'closure' in a language that has variables.
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]
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.
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!
Closure existed well before JQuery did.
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.
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.