Google’s inroads into solving 3 of 4 web-based app problems

This week Google has taken two more big steps toward The Last Computer, with release of Google Gears and acquisition of GreenBorder virtualization technology. Too bad they’re stepping with such clunky shoes.

In my previous post (Browser-based thin-client apps) I wrote about why Web 2.0 AJAXish applications are part of The Last Computer. But I also wrote about the four reasons browser applications will not replace all desktop applications.

3 of 4 web-app problems are solved by removing old client/server thinking

The first three of those four problems (Connection Required, Slow, & Sandboxed) are not a problem of the browser paradigm itself (although the fourth reason, HTML == Poor Interface, is). These three problems are due to an old, fixed way of thinking about browser apps. The old thinking is that the browser is on a client machine, and the server is on a distant machine somewhere on the other side of the internet, and never the two shall meet. There is no reason for this separation other than tradition, and if this tradition is broken then the first three problems approach zero.

Consider: For ftp, bit torrent, and most p2p applications, there is no single client talking to a single server. The client is just as often a server. Client/server are outdated concepts.

The first step to breaking with old web/server thinking is to realize what a web server is: it’s the simplest bit of software ever written. A web server receives a request in a string; it sends back a response in a string. There’s no easier program to write than a basic web server. Perl fans like to write a web server in just a few lines. I’ve written at least twenty different web servers using Nombas’ ScriptEase Machine, because it is easier and smaller to create a specific web server than to install and configure a big commercial one.

Big Step #1: Move the web server onto the client

Realizing what a small effort an actual web server is, especially if it services only one client, there is no reason not to move that web server onto the client machine. Simply by moving a web server onto the client we’ve already (mostly) solved the first three of the web-app problems:

1. Connection Required – Solved: server is on 127.0.0.1, no internet needed
2. Slow – Solved (mostly): No internet latency added
3. Sandboxed – Solved: Server has full access to client’s machine

For years I’ve used this web-server-on-desktop approach to create simple applications that use a browser interface to access my own computer. Mostly these have been for personal use when I need a quick program with a simple interface—usually a browser link or simple browser form will suffice. It works great (although it always feels like a hack).

Google Desktop was the first widespread offering I saw that used this approach. With the first Google Desktop, which allowed Google-like searching to spread to your own personal computer, what Google did was simply to write a web server that you ran on your own machine and so could search your local files, and your existing browser became the interface to what that installed web server delivered.

BTW, this Google Desktop interface was terrible. People didn’t notice it was terrible because it looked just like regular Google results, which are fine, for the web (where expectations are very low), but when compared against a real desktop app it really was/is terrible. Long before Google Desktop I’d been using Copernic for the same thing. Even more so than my comparison of GMmail vs. Outlook, Google Desktop versus Copernic, side-by-side, showed the extreme comparative suckiness of browser as an interface.

Big Step #2: Join my web server into “the cloud” – Any computer is the network

So Google long ago realized some benefit of moving a web server onto the client. Why did they stop there for so long? Wouldn’t Gmail, and others parts of Google’s huge suite of web-based applications also benefit (i.e. lose 3 of 4 web-app problems) from moving the server onto the client?

Consider: Google does not have “a server” delivering my Gmail, web results, and so on. Instead, Google is some kind of amorphous cloud of machines that somehow magically act as one huge magical system. Those machines are fairly straightforward boxes. They’re unreliable; they break. Google works around problems. It’s magic.

I’m sitting here right now on a computer that is pretty much the same as those gazillion Google computers. But my computer can be dedicated to serving just me, while in the Google cloud I surely get less than one full system dedicated to me. Why cannot my personal computer become part of that amorphous Google web server cloud? The web server on my computer can better service me individually (online and off) but can also be part of the Google mega-computer-cloud. It’s the best of both worlds.

Google begins big steps with Google Gears, solving 2 problems (and creating more)

This week Google introduced a beta of Google Gears, taking those first two big beta steps toward solving the problems of browser-based apps replacing desktop apps. Google Gears is (primarily) a web server that runs on the desktop. In time, I expect Google Gears to tie into the Google cloud. The result being that all Google web applications will work when offline (synchronizing when connected), will become faster (because they will work directly with the local server), and will break out of the sandbox and allow access to data on one’s one computer (initially in limited form).

With Google Gears, web apps will become, for most functional intents and purposes, synonymous with desktop apps.

Google extends baby steps with GreenBorder virtualization acquisition

When you look at the Google Gears site, the first thing you see is this:

This is an early release of Google Gears (BETA). After installation, please pay attention to the warning dialogs and grant access only to websites that you trust.

Once you extend the Google cloud to the desktop, so that any computer is the network, you’ve now introduced some big security holes. As the sandbox is opened and allows more capabilities, it also allows more danger. For instance, a web server on your Windows desktop has full access to delete your entire drive, read financial data, etc… whereas the browser on its own (barring bugs) cannot.

This is where Google’s second big news of the week comes in, their acquisition of GreenBorder. This acquisition has so far been reported as just a tool that protects a browsing session from danger, but I believe it has a deeper purpose that, when tied with Google Gears, gets Google closer to their version of The Last Computer.

If you can virtualize the session, not just of the browser but of the browser combined with Google Gears, then you have two things. 1) A safe environment for web apps that can do nearly anything a desktop app can do, including accessing much of the local computer’s resources, and 2) A virtualized “desktop” that can be neatly bundled, backed up (or cached), and even shared with other computers, so that as you move between computers your virtualized sessions can move with you.

With Google Gears and GreenBorder, can Google now replace web apps?

In combining Google’s news of the week, the whole story is much bigger than the sum of its parts. Google Gears + GreenBorder (+ existing Google apps) ~= Web Apps Replacing Desktop Apps.

That’s a big story. Enough to make Microsoft and Adobe squirm (more on them in future blogs). But this story still has a big problem: problem #4: HTML sucks for making rich and compelling interfaces. The browser, composed of HTML + CSS + Canvas + Plugins + Ecmascript + KitchenSinks, does not make pretty interfaces, at least not without a ton of hacks, memory, and money thrown at it for every application. The browser and its markup are just the wrong tools for making rich applications. Furthermore, the browser is not a thin client as it’s so often billed to be--it’s a fat, clinically obese, needs-a-crane-to-leave-the-bed client.

Close, Google, but no cigar yet

With these recent steps, Google is getting close to The Last Computer, but in some very inelegant ways. At least they show that they understand what The Last Computer is all about. And in their Googly way (with the nearly limitless resources of money and smart people to throw at the problem, even if they are hobbled by inelegant choices of basic components) they’ll probably make it work sufficiently well to become an integral part of most Last Computer systems.

---

Addendum June 10, 2007:

For more discussion on why Google Gears is almost right, but not quite, because it avoids the difficult replication tasks, see Dare Obasanjo's blog Google Gears: Replacing OneProblem with Another and an associated eWeek article Can Microsoft Be the Wrench in Google Gears?