Google Web Toolkit: Now With Speed Tracer, Code Splitting, And More

This evening at its Campfire One event, Google showcased a number of new technologies coming to Google Web Toolkit (you can see my live blog of the event here). The big announcements include the release of a new Speed Tracer tool to help developers speed up their web apps; a code splitting tool that enables developers to deploy apps as incremental downloads; and UiBinder, a UI framework that allows developers to separate the ‘logic’ presentation of their apps from the presentation portion.

Speed Tracer is a new extension for Google Chrome that is meant to help developers streamline their web applications. In particular, the tool is built to help optimize AJAXy applications. Obviously there are other tools for speed optimization, but many of these have to do with load time. Speed Tracer is meant to track performance over an extended period of time, as users tap into an app’s various functions. Google’s Andrew Bowers explains that Speed Tracer can track performance bottlenecks in ways that were not previously possible, because it taps into APIs that were built into Webkit for that very purpose (APIs other browser engines don’t offer).

The tool will allow developers to isolate exactly which functions in their app are taking a long time to perform, allowing them to monitor performance in real time. It will suggest that developers take a look at certain problem functions (namely actions that take over 100ms, which is when users begin to notice a lag time).

The second major addition announced at tonight’s event is developer guided code splitting. Bowers says that when the Google Wave team was first building Wave, the size of their JavaScript app grew to 1.4 megabytes (that’s a lot, and will lead to a long initial loading time for users). To help deal with this Google found a way to split code into chunks and to only initially serve the portions users needed. In other words, when you go to Wave now, your browser is only downloading the portion of the app it needs to run the most basic functions. If you decide you want to access something beyond that — say, the Settings menu — the app will quickly fetch that once you click the ‘Settings’ button.

This isn’t the first time developers have been able to split their code — in fact, some of them try to fully automate the process. Bowers says that Google is taking a different approach. Rather than try to fully automate the code splitting, Google Web Toolkit will allow developers to pick and choose which functions users will need to be able to access. The tool will then identify which code corresponds to those functions. In effect, developers are still responsible for choosing which functions they want to have available on the app’s initial load, but the tool can manage things beyond that.

The third tool to launch this evening was UiBinder, which came out of some of the work Google has done with AdWords. Bowers describes UiBinder as a declarative UI that allows developers to bind a layout template and associate it with a Java file, without having to merge the two. He explains that in a typical Java file, developers often have to combine the layout portion of the application with the logic portion of the app. In that scenario, when a designer wants to tweak the look of the app, the logic has to be tweaked too. Using UiBinder, developers can keep the two separate, so layouts can be adjusted without having to rewrite any logic code.