Hello.

In the early days of mobile web development, Google Gears played a pivotal role in shaping the APIs we use today. It introduced concepts like local caching, local databases, and background processing, which paved the way for modern APIs such as AppCache, WebSQL, Geolocation, and Web Workers. While WebSQL and AppCache have been replaced by IndexedDB and ServiceWorkers, respectively, the legacy of Gears is undeniable.

AppCache, while crucial for offline web apps, has significant issues. One major problem arises when integrating with APIs like registerProtocolHandler or registerContentHandler, which use query parameters. AppCache caches each unique URI, including query strings, separately. This is fine online, but offline, only previously cached URIs with specific query strings will work. Updating the app cache also causes every unique URL stored in the app cache group to be re-downloaded, even if they're not in the current manifest, potentially leading to server overload. This post highlights these issues and calls for better documentation and patterns for offline app development.

During our Google IO talk on Mobile Web Development, we received a great question about handling AppCache storage limits in modern browsers. Our approach was straightforward: we primarily used AppCache for program code, including CSS and JS, along with the main page. Our application's size remained manageable, helped by minifying the JS in our production build using uglifyJS. Although we could have compressed the CSS, we prioritized ease of development. If space became an issue, our plan was to AppCache only form-factor specific code and assets, but thankfully, that wasn't necessary.