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}

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.

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

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

Reference counting GC is the problem, not closures.

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.

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

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

just fire up gmail :-)

I think sexy was a bit of sarcasm.

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.

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

EDIT: spelling ..

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.

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.

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.

Can anyone compare this Closure package with GWT ?