Tonight at its headquarters in Mountain View, CA, Google is holding a Campfire One event to announce some of its new developer-focused releases. Google holds these campfire events a couple times a year — the last one was in April — to announce new product launches that cater to the development community. I’ll be live blogging tonight’s event below.
Update: You can see an overview of the evening’s announcements here.
David Glazer, Google Director of Engineering has taken the stage. He’s outlining some of the Google applications that have been built using Google Web Toolkit. Since the last campfire event, Google has released Wave, a revamp of AdWords, and a redo of the Orkut UI. They’ve also built a number of new internal Google apps. Tonight we’re talking about building faster apps, and running apps faster.
Dotspots founder Matt Mastracci has taken the stage. Lets you create miniature dots related to media. Have been using GWT for a couple years. He’s showing off how you can add a ‘dot’ to an article (he used a TechCrunch post as his example — good choice). One advantage of GWT 2.0 is new development plugin they’ve just launched. Allows devs to make changes without having to go through the whole GWT compile process. Our website is based on GWT. Say you wanted to make a change to your website. Jump into Eclipse, grab the GWT URL, and enter development mode in the browser. Save the code change in Eclipse, refresh the browser, and you see the change live. Mastracci’s summary:
- Developing for multiple targets with one code base is easier with GWT
- Easier to debut in multiple browsers
- Recompiling existing single code base with GWT 2.0 saves time too (Dotspots saw 20% savings just by recompile using GWT 2.0)
Below is a JS app in size 2 font. On the left is the original codebase, on the right is the optimized code.
There’s a size reduction from GWT 1.7 to 2.0.
GWT 2.0 offeres incremental app downloads using developer guided code splitting. Like watching a movie online. Don’t want to have to watch the entire thing, before you can start downloading it. Real-world example for Google: Google WaveWave spiraled up to nearly 1,500 kb in size as they built it. Someone joked about having to ship on a CD ROM. Code splitting was the answer (or at least part of it). In several weeks they reduced startup size by a factor of 7. 1400kb to 200k uncompressed.
Jason Bright, President and Founder of Media Beacon has taken the stage. Showing off of Media Beacon uses GWT. Codebase kept getting bigger and bigger, the problem was we got to 1.5 meg before the login screen. Took 15 seconds to load at 100kb/s. Put in code splitting, jumped to 109kb compressed. Smaller than the logo.
Johnson has retaken the stage. What happens if you’ve had all these issues and resolved them, but the app is still slow? Things you can’t really see. Kelly Norton, the Tech Lead of Speed Tracer has taken the stage. A few of us on GWT got good at pinpointing problem for a web team. Problem is that it involves debugging browser itself, building rom source. Then once in place, have to sift through reams of data to figure out where the problem lies.
Norton has fired up Google Calendar, and is now watching what’s going on inside the browser using Speed Tracer. Can monitor to see if actions of snappy, even after the initial load time. It’s an HTML5 app deployed as a Chrome extension, not a desktop app. “We did this by using Speed Tracer, on Speed Tracer.”
To conclude the event, Johnson has taken the stage to give a special thanks to the WebKit team, which made Speed Tracer possible.