

Google releases Closure, the tools behind the JS geniuses - nathanwdavis
http://ajaxian.com/archives/google-releases-closure-the-tools-behind-the-js-geniuses

======
asher
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}

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

      > 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
<http://www.ibm.com/developerworks/web/library/wa-memleak/>

~~~
andreyf
Firefox 3 no longer has this problem:
[https://developer.mozilla.org/en/interfacing_with_the_xpcom_...](https://developer.mozilla.org/en/interfacing_with_the_xpcom_cycle_collector)

Reference counting GC is the problem, not closures.

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

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

~~~
jmtame
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
just fire up gmail :-)

I think _sexy_ was a bit of sarcasm.

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

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

~~~
enneff
"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
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
Interesting. I stand amended.

------
mindaugas
Can anyone compare this Closure package with GWT ?

