Google Chrome is not an OS replacement, but could it be?

Since the launch of Google Chrome yesterday, a handful of people have been touting it as a Google OS if you will. It’s not. However, I’d argue that Google missed a huge opportunity here to not redefine the browser as an OS alternative but rather to make it a potential OS shell and runtime alternative. Now that would have been remarkable and worthy of all the attention Chrome has gotten so far.

With the renewed interest and market feasibility of netbooks, small notebooks and proposed devices like the OLPC2, a browser oriented device has some appeal. Limited local resources. Focus on connectivity. I don’t see how Chrome, though, helps to realize the dream of these devices. It’s just another browser following the same old implementation model.

But what if it weren’t? What if Chrome had been designed to be the core way we’d interact with a netbook or an OLPC2? What would it need to be like?

Well, I think it would be much different than Chrome or any other browser in some structural way, yet still be able to retain all the classic page-oriented compatibility that browser’s need.

Let’s not get ahead of ourselves here. Look at the iPhone. Did it not demonstrate that if you just take the browser as is, that it only provides so much capability–not enough to trump native apps. Just look at the flourishing App Store for the iPhone. Is there no doubt that even on it, native apps trump browser apps in most cases?

Here’s the thing: Today’s browsers have a couple fundamental flaws at their core–which almost guarantee the continued survival of native apps.

* First and foremost: Browsers are missing a paging model. What do I mean by paging? Browsers/HMTL should fundamentally provide the ability to page content. You can kind of do it using AJAX, but I mean fundamentally browsers should be able to page content somewhat like PDF plugins do. In fact, done right, PDF isn’t even needed outside of providing an alternative persistence format.

* Caching–which is also about paging of resources–is also something that needs to be implemented better at the core. I’m not just talking about cookies. I’m talking about the browser bringing down a 300 page book and then releasing 200 unread pages to free up resources for something else being read right now. Google Gears, et al are patches to a problem that should be solved as a fundamental. It’ll open up so many possibilities for apps.

* Primitives. A great browser will have great primitives that make using browser apps compelling. Some of these will help to intelligently manage the resources behind the scenes for a particular app; some will be UI oriented, such as page swipe effects, and the like; some will be app oriented, such as providing editing support, spell checking, and so on.

* The desktop is the home page. Icons, gadgets, etc.

* Autosave should be standard with a potentially huge undo stack saved to the cloud, with incremental versions of the full document saved occasionally off the device. In this way, undo can work across sessions if you’re connected.

Now to be fair, the browsers are inching in the direction of adding these kinds of features, however, I’d make the argument that if they are implemented at the core, we’d have a game changer and browser-based apps and content would rival native apps–particularly on smaller, resource-constrained devices.