jquery poised to gain on GWT's compiler, thanks to, um ... Google

Buried in the jquery 1.4 release announcement, under the Miscellaneous section, is the following tidbit:

Now use Closure Compiler instead of YUI Min (commit)

So what is Closure Compiler? According to the project page at Google Labs,

"The Closure Compiler is a tool for making JavaScript download and run faster. It is a true compiler for JavaScript. Instead of compiling from a source language to machine code, it compiles from JavaScript to better JavaScript. It parses your JavaScript, analyzes it, removes dead code and rewrites and minimizes what's left. It also checks syntax, variable references, and types, and warns about common JavaScript pitfalls."

According to the commit message, switching from YUI Compressor to Google Closure Compiler reduced the filesize by 13% with no other changes.

But wait, there's more!

A 13% bump is not bad, and certainly no one is surprised these days when Google one-ups Yahoo. But it gets better: jquery is so far only using Closure Compiler in Standard Optimizations mode (the default setting). It is not yet using the more aggressive Advanced Optimizations. With advanced optimizations enabled, Closure Compiler also:

1. renames global variables and function names to make them shorter,
2. removes unused functions, and
3. inlines references where possible, including function calls, constants, and variables.

The catch is...

In order to use Advanced Optimizations safely, you need to tell Closure Compiler which symbols are actually calls to external code (externs) and which symbols need to be preserved as public API so that other libraries can reference them (exports). In the case of exports, it still shortens the symbol names everywhere they are used, but it sets up a single alias with the public name.

Setting up externs and exports takes time, effort, and testing, and it's probably the reason why jquery isn't using advanced optimizations just yet. Still, the source code is out there in plain sight and anyone can do it. So it's only a matter of time before jquery gains some of the same compiler optimizations that lend GWT its performance advantage.

Of course, for the code you write on top of jquery to also leverage Closure Compiler, you will have to add it to your build step and use it on your own javascript code as well.

The best Javascript toolkit is...

The contenders are dojo, yui, jquery, mootools, gwt, scriptaculous. The votes are in. The people have spoken. The best Javascript toolkit, by popularity, is....

jquery.

Why I left GWT and came crawling back to jquery

jquery, I'm sorry I said those mean things about you. After all the good times we had together, I walked away the moment GWT batted its eyes at me.

We got along okay at first, GWT and me. But then I started running into problems with the simplest things due to GWT's convoluted overuse of container markup for things like text and links. Trudging on, I encountered vexing UI layout bugs that could not easily be solved without dissecting that very-same convoluted container markup. When I cracked open the Firebug Inspector, I was shocked to see just how many containers were being created for even the simplest layouts, and that same complexity made it mind-numbingly tedious to comprehend the effects of the CSS on all that markup.

Of course, using Eclipse's superior source-code navigation capabilities, I was able to find the offending source code. It was one of those weird decisions made in a private method 4 superclasses up. (To fork, or not to fork? That is the question.) With the offending code safely barricaded, er, encapsulated, I turned back to hacking the CSS rules on that seemingly unending hierarchy of containers. That was when I first doubted my decision to leave you, jquery... But I trudged on, in search of that beautiful, statically-typed, generic, polymorphic sunrise.

The two faces of GWT-RPC

Okay, so the approach to UI layout is needlessly complex and tedious, but at least there is the beauty of GWT-RPC, right? That's what I thought, until I learned firsthand of the nasty RPC problems that arise when you make assumptions about what objects you can transfer. There are JavaScriptObjects and pojos and a bloodbath of DTOs trying to hold things together.

There was the time I naively assumed that I could read a JavaScriptObject from the "wild" and then pass it upstream in a GWT-RPC call. BZZZTT! Please convert to a pojo and try again.

Then there was the dreaded RPC Types Whitelist thingie that couldn't deal with my clever use of generics. I couldn't find this mythical whitelist file, so I just added dummy methods to my RPC interface referencing all the different concrete types I would need to be able to handle. (Bleh.)

Closures

There was also the misery of recreating in tedious boilerplate Java what is so succint and beautiful in Javascript. Closures become anonymous callback classes with several lines of boilerplate for the interface instantiation and the method declaration. I would agonize about whether to convert to a top-level class, which would then require me to pass in all my closure variables to a constructor and hold them in member variables, and pretty soon the once-elegant javascript closure has exploded into a 100-line .java file of its very own...

Java has a degree of elegance when compared to C++, but not next to Javascript: closures save time. Hip companies like Apple know this. Maybe someday Sun will catch up.

Here's your host.... (loading)

Then there's GWT hosted mode with its slow launch time and its generated code that I can't follow in Firebug because, you know, some-really-smart-guy-that's-probably-smarter-than-me wrote it, and so what right do I have to debug code generated by said-smart-guy's compiler? But then there's this little problem called, I have no idea why my RPC is failing, and why does it have to be this hard? and maybe the GWT-RPC mechanism is just flawed, and maybe I should just dump it and rewrite my own RPC mechanism?

Dump GWT-RPC and rewrite my own RPC mechanism? Not a bad idea....

And so I did.

Using jquery.

JSON, JSOFF

The funny thing is, it was so easy. All I needed was some JSON conversion on the server-side and then your getJSON() method took care of everything else for me. And then finally, I had my Firebug back. And I had my closures back. And no more private methods 4 superclasses up; I had my easy mixins back. And suddenly event-handling was easy again.

I miss a few things from that fling with GWT. The CSS sprites were good (ImageBundle, in GWT parlance). The idea of deferred binding is nice. The focus on performance in general, will be missed. The new native hosted mode is definitely a step up from GWT 1.x. I will miss refactoring, sort of. (It's absolutely essential when dealing with the verbosity of Java, but many of the types of code changes that make refactoring necessary in Java just aren't even necessary in Javascript.)

Still, it's good to be back. It's amazing what you can do in just a few lines with a javascript closure. And I don't mind writing "throwaway javascript code" when it feels good every time.