http://sourceforge.net/projects/packtag

GWT will also soon provide a mechanism for compilation-split lazy-loads, combining the best advantages of GWT’s heavy optimizations and packaging, with the ability to indicate which parts of overall program control flow are required for startup vs capable of being deferred.

Even without deferred loading, GWT typically boasts perceived startup times that are fast, one of the best examples being the Dojo and ExtJS Mail and Feed reader samples vs GWT equivalents. The GWT versions with essentially the same functionality startup anywhere from 2x to 5x faster.

I would also quibble about the combined size vs individual file size + headers comment. You don’t want to just optimize bandwidth consumption, but also latency. Each HTTP request adds latency, even those over a reused and pipelined HTTP connection. When I look at network latency in Safari or Firebug, even on pipelined individual requests, I still see 10-40ms latency from the addition roundtrips.

To optimize download, the combined size of the file should not be larger than the size of the required individual files plus the HTTP headers to retrieve them. This means that at some point you should package your combined scripts so that nothing (or few things) extra gets downloaded for a given page. Bundling everything into one file may increase the download and render time for many pages on your site.

Only for some, and only in the near term. In the long term, GWT is bound to be multilingual and include front end support for compiling JS2, and perhaps Scala. The benefits to endusers are undeniable, and there are enough polyglot programmers who aren’t vehemently anti-Java zealots, that it is still worth evangelizing. It’s sad, but alot of AJAX advocacy really centers around Javascript zealotry.

It uses a number of mechanisms to do this. It compiles all of the source code and resources at once, aggressively optimizing and obfuscating the Javascript in ways far more compact than JS minifiers/packers. It allows all images to be auto-sprited. It can take sprited images, CSS, locale data, even Flash SWF, and effectively inline them into the same file containing the JS (using data URLs). It includes a CSS optimizer as well, so prior to packing the CSS, it optimizes it.

The end result, is that you can, if you choose, reduce your entire app down to 2 HTTP requests, the second being in the cache 99% of the time, bringing the amortized number of requests to 1. And the data that is cached/loaded, is extremely optimized for size and speed.

The only “downside” for some, is having to use Java. :)

Now all we need is YUI on-server to minify all scripts. Or something.