Blog Post

Why Google Is Killing Gears & Pushing HTML5

googlegearslogo.gifAs it is with everything Google does, the technology world went into a tizzy when in 2007, the search giant released Google Gears, a way to access web applications offline in your browser. Microsoft (s msft) responded with its own technology and Adobe Systems came out with AIR. And while our readers were divided on Google Gears, we were skeptical of the technology, mostly because of its limitations.

Despite our skepticism, Google Gears, which worked on most major browsers and most operating systems, made its way into some of my favorite applications including Google Docs. But the fact of the matter is that I didn’t pay much attention to Google Gears. I was always so connected — with a BlackBerry (s rimm), an iPhone (s aapl), wireless broadband via MiFi, broadband at home and at the office — and so never needed offline access. And while another time I would have used Google Gears was when I was flying, now there’s usually connectivity in the air as well. Besides, even though I like the idea of connectivity when flying, I much prefer to write out my thoughts in long hand in my always-on Moleskin notebook.

Now, nearly two years later, Stacey has pointed out to me a story in the Los Angeles Times about Google quietly phasing out Google Gears. The company is instead betting the farm on HTML5, a constellation of technologies that make it easy to replicate the Google Gears functionality.

“We are excited that much of the technology in Gears, including offline support and geolocation APIs, are being incorporated into the HTML5 spec as an open standard supported across browsers, and see that as the logical next step for developers looking to include these features in their websites,” a Google spokesman told The Los Angeles Times.

Given that HTML5 is still a work in progress, Google is keeping Gears on life support, as outlined in these comments by a spokesman for the company:

“We’re continuing to support Gears so that nothing breaks for sites that use it. But we expect developers to use HTML5 for these features moving forward as it’s a standards-based approach that will be available across all browsers.”

So what’s behind Google’s big bet on HTML5? In a word: mobile.

The company wants to push HTML5 so that people use it to write web apps that match the quality of the native apps for its two emergent platforms: Android and Chrome OS. Google’s biggest problem with both of these mobile-oriented operating systems is that it has to work with hardware partners, which makes it difficult for the company to maintain a tight control on the ecosystem. Motorola (s mot), HTC, Sony (s sne) Ericsson (s ericy) and Samsung have all come out with their own interfaces for the Android, which is already causing some developer dissatisfaction. Against such a backdrop, it makes perfect sense for Google to promote web-based apps, because it means there be will a unified experience for end users, regardless of the device (and the platform.)

Oh, and let’s not forget about Apple!

appleappsarebig.jpgSteve Jobs & Co. scare the bejeezus out of Google. In a recent interview with Fox News, Google CEO Eric Schmidt candidly admitted that his company needed an open Internet in order to do its job. Indeed, just as it needs to corral information we are likely to search for, Google needs as much access as it can possibly get to what you and I do in order to serve us more targeted advertising.

Apple, on the other hand, thanks to the growing popularity of its applications, is promoting a new way of interacting with what is clearly going to be the next big platform: the superphone. Just as Facebook is training people to consume information via the news feed (river of news) format, Apple is turning compute usage into a specific activity. In doing so, it’s causing some problems for Google, as apps are silos that are out of reach from Google’s spiders. If Google can’t access the content, it can’t serve up matching adds. I suspect that has something to do with why Google decided to spend $750 million to buy AdMob. The ad company’s code is embedded inside thousands of iPhone apps, so its acquisition will ostensibly give Google a chance to still make money despite being locked out of the apps.


As we wrote back in August, HTML5 is a good way to break Apple’s stranglehold, as illustrated by this Pie Guy variation of the classic Pacman game, which uses HTML5 to replicate the user experience you would find normally in a native iPhone app. With web apps, Google can not only continue to have access to user data (public not private), it can also continue to serve advertising to those users. For developers, it would mean embedding Google ads in their web apps. I like the gumption of Google’s plan, except for one small thing: Web apps will need better wireless networks with much lower latency and higher bandwidth capabilities in order to meet (and beat) the native apps.

So there you have it — why Google Gears must die in order for Google (and HTML5) to live on.

(Related GigaOM Pro Research Report: Google’s Mobile Strategy and Research Note: Will Google Lead the Way in Mobile Innovation? Subscription required, sign up for just $79 a year.)

12 Responses to “Why Google Is Killing Gears & Pushing HTML5”

  1. Over the long term, open has always proven to beat out closed, simply because open offers a zillion tiny exits to the next whatever, as opposed to closed offering only a few large and small exits. People in free motion shape limiting boundaries. The more people freely impinging on an energy, the more complex its shape and surfaces.

  2. Om,
    Hi! Nice summary of HTML-5 and its deficiencies on being a viable development platform for mobile apps. There is a huge discovery problem in mobile that Apple has solved through the App Store, which I’m not sure a web browser on mobile can solve in finding the right apps. Already, discovery of apps on Android is a big mess, let alone the fragmentation. In addition, all the mobile browsers (not just iPhone or Android), controlled by the carriers on feature phones should be compliant with HTML-5. I completely agree with you that the performance and capabilities of web apps on mobile will be far inferior to a native apps, any day.

    Interestingly, the same logic applies to device based ad insertion (ads cached on phone) vs streamed ads from the network. If Google has bought AdMob to monetize mobile apps better, I think they only got part of that strategy right. Inserting pre-cached video ads on different genres of apps (games, informational etc.) to replicate the video ad business on web sites, is a completely different ball game. And AdMob does not have the technology to flexibly render the interactive video ad within mobile apps (they are mucking around with the bit rates of video ads and streaming it from the network based on network bandwidth). Definitely  unappealing to a brand that has spent quite a bit of money on video ad production. And not exactly the mechanism to monetize devices such as iPod Touch with sporadic WiFi connectivity, where the users are more often playing games in an off-line mode. The real DoubleClick on Mobile is the company that can understand these ad placement issues and has the right technology to come up with a premium video ad network on mobile, while at the same time giving the flexibility to premium brand publishers to sell their own inventory.


  3. Wonderful post and the comments have added some great value as well. Personally, I love the concept of pushing towards HTML5. The best experiences come from everyone working in the same format, in my humble opinion.

    So, rather than Google’s this leading to Microsoft’s and Apple’s and Adobe’s that, maybe they all will be looking to push HTML5 to its limits.

    From a business perspective it makes great sense as well, of course, but the post and the other comments drive that point so well that I just wanted to add how good it will be for coding in general.

    • AIR wasn’t a response to Gears.
    • Gears does a lot more than offline mode. It’s largely HTML5 support in plugin form.
    • I don’t know if “constellation of technologies” is the best phrase for HTML5. It has a spec, and members from major technology companies are working to support it just like they did with HTML4 and XHTML. It’s pretty well supported, although we’ll see what IE9 looks like.
    • Yeah, it is a “work in progress”, but practically speaking, Firefox and Webkit are already able to use some of the best tech today. If IE9 supports HTML5 in a big way, a lot will change in the coming years.
    • Apple is extremely bullish on HTML5.
    • Yes, the AdMob purchase was so Google could serve ads on mobile apps. If that wasn’t their goal, buying a mobile app ad network was probably misguided.
    • I think anyone is a fan of faster networks. But one of the great things about HTML5 is client-side databases and client-side “manifests”, essentially a massive cache. These two items mean that once the web app is “downloaded” the first time, the network becomes far less important.
  4. This is the age old argument that you covered nicely. Native or Web apps? So far the winner is native apps but if desktop history is any example, web apps should be the ultimate winners. Question is when and the catalyst for it.
    Today native apps are so convenient that we can’t imagine life without them and so some cool new web apps have to prove that they can deliver the great user experience and may be Google should start with its apps on Android and iPhone.
    Better connectivity will always help but don’t think is in the way of this transition.

    It is a battle between Apple and Google at one level and MS and Google at another level as MS is also resisting HTML5. Is there another browser besides Chrome that supports HTML5 today?

  5. Om, I was with you all of the way until you wrote, “Web apps will need better wireless networks with much lower latency and higher bandwidth capabilities in order to meet (and beat) the native apps.”

    I don’t understand your point there. Native applications have the same network limitations that web apps do. Native computing performance doesn’t address network latency or limited bandwidth.

    FWIW, the five common arguments for native development versus HTML for mobile devices that I’ve heard from people are:

    1. Offline Mode
    2. Findability
    3. Performance
    4. Device Attributes
    5. Monetization

    To my mind, those are the hurdles that Google–and anyone else who wants to see the mobile web become a viable alternative to gatekeeper appstores–needs to overcome.

    I wrote more about these five factors at if you’re interested.

    • Jason

      I am not arguing against the web apps. I am arguing for better connectivity and lower latency. Those two factors will help with adoption.

      Your five points — I pretty much agree with, though not sure I quite understand the monetization argument. Care to elaborate?

      • I didn’t think you were arguing against web apps. What I didn’t get was why networks with lower latency and higher bandwidth weren’t just as much of an impediment for native apps.

        I think we’re talking past each other some how. Next time I’m down in San Francisco we’ll have to have a longer chat than the quick one we had when Surj introduced us. :-)

        Regarding monetization, it’s simply easier to buy iPhone apps than it is to buy things on the mobile web. Entering credit card information on the phone is not fun and integrating carrier billing means wading into a mess of different rules and revenue sharing percentages.

  6. One key component being forgotten — the offline access is just as useful for the webapp once on the phone (even with advertisement), let me explain.

    When purchasing an app, the user has to be online, so the web app loads once and is immediately archived for offline browsing. Embedded in the app is an ad generator with a pre-defined set of ads to run while in offline mode. The “webapp” and ad generator store all data while offline and once within connectivity range again, go out to update.

    I see this as a very likely solution, and quite honestly, it’s brilliant. On more popular apps, google can up the stakes on being available in offline mode because, depending on the duration, your ad is likely to see 2-20 times more cycles during the user interfacing with that app.

    The fact of the matter is, Google’s vision of the internet will happen, one day. As to whether it’s “around the corner” or “down the road, take a left at the gas station, follow that till it runs out and it’ll be on your left… you can’t miss it” remains to be seen.

  7. Hasn’t Google always maintained that Gears was just a cutting edge implementation of a future standardized way of storing data locally? Why would Google want to keep local storage in Gears when modern browsers natively support it?

    I am surprised that Google is killing Gears though. I always thought Gears would be a playground to add functionality to other browsers. As local storage and geo-location goes out, new cutting feature come in. I guess Google is betting on Chrome to push other vendors into adding features.

  8. Om,

    Your post makes a lot sense, especially in light of the fact that handheld mobile devices currently outnumber desktops/laptops by more than 4 to 1 worldwide. That said, the HTML5 bet by Google is sound as “apps” on handhelds only make up for poor web browser experiences. These “apps” will go the way of desktop software when the day arrives when there is a mobile browser with critical mass. I think Google recognizes this likely possibility.

    My $.02.


    • Curtis,

      I think Google is right in thinking along these lines but in order for mobile to replicate the wireline-based web app experience, some things have to improve at the infrastructure level. The good news: LTE will help and so will the pervasiveness of WiFi.