What a great way to kick off the conference! There was lots of GWT focus even starting during the keynote, which I honestly didn’t expect; HTML5 and browser video was big but GWT was right there behind it. Real backing from SpringSource/VMware was good to see and the SpeedTracer and 2.1 widget demos were impressive. The keynote is up on YouTube already, with sessions to follow in June.
My big takeaways the first day relating to GWT are:
GWT 2.1 is just around the corner and is heavily performance-focused with more general purpose widgets that will let us display data quickly. Specifically they seem focused on high performance grids and layout strategies, which really started taking off in 2.0.
SpeedTracer has some really powerful new features like being able to add arbitrary benchmark points in code that show up in its UI, and ability to link back to the actual line of Java code for a GWT project (not just the obfuscated JS), along with the server-side integration via Spring from the keynote; while I haven’t tried yet it’s all in the latest milestone and should essentially be available now.
There are a lot of undocumented compiler options to further reduce code size and some other JVM options you might not have expected can help too (like -server and a 64-bit JVM), but using code splitting really makes the biggest difference (yay!), as well as some other things I’ve suspected like avoiding singletons and other static initializers at all cost.
Linkers are really easy to build and are a powerful way to handle the final creation of an app with far more metadata available than, say, manipulating files with ant. Unfortunately something like static linking – an idea many of us have thought about to reduce the coupling between different GWT modules that inherit each other – needs heavy interaction between both the compiler and linker, and even though it’s open the core compiler is far less documented/outside developer friendly right now. However, there is really cool work being done to support distributed compiles that’s separating the work out in a way which might be divided not only among a cluster of machines across permutations, but used to save artifacts and re-use them if the underlying module hasn’t changed. I chatted with some people after the session and there is just a lot of work to be done in that smart splitting/change detection that puts it in at least the 2.2+ timeframe.
Architecting for Performance
Most of these best practices were things my team is already familiar with like putting serious thought into how the application is bootstrapped, how many RPCs we’re making, and what the payload is, specifically the importance of having UI-focused meta-services that return exactly what a UI function expects rather than simple generic services with heavy lifting in the client, plus more “use code splitting!”. However some new ideas are using UIBinder to separate out (and obfuscate, in production) css, using LazyPanel to defer rendering as late as possible without affecting the contract of widgets to their consumers, and designing UI’s with more optimism when an RPC takes place (assume it will work and begin the “success” case immediately, finishing as the data arrives, but potentially more work to handle failure).
A theme here was orders of magnitude, and the idea that performance is just a characteristic of usability:
- 100ms = “instant” to users, almost everything should be faster than this – I related to this to anything that’s purely client that I expect to be unnoticeable
- 1,000ms = “keeps focus”, this is a pretty big deal but things above this can be managed with explicit feedback – I related this to anything requiring a potentially slow RPC load and putting up some kind of “Searching…” or “Waiting…” dialog
- 10,000ms = “upper limit”, the longest you can possibly ever take before a user has surely alt-tabbed, gotten up from their desk, force-killed your app, etc.!
There’s a ton of buzz around this right now, but the short story for the moment is that any app forced to stay seriously in the IE7-8 world (which, sadly, mine does), is going to be crippled. To take advantage of what, as they like to say, “all modern browsers” are capable of, apps are going to need a user base comfortable running Chrome, Safari, and Firefox (and I guess Opera), else they’ll be left in the dust.