Summary

  • Google launched Gears in 2007 as an open-source browser extension for offline web applications, with Google Reader as its first public example. A developer demonstration used local SQLite storage for queries and full results; its no-Gears branch kept only the queries in cookies.
  • On 24 May 2010 Reader announced it would remove Gears-based offline access from 1 June, citing limited active use and continuing engineering work. Gears stopped receiving new releases in 2011, and Chrome 12's stable release listed its removal on 7 June 2011.

A feed reader is most useful on the train precisely when the train loses its connection. Google Reader's early answer was to put some work and storage inside the browser. In May 2007 Google launched Gears, an open-source browser extension that added JavaScript interfaces for local storage, caching and work outside the page's main thread. Reader was the first named example of an application made available offline. The pitch was bigger than one product: give web apps capabilities browsers did not yet provide, then push those capabilities toward common standards.

The Gears engineers' launch post described the extension as an incremental addition to the existing AJAX web. That mattered. A publisher did not have to wait for every browser maker to implement a new standard before testing an offline application. The price was a new dependency. The user needed Gears, the application needed Gears-aware code, and the publisher needed a plan for which data to keep and how to reconcile it later.

Google's own June 2007 developer example shows the split in unusually concrete form. A sample search application stored queries and full results in a local SQLite database when Gears was installed. Without Gears, its alternative stored queries in a cookie but omitted full results because they were too large. The same page described a further chore: once a local schema was in use, a later schema change required an upgrade script for people who already had data on their machines. Offline access was not a switch one could flick on a server. It was a second operating path with local state and migrations.

That developer sample was not Reader's source code. It establishes the kind of product work the extension invited. Reader's public launch demonstrated the end-user reward: feed items could remain available during a lost connection. By 2010, the product team was measuring the cost of keeping that reward alive. In a 24 May engineering notice, Reader said only a minority of its users actively used offline access. Supporting it required substantial ongoing engineering, and Gears was being superseded by HTML5. The team announced that it would remove offline access starting 1 June. It pointed users to separate feed clients, but did not announce a built-in HTML5 replacement for Reader's offline mode.

The timing is the story. In February 2010 the Gears team said it had shifted effort to browser standards and would stop building new Gears features. It also said there was not yet a simple, comprehensive route for moving an existing Gears app and its users to standards-based APIs. Reader's product decision came three months later. The possibility that the web platform would eventually gain native offline machinery did not pay Reader's immediate maintenance bill.

Google formally closed the extension's road in March 2011: no new releases, no support for newer Firefox 4 or Internet Explorer 9, and a plan to remove Gears from Chrome 12. The team mapped Gears capabilities onto several browser technologies: application cache for offline resources, IndexedDB for local databases, the File API for blobs, and native geolocation, notifications and workers for other tasks. That was a distribution of capabilities across a changing browser platform, not a one-click migration of every application built on the extension.

The Chrome 12 stable release of 7 June 2011 listed removal of Google Gears. Reader's offline access had already been scheduled for removal a year earlier. Two decisions often compressed into one neat technology timeline were made by different owners. The platform team could move primitives into browsers. The Reader team still had to decide whether supporting an offline version of its service was worth the work.

The contrast exposes a hard limit of standards history. An API can survive under a new name while the product experience that first sold it disappears. For the Reader user who counted on a saved feed during a dead connection, “the browser now has better primitives” was a description of future development capacity. It was not the article already waiting offline.

Original records