Cranking up the browser

Not everyone agrees that moving Web apps outside the browser is the right approach.

"We think the browser is where it's at. We want to push that forward," says Dion Almaer, developer advocate at Google. "Google has been building all of these Web applications -- we're basically Web developers -- and we wanted to add functionality."

Since the Web's inception, all browser-based applications have shared certain limitations. Foremost is their reliance on the network; lose your Internet access, and a Web app's greatest strength becomes its greatest weakness.

Google Gears aims to solve this problem. A Gears-enabled application looks and behaves just like a regular Web app, with a difference. Client-side Gears code caches HTML, images, and JavaScript while you work, allowing the application to keep running even if you lose your Net connection. When you submit a form or modify data, the request is queued in local storage and synchronized the next time you're online. The overall effect is like running a native desktop application, without sacrificing the core browser experience.

"With Gears, you still go to the same URL, the application works, and you don't have to have any companion apps. It's extending the Web to places that maybe people weren't used to before," Almaer says -- even, for example, to an airplane seat.

The client-side Gears code confers other benefits, as well. One module, called WorkerPool, speeds up AJAX applications by executing JavaScript instructions asynchronously in the background, freeing the browser to handle user interaction and page display. Future Gears modules will add APIs for location-based services and unified event notification.

Google's Gears strategy is all about restraint. Unlike AIR, which advertises its presence to the end-user, Gears works quietly, in the background. Rather than confounding developers with hundreds of new features and APIs or forcing them to learn a new application paradigm, Gears adds just a few new capabilities to the browser, each designed to address a particular pain point.

"It's kind of similar to how the XMLHttpRequest object allowed AJAX," says Almaer. "This tiny little module with a little bit of functionality enabled developers to be creative. We're trying to do that approach."

Share alike

Of course, there's no one answer. While in some respects each of these technologies competes with the others, they are also often complementary.

For example, there's no inherent conflict between Prism and traditional browsers. "Today's SSBs just make it much easier to escape the browser and add some neat OS conveniences," Mozilla's Finkle says. "I think we'll see some of these conveniences start to appear in traditional browsers, too."