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).
"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)."
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!
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?
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.
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.
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.
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.
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.
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 ;)
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.
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?
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!
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!
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
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.
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.
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).
Very cool. I'll have to see how it can help with my own apps!
ReplyDeleteThanks for making these tools available to the world.
ReplyDeleteIt must be a nice one instead of Microsoft Ajax library!
ReplyDeleteSounds very cool, look forward to having a play with this and integrating it into an Umbraco project :)
ReplyDeleteSounds 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).
ReplyDeleteWell... I just can say THANKS!!!
ReplyDeleteThis tools are a huge help for the community, thanks for making this available to everyone.
Very cool!
ReplyDeleteThat's awesome guys! Gonna check it out...
ReplyDeleteThe Tree demo is not working
ReplyDeletehttp://closure-library.googlecode.com/svn/trunk/closure/goog/demos/tree/demo.html
Holy NIH on possibly the largest scale ever batman! ;)
ReplyDeleteI'm a fanboy too.
ReplyDelete+1 Rob Russell
ReplyDelete"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?
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 :)
ReplyDeleteLoving how "Dojo-like" the API feels. Good stuff!
ReplyDeleteI was suprised to read that and very excited to test the tool.
ReplyDeleteFinally, 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!
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?
ReplyDeleteObviously 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?
Great news! Now I won't be able to see the source code on the web and learn anymore!
ReplyDeleteAwesome stuff!
ReplyDeleteA 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?
very cool! thanks for this announcement!
ReplyDeleteoffering a Firefox extension? How about Chrome?
ReplyDelete+2 Bob Russell. 'sup with the name? ... very confusing indeed.
ReplyDeleteCongratulations everybody! Closure is a GREAT library and I'm glad to see it get out in the wild.
ReplyDeleteNothing about Chrome - FireFox + Firebug - best dev&test platform now. :)
ReplyDeleteFunny 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.
ReplyDeletegood tool to use.
ReplyDeleteawesome i love all the open source stuff yall are doing blog post to follow on my blog
ReplyDelete@Denis Sokolov :
ReplyDeleteI'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.
I'm exited to get my hands on it. Google did it again.
ReplyDeleteThanks for a very useful set of tools and services
ReplyDeleteHow effective & accurate itz compressor is, if we compare with Yahoo! YUI Compressor [1] which is well tested & always give me good results.
ReplyDeleteAny comparison / results / stats will be appreciated.
Thanks,
Vishnu
[1] http://developer.yahoo.com/yui/compressor/
Thanks!
ReplyDeletei have used page-speed and optimized my website according to that.
ReplyDeletebut I could not use the javascript profiler in that. I could not understand that. may be I need to give that more time.
This will definitely be quite useful! :)
ReplyDeleteThis is really cool; this would be THE standard tool set for any serious Java Script developer.
ReplyDeleteReally cool. Thanks, really.
ReplyDeleteAmazing stuff! Gonna test those ASAP - and perhaps I will be using them regularly.
ReplyDelete@Shelby Pratt
ReplyDeleteI 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.
Hello there.
ReplyDeleteYahoo released a similar set of tools long time ago. YSlow, YUI, etc.
Thank you so much for releasing this guys!
ReplyDelete@Awef: Others have released similar search engines a long time ago: Yahoo, Excite, Lycos, etc.
ReplyDeletegreat FOSS addition!
ReplyDeleteNice work. Looking forward to checking this out!
ReplyDeleteBig 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.
ReplyDeleteHell yeah!!!!!
ReplyDeleteGod bless open source.
Cool!
ReplyDeletecool' good for dev mania :)
ReplyDeleteThis should raise an compile error, isn't it?
ReplyDeletefunction hello(name) {
return
alert('Hello, ' + name)
}
hello('New user');
Compiled:
function hello(){}hello("New user");
Great work and thank you, I'm excited to check these out.
ReplyDeleteI 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"Take a look at packer and grab some ideas."
ReplyDeletePacker 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.
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?
ReplyDeleteGood good.
ReplyDeleteBut 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!
can i use this for blogger template..
ReplyDeleteScience Update
hmm... this seems to be an another foot of google in the market...
ReplyDeleteLets see how this cool app fits to my needs..
ReplyDeletenice 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.
ReplyDeleteAn alternative view point to the praise that's being heaped here: Google Closure: How Not To Write JavaScript
ReplyDeletePlease add closure compiled libraries of all the libraries on google ajax apis hosting. Save on some bandwidth for everyone.
ReplyDeleteI 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***ATTENTION***
ReplyDeleteMake $$$ to sell Exclusive sneakers without spending a dime. GUARANTEED!!! up to 25% commission
If you use the internet, PLEASE do not overlook this offer :)
Closure compiler was not able to swallow this :
ReplyDeletefunction X(x,y,z) {
return {
a : x , b : y , c : z , total : x + y + z
}
}
var t = X(1,2,3).total ;
Any ideas ?
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!
ReplyDeletenice! thanks for this announcement!
ReplyDeleteGoogle should be able to afford better JavaScript programmers if they are serious about it...
ReplyDeletehttp://www.sitepoint.com/blogs/2009/11/12/google-closure-how-not-to-write-javascript/
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
ReplyDeleteI use jquery and raphael with no problems on the game, but lets see how Closures perform
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.
ReplyDeleteThank you for google closure.
ReplyDeleteI 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.
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.
ReplyDeletefor 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).
Thanks for sharing.
ReplyDeleteI'll try now !
Thanks really waiting for this!!, For years.
ReplyDelete404 Not Found -
ReplyDeleteClosure Library Docs -- (Seriously. Check the docs.)
- http://closure-library.googlecode.com/svn/trunk/closure/goog/docs/index.html
IT SUCKS!!!
ReplyDeleteSo, does the name "Closure" come from the automatic translation of packages/classes/subclasses into the use of javascript closure?
ReplyDeletelooks awesome.. waiting to get hands on..
ReplyDeleteIs there ant task available for this tool?
ReplyDelete