Live data from Hacker News

Google releases Closure, the tools behind the JS geniuses

ajaxian.com

11–20 of 21 posts

Re: Google releases Closure, the tools behind the JS geniuses

#11
post #7

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.

  > 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?

Re: Google releases Closure, the tools behind the JS geniuses

#12
post #7

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.

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.

Re: Google releases Closure, the tools behind the JS geniuses

#13
post #11
post #7

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.

> 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?

http://www.ibm.com/developerworks/web/library/wa-memleak/

Re: Google releases Closure, the tools behind the JS geniuses

#14
post #3
post #2

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?

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.

"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.

Re: Google releases Closure, the tools behind the JS geniuses

#15
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}
        
        {foreach $d in $data}
            {$d}
            {if not isFirst($d) and index($d) % $ncols == 0}
                
            {/if}
        {/foreach}
        
    {/template}

Re: Google releases Closure, the tools behind the JS geniuses

#16
post #11

Earlier quoted context omitted.

> 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?

http://www.ibm.com/developerworks/web/library/wa-memleak/

Firefox 3 no longer has this problem: https://developer.mozilla.org/en/interfacing_with_the_xpcom_...

Reference counting GC is the problem, not closures.

Re: Google releases Closure, the tools behind the JS geniuses

#17
post #14
post #3

Earlier quoted context omitted.

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.

"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.

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.

Re: Google releases Closure, the tools behind the JS geniuses

#18
post #17
post #14

Earlier quoted context omitted.

"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.

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.

Interesting. I stand amended.

Re: Google releases Closure, the tools behind the JS geniuses

#20
post #3
post #2

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?

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.

Wave is built with GWT (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.

Post reply on HN