Google's money won't be made with search... that's small peanuts compared to selling access to the world's biggest, best, and most cleverly-utilized map of the web...
Google isn't worried about Yahoo! or Microsoft's search efforts... although the media's focus on that is probably to their advantage. Their real target is Windows. Who needs Windows when anyone can have free unlimited access to the world's fastest computer running the smartest operating system? Mobile devices don't need big, bloated OSes... they'll be perfect platforms for accessing the GooOS. Using Gnome and Linux as a starting point, Google should design an OS for desktop computers that's modified to use the GooOS and sell it right alongside Windows ($200) at CompUSA for $10/apiece (available free online of course). Google Office (Goffice?) will be built in, with all your data stored locally, backed up remotely, and available to whomever it needs to be (SubEthaEdit-style collaboration on Word/Excel/PowerPoint-esque documents is only the beginning). Email, shopping, games, music, news,
personal publishing, etc.; all the stuff that people use their computers for, it's all there.
By the way, Rick Skrenta pointed out (via the New York Times) in April 2004 that Google had at that time 100,000 servers. Eight months later, Charles Ferguson points out (via his MIT Tech Review article, What's Next For Google) in December 2004 that Google has 250,000 servers. If they double roughly every nine months, Google will have a million servers in summer 2006. Ferguson writes,
Today, the wholesale search market has significant barriers to entry. Economies of scale have asserted themselves, secondary competitors have folded, and the creation of new search engines by startups is becoming prohibitively expensive. Consider: to crawl, index, and search more than eight billion pages -- still only a fraction of the Web -- Google now operates a global infrastructure of more than 250,000 Linux-based servers of its own design, according to one Google executive I spoke with, and it is becoming a major consumer of electrical power, computer hardware, and telecommunications bandwidth.
I'm still stuck on the notion that in less than two years Google will have a million-node computer operating as a single, optimized operating system for web-based applications. Google gets it. Most professional developers look at web-based applications and all they see is "the lameness of web pages as a UI", as Paul Graham called it. They grumpily say in Eeyore fashion that web apps are the legacy apps of the future. They don't see that the power of Weblications is that "simplicity and flexibility beat optimization and power in a world where connectivity is key", as Adam Bosworth put it.
It is no coincidence that in 2004 Google hired Adam Bosworth. It is no coincidence that in 2004 Google hired among-the-best-and-brightest-in-the-world web developers such as Chris Wetherell and Aaron Boodman -- and they are searching for more. Because 2004 is the year that Google led the charge in making applications that showcase The Web Way -- using just the simple and flexible mix of dynamic HTML, JavaScript, style sheets, and a DOM-capable browser -- respectable and cool and (most importantly:) useful enough to be considered a viable alternative to The Three M's Of UI Lock-in (Macromedia, Microsoft, and Mozilla), all of which aim to fatten up the client and
lock some users in and lock other would-be users out because they don't have Flash or XAML or XUL or any other doesn't-work-on-some-platforms complex soup like Java Server Faces and Struts taglibs. When it comes to simple, ubiquitous, usable user interfaces, Dynamic HTML is one ring to bing them all.
It took a long time -- upwards of a decade since Netscape released the first widely-used, widely-deployed browser -- for The Web Platform to become stable enough to build complete, beautiful applications upon. In 2004, Google's applications like Gmail and experiments like Google Suggest demonstrate that we can have robust, interactive, useful web-based applications. Joyce pointed this out over the weekend in her essay, Google is good for webdev, in which she wrote,
Google is quietly hiring -- they probably have between 5 and 10 of the top front-end devs, which doesn't sound like much until you realize there might be only a couple dozen out there with significant experience. That decreases the supply of the remaining ones, which as we all know means you're gonna have to show them some serious love to enjoy their scarce favors.
Most importantly, Google seems to be putting some chips down on the DHTML side of the table instead of the Flash or XAML or XUL or Laszlo sides. Given how important a few technology leaders are as role models for all developers -- I dunno how many arguments I've had where the magic words, "But Yahoo/Amazon/Google does it this way!" work their incantatory magic -- this is very much a Good Thing. So I've got to thank Google for making it viable to spend money building newer, faster, more responsive, standards-compliant, user-centric, cross-browser interfaces. Whatever the opposite of "collateral damage" is -- collateral benevolence? -- Google is doing it for webdev now.
What's so significant about the development of Gmail? Jon Udell looked under the hood, and was enthused by what he saw:
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.
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.
In Gmail's case, the weblication was better than the non-web-based applications. Gmail raised the entire discussion of what is possible with web-based applications. It didn't go it alone -- it built on the knowledge of web-based applications learned by those who had previously written state-of-the-art weblications. What's significant is that it was able to break through expectations, and proved that "we don't have to settle for ordinary" with web-based applications. Koranteng Ofosu-Amaah clarifies this point in his essay On GMail and DHTML architecture again, in which he writes,
GMail's architecture is actually very generic for a DHTML app. Everyone with a clue should be trying to leverage the browser and that, in essence, is all they are doing.
It is riskier to do more on the rich browser client because it has been a more brittle platform over this past decade. Companies that do middleware and server-side tooling take a while to move from their core competency. Architects that thrive in that environment are essentially conservative and for good reason... Four years later, I now hear mutterings about drag-and-drop and richer clients in our corridors...
This only underscores the point that Jakob Nielsen's predictions about browser adoption cycles have turned out to be pretty accurate. Even though web application developers have been quietly spreading unobtrusive javascript usage in the interim, it is only now that there's a critical mass of clients that can leverage them; when Amazon and Yahoo move, something must be happening.
The developer tools and resources have gotten (slightly) better and there's more experience with the DOM. Increased adoption of broadband also helps reduce latency for the average client so you don't have to fight the inevitable arguments about performance and can couch your advocacy in terms of user interaction. In any case if and when you do have the performance discussion you can always argue that caching as close to the client as possible is a good thing and what better cache than the browser itself. It just so happens that applications like GMail, Bloglines and Oddpost are the state of the art in terms of browser leverage.
I recently wrote about this type of architecture in my recounting of the history of the DHTML spreadsheet and presentation components that are the genetic forebears of OddPost.
The idea is to fetch an HTML skeleton, decide what content you need, fetch that (as XML), and cache it wherever you get a chance. Render incrementally.
Adam Rifkin,
Weblications - December 20, 2004
Previous
