Under Gmail’s hood

I’d been experimenting for a few months with Gmail, Google’s Web mail system, without really taking it seriously. But this week I decided to take the plunge and try using Gmail not only as a mail search engine, but as a replacement for Outlook (on Windows) and Mail (on OS X). Now I’m ready to join the chorus singing the praises of GMail’s user-interface technology. Its combination of HTML, JavaScript, and the DOM makes the browser do some remarkable tricks.

Free IT resource TechNet: More ways to know it, share it, and keep it running. Sponsored by Microsoft Free IT resource Attend the SOA Executive Forum: Breaking SOA Bottlenecks SOAExecForum.com/may2007 Sponsored by InfoWorld

One of my favorite acid tests is address completion. When you begin typing an e-mail address, your mail program should immediately show you the matching addresses and then dynamically constrain the list as you continue to type. Outlook does poorly on this test; you have to type CTRL-K to invoke the address book in a separate window. OS X’s Mail does address completion in situ, just as I expect. So does Gmail. And here’s the shocker: Gmail does it faster.

Gmail’s spell checker is another amazing hack. When you invoke it from the message composer, misspelled words turn red. Click one and a list of choices drops down, ending with an Edit choice. Click Edit and the suspect word converts, inline, to an input box. When you’re done correcting one or more words they merge back into the text.

As early adopters discovered long before I did, there’s an architecture behind this JavaScript/ DHTML wizardry. The best description I’ve found is from Johnvey Hwang, who deconstructed Gmail’s JavaScript code and created a .Net-based Gmail API. As Hwang described in his July 5 write-up, Gmail loads a JavaScript “UI engine” into your browser at the beginning of each session. Oddpost, he noted, was the first Web mail application to perfect this technique. That was a prophetic statement: Just four days later, on July 9, Yahoo acquired Oddpost.

Because Gmail’s behavior is embedded in the UI engine, all subsequent interaction between the browser and the Gmail service is just an exchange of data. What Hwang calls the DataPack format is not XML, though; it’s JavaScript. When you make a request to the Gmail service, whether to refresh your inbox or to modify the list of labels you can attach to messages, the response is a minimal set of JavaScript function calls and associated data objects that the engine uses to update the display.

This is very geeky stuff, I admit, but here are two important points to take away. First, as I’ve often said, intelligent use of browser-based technology can accomplish more than most people realize. You can’t do everything — not by a long shot — but for many of the things that information workers routinely do, even ordinary Web UI is good enough. And now Gmail is proving that we don’t have to settle for ordinary.

Second, Gmail’s architecture is not limited to Web UI. Because it is protocol-driven, developers can create new tools that speak to the DataPack format. Many have done so already. My favorite spam filter, SpamBayes, isn’t yet implemented for Gmail, but if that happens, I’ll be sorely tempted to switch to Gmail full time.

So is Gmail a rich Internet application? Sure. Although that label most often applies to Java, .Net, and Flash clients, Gmail shows that Web clients can join the club too. But crucially, Gmail’s architecture is open to other kinds of rich clients, too. It doesn’t have to be a zero-sum game.