Udo's Techblog

Web apps are great, especially for data entry and data review-type of applications. They're great for developers, because they don't have to code much to implement lots of functionality, also deployment and code/data concurrency is pretty much a non-issue. Users love web apps because they are virtually risk-free to use and easy to understand. And they are accessible from anywhere.

Well, not quite anywhere. And here, the problems of the supposedly ubiquitous web apps begin:

• Connectivity is not ubiquitous
  You can't use them when you're flying. If you don't have a free data plan and appropriate equipment, you can't use them while travelling. Sometimes all you get are pre-dialup speeds on your connection, and suddenly all the coolness of the web breaks down.


• Control over your content
  Web apps go out of service, or they just lose your data by accident, so you want the option of making offline backups of your own stuff. But you can't.


• Local hubs
  In other cases, you want to tie several online services together, but since they are not interconnected and you don't want to trust one service with all your online credentials. There is no nexus to tie it all together.

In spring 2007 Google Gears came out as a response to those issues. To be exact, it only adresses the first point. But still. Gears was supposed to help web developers roll applications that were going to provide some offline functionality. Now, one half year later, independent developers haven't yet picked up Gears while Google's own apps are also conspicouosly missing Gears support, with the notable exception of Reader for which Gears was probably developed in the first place.

There are two possible reasons why Gears wasn't received well: either there is no real need for web applications to have offline capabilities, or Gears just can't solve the problems imposed by this issue. My money, of course, is only the latter. Offline web application development faces the following issues:

• Synching
  The whole purpose of offline apps is to be able to work on your data while not connected to the master database. The general is that the offline storage retrieves all or part of the online master database, then disconnects. Now, while disconnected, two things generally happen: the offline database changes (because you work on the data) and the online database changes (because other people modify your data). All of a sudden, you have all kinds of concurrency problems, but the most fundamental issue is: how can we get those two databases to sync? Obviously, the mechanisms appropriate for this behavior differ with different types of applications. But Gears does not address a single one of them, nor does it even provide any kind of agnostic update mechanism for data.



• Abstraction
  The Gears offline package is basically just a JavaScript API with two local storage engines attached (a code caching repository and a mini SQL database). Now, when developers write web applications, they usually write a lot of server side code. This is where the intelligence of the software lives. PHP, Ruby and Java come to mind as the main environments where this code lives. On top of that, developers sprinkle the output of these apps with some JavaScript to make it work better in browsers. By now it should be perfectly clear why a developer who wants to use Gears, has to implement everything twice: one time for the server side online version, and then they have to do it again for the reduced offline version (this time entirely in JavaScript using the Gears API). The number of people who have time for this exercise in futility is basically zero. Especially when you have to keep in mind that you also have to maintain two versions of the software at the same time.


• Functionality
  I've touched the issue with the above bullet point already, but I think it's worth to point out again that there is probably a reason why people use PHP, Ruby or Java to write web applications - not client-side JavaScript. Although AJAX purists claim the opposite, JavaScript-only applications are security nightmares, they run terribly inefficiently, and they're hell to debug.

I find it absolutely puzzling that locally installed web runtimes are not a standard part of operating systems by now. Adobe seems to be the only company who at least looked at the basic concept with Aero. Every Linux system comes with runtime packages for character-driven interfaces and at least two different GUI interfaces. Every Windows desktop had character mode bindings, as well as a sheer buttload of Win32 interfaces to choose from. Every Mac software has the option to run in console mode, there are Carbon and Cocoa bindings and whatnot.

All it would take to make web applications installable locally is a piece of webserver software, some language interpreters and a database. Slap an installer/package manager (and if you want to be fancy: some kind of app compartmentalization) on top of it and you're all done! Imagine, with a solution like this, developers would have to code all the stuff just once. A real runtime installed locally would reduce the hassle of offline-support essentially to a single issue: data synchronization. That's hard enough to solve on its own but at least developers would not have to worry about the other horrible stuff they have to go through when relying on a half-assed solution such as Gears.

So: who will be the first to market with a true web runner?