Introducing Closure Tools
googlecode.blogspot.com
googlecode.blogspot.com
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 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)
If someone wants to contribute a jQuery version compiled with advanced opts, I'll be happy to add it to the list.
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.
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.
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.
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}).
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.
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.
"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:
How about "Armadillo"?
I called it "Arnold" because it was strong and squeezed javascript into a smaller shape.
GClosure, JSClosure, ClosureG, or ClosureJS
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 ;-)
http://www.clozure.com/clozurecl.html
Any other consonants that can be shoe-horned into that slot?
The overlap of people interested in Clojure and people interested in Closure is rather small.
This entire thread is evidence against that point.
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.
So depressing.
-- Marvin
Personally, I love picking names that recast old words in a new way, and think Closure is a great name for this project.
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...
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 already use lint in my build system, this looks like a good companion as well.
Don't remember many specifics, I just remember liking it. Good luck!
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)I was already getting the first two mixed up.
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.)
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...
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).
f x = (\y -> x + y)
It's completely different from a 'closure' in a language that has variables.
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]
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.
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.