6 ms·

Google releases Closure, the tools behind the JS geniuses

43 points by nathanwdavis 17y ago

jmtame 17y ago
how is this different from the likes of jquery? edit: it seems the library is similar in terms of dom manipulation, but the compiler and templating system seem to be the major differences?
- nym 17y ago
  The Closure Compiler is the big news. As the article says, it turns your regular JavaScript code into compact, high-performance JavaScript code. This is some of the magic behind Google Maps, Gmail, and I assume Wave. This is a very big deal for JavaScript developers because it is like having JSLint, YUI Compressor, and Chuck Norris rolled into one.
  - ironsam 17y ago
    Sort of, except it has its problems: http://webreflection.blogspot.com/2009/11/google-closure-im-not-impressed.html http://webreflection.blogspot.com/2009/11/google-closure-im-...
  - enneff 17y ago
    "it turns your regular JavaScript code into compact, high-performance JavaScript code." It won't actually make your JavaScript much faster, if it does at all. The major benefits are the exclusion of unused code, and code in-lining where possible. This helps a lot in terms of cutting down loading times, but your code is still only really going to be about as efficient as it was before.
    - swolchok 17y ago
      Not true if you use objects as namespaces -- it is capable of reducing a.b.c.d to one access, particularly with inlining, and this construct has a runtime cost in JS.
      - enneff 17y ago
        Interesting. I stand amended.
  - jollojou 17y ago
    Wave is built with GWT (http://www.techworld.com.au/article/305043/aussie_devs_make_wave_google_web_toolkit http://www.techworld.com.au/article/305043/aussie_devs_make_...), which has its own JavaScript compiler. But do GWT and Closure use the same technology, that I don't know.
dustingetz 17y ago
it looks like they're giving away their incredibly sexy ui components.
- jmtame 17y ago
  i wish they'd post screenshots of this stuff so i didn't have to download it just to see what the various ui elements looked like..
  - catch23 17y ago
    just fire up gmail :-) I think sexy was a bit of sarcasm.
  - bokchoi 17y ago
    From the api docs there is a 'demo' link on some pages. It looks like not all of the widgets have demo pages. I wish more api docs did this.
vl 17y ago
It would be interesting to see what gives developer better productivity in the long run: Closure or GWT? I'm big fan of GWT myself, and one of the reasons is that it allows me to build bigger projects: my JS projects always reached maintainability problems sooner than GWT projects.
psranga 17y ago
Does it provide any support for avoiding/detecting Javascript "memory leaks" which are easy to create with closures and anonymous functions? That's what interests me the most. The stuff they have here for annotating types (love the type expressions), equivalent of #define are major conveniences to ease development. And long overdue. So thanks, Google.
- joeyo 17y ago
  > Does it provide any support for avoiding/detecting > Javascript "memory leaks" which are easy to create with > closures and anonymous functions? I don't understand this. Do closures leak because of buggy javascript implementations or is there something about them that fundamentally prevents the interpreter from being able to tell when to garbage collect them?
  - richcollins 17y ago
    http://www.ibm.com/developerworks/web/library/wa-memleak/ http://www.ibm.com/developerworks/web/library/wa-memleak/
    - andreyf 17y ago
      Firefox 3 no longer has this problem: https://developer.mozilla.org/en/interfacing_with_the_xpcom_cycle_collector https://developer.mozilla.org/en/interfacing_with_the_xpcom_... Reference counting GC is the problem, not closures.
- mpk 17y ago
  Thank you psranga for being the only one in here to make a technical comment. Leak profiling in JS is a pain. I wasn't really expecting Google to provide an answer here because all their apps contribute to wasted heap space too. Google's answer (as far as I can tell) is just to push it back to the browser. In their case, use Chrome, which uses a separate process for each page. Chasing JS leaks has to be one of the most frustrating exercises ever. I ended up using a windows tool for analyzing jscript.dll and cross-referencing this with a custom spidermonkey build (with lots of print statements in the source). Anything less than insight to this problem I'm going to take with a grain of salt.
asher 17y ago
Thoughts so far: The templating system is interesting. It does something I have not seen before: You can define one template, then execute it server-side (in Java only) and/or client-side (compiled into Javascript). To achieve this, the template language is quite restricted. It seems that we could write interpreters for this language in Ruby, Python, etc. Also, we could write a compiler back-end which generates C to run inside nginx or Apache; this could yield a high-performance templating system. Here's an example template I made. Note that the "javadoc" portion is mandatory and is parsed by the compiler. /** * show a table * * @param data array of values * @param ncols num columns */ {template .vvtable} <table cellspacing=10><tr> {foreach $d in $data} <td><div style="background-color:#f00;padding:5px">{$d}</div></td> {if not isFirst($d) and index($d) % $ncols == 0} </tr><tr> {/if} {/foreach} </tr></table> {/template}
mindaugas 17y ago
Can anyone compare this Closure package with GWT ?
charlesmarshall 17y ago
If you want a simple web form for the compiler; i made http://closureoptimizer.com/ http://closureoptimizer.com/ this morning (DNS might still be working itself out) EDIT: spelling ..

43 points by nathanwdavis 17y ago

how is this different from the likes of jquery? edit: it seems the library is similar in terms of dom manipulation, but the compiler and templating system seem to be the major differences?

nym 17y ago
The Closure Compiler is the big news. As the article says, it turns your regular JavaScript code into compact, high-performance JavaScript code. This is some of the magic behind Google Maps, Gmail, and I assume Wave. This is a very big deal for JavaScript developers because it is like having JSLint, YUI Compressor, and Chuck Norris rolled into one.
- ironsam 17y ago
  Sort of, except it has its problems: http://webreflection.blogspot.com/2009/11/google-closure-im-not-impressed.html http://webreflection.blogspot.com/2009/11/google-closure-im-...
- enneff 17y ago
  "it turns your regular JavaScript code into compact, high-performance JavaScript code." It won't actually make your JavaScript much faster, if it does at all. The major benefits are the exclusion of unused code, and code in-lining where possible. This helps a lot in terms of cutting down loading times, but your code is still only really going to be about as efficient as it was before.
  - swolchok 17y ago
    Not true if you use objects as namespaces -- it is capable of reducing a.b.c.d to one access, particularly with inlining, and this construct has a runtime cost in JS.
    - enneff 17y ago
      Interesting. I stand amended.
- jollojou 17y ago
  Wave is built with GWT (http://www.techworld.com.au/article/305043/aussie_devs_make_wave_google_web_toolkit http://www.techworld.com.au/article/305043/aussie_devs_make_...), which has its own JavaScript compiler. But do GWT and Closure use the same technology, that I don't know.

dustingetz 17y ago

it looks like they're giving away their incredibly sexy ui components.

jmtame 17y ago
i wish they'd post screenshots of this stuff so i didn't have to download it just to see what the various ui elements looked like..
- catch23 17y ago
  just fire up gmail :-) I think sexy was a bit of sarcasm.
- bokchoi 17y ago
  From the api docs there is a 'demo' link on some pages. It looks like not all of the widgets have demo pages. I wish more api docs did this.

vl 17y ago

It would be interesting to see what gives developer better productivity in the long run: Closure or GWT? I'm big fan of GWT myself, and one of the reasons is that it allows me to build bigger projects: my JS projects always reached maintainability problems sooner than GWT projects.

psranga 17y ago

Does it provide any support for avoiding/detecting Javascript "memory leaks" which are easy to create with closures and anonymous functions? That's what interests me the most. The stuff they have here for annotating types (love the type expressions), equivalent of #define are major conveniences to ease development. And long overdue. So thanks, Google.

joeyo 17y ago
> Does it provide any support for avoiding/detecting > Javascript "memory leaks" which are easy to create with > closures and anonymous functions? I don't understand this. Do closures leak because of buggy javascript implementations or is there something about them that fundamentally prevents the interpreter from being able to tell when to garbage collect them?
- richcollins 17y ago
  http://www.ibm.com/developerworks/web/library/wa-memleak/ http://www.ibm.com/developerworks/web/library/wa-memleak/
  - andreyf 17y ago
    Firefox 3 no longer has this problem: https://developer.mozilla.org/en/interfacing_with_the_xpcom_cycle_collector https://developer.mozilla.org/en/interfacing_with_the_xpcom_... Reference counting GC is the problem, not closures.
mpk 17y ago
Thank you psranga for being the only one in here to make a technical comment. Leak profiling in JS is a pain. I wasn't really expecting Google to provide an answer here because all their apps contribute to wasted heap space too. Google's answer (as far as I can tell) is just to push it back to the browser. In their case, use Chrome, which uses a separate process for each page. Chasing JS leaks has to be one of the most frustrating exercises ever. I ended up using a windows tool for analyzing jscript.dll and cross-referencing this with a custom spidermonkey build (with lots of print statements in the source). Anything less than insight to this problem I'm going to take with a grain of salt.

asher 17y ago

Thoughts so far: The templating system is interesting. It does something I have not seen before: You can define one template, then execute it server-side (in Java only) and/or client-side (compiled into Javascript). To achieve this, the template language is quite restricted. It seems that we could write interpreters for this language in Ruby, Python, etc. Also, we could write a compiler back-end which generates C to run inside nginx or Apache; this could yield a high-performance templating system. Here's an example template I made. Note that the "javadoc" portion is mandatory and is parsed by the compiler. /** * show a table * * @param data array of values * @param ncols num columns */ {template .vvtable} <table cellspacing=10><tr> {foreach $d in $data} <td><div style="background-color:#f00;padding:5px">{$d}</div></td> {if not isFirst($d) and index($d) % $ncols == 0} </tr><tr> {/if} {/foreach} </tr></table> {/template}

mindaugas 17y ago

Can anyone compare this Closure package with GWT ?

charlesmarshall 17y ago

If you want a simple web form for the compiler; i made http://closureoptimizer.com/ http://closureoptimizer.com/ this morning (DNS might still be working itself out) EDIT: spelling ..