The Web Browser is Dead. Or Pregnant. Or Something.

In August, Wired published an article entitled "The Web Is Dead. Long Live the Internet", along with a companion piece "The Web Is Dead? A Debate". (The latter benefits from the participation of Tim O'Reilly, whose vision of the internet's future is as insightful as any I've seen.) The provocative title, predictably, engendered a lively debate in the blogosphere, mostly refuting the article's thesis and/or objecting to its overly dramatic tone.

In a nutshell, the Wired article postulates that the open web is being replaced by closed applications that offer a better user experience ("blame us") and better opportunities for monetization ("blame them"). The negative reaction stems mainly from the visceral attachment that techies have to openness as a general philosophy (witness, as one example, the ability of four college students to raise over $100,000 in a couple of weeks on the basis of a woolly -- and utterly implausible -- plan to create an open alternative to Facebook). The idea that the web might be replaced by something that looks more like traditional media, with a bunch of clueless lawyers and MBAs overcharging us for apps and content while imposing annoying restrictions on how we use them, is enough to get the tech crowd steaming. Wired's overblown rhetoric and sometimes half-baked logic (how can Facebook be an example of the web's demise when it is first and foremost a website?) seems designed to evoke exactly this reaction.

Nonetheless, the notion that we are witnessing a fundamental change in the way we access, use and consume content and applications is more than just cynical linkbait. There are, in fact, three overarching trends that deserve our attention: the shift from open to closed ecosystems, the use of non-web protocols and languages for internet development and the replacement of the web browser with single-purpose user agents (a.k.a. "apps"). These trends are both separate and deeply interconnected, and the biggest weakness of Wired's treatment lies in the choice to conflate them into one big Web vs. Not Web dichotomy. I plan to write about each of these trends, but since this is a blog about web browsers I'll tackle the last one first.

It is accepted wisdom nowadays that native apps are replacing websites as the way people access remote databases, consume content and pull software onto their computers. In this view, the rise of the web app was just a transitional phase. Bulky desktop apps with limited connectivity were defenseless when faced with lightweight web apps that live natively in the cloud. But it turned out that the latter had drawbacks of their own: high latency, limited access to local hardware, poor integration with desktop eye candy and a dearth of decent development tools. These problems were particularly evident on the nascent iOS platform. When Steve Job claimed in 2007 that the web would be the way to get third-party apps onto the iPhone, he was either being stupid or he was trying to obfuscate Apple's plans for a true SDK (hint: he wasn't being stupid). Loading a web browser and rendering HTML in order to, say, check your stock quotes or Facebook feed was slow and laborious. Web apps didn't have access to a lot of the phone's cool hardware features (accelerator, location services, camera, etc.). Like web apps on the desktop, monetization was a challenge. And did I mention that the development tools sucked?

So advent of iPhone apps with their polished Cocoa APIs, slick development environment and App Store for distribution and monetization was a no-brainer. Now everyone is app crazy, Apple just announced an App Store for the Mac and it's only a matter of time until the web rolls over and breathes its last breath. But there isn't any inherent reason why the web can't catch up. I find myself using websites much more on my iPad than on my iPhone 3G (and the same will probably be true for my iPhone 4 if Vodafone ever deigns to send it to me). Faster hardware makes a big difference. New web standards for things like geolocation and access to local devices are finding their way into the latest generation of web browsers. Single-site browsers like Prism and Fluid make web apps look and act just like native apps. Development tools still trail but eventually someone's going to make a killing with an IDE that makes coding for the web as easy as building an iPhone app. (Please, someone, prove me right.)

Meanwhile the notion of a native app for everything isn't all sunshine and puppy dogs either. For one thing, they eliminate a truly revolutionary advantage of web apps for developers: that you write once and they run everywhere. But even more importantly, they don't always make sense in terms of user experience. The reason that publishers are clamoring to deploy apps for reading their newspapers and magazines is not that you can't create a fabulous reading experience in a browser, but because they haven't figured out how to make enough money to compensate for their declining paper-based revenues (which really are dead). It's not surprising that they see paid apps as their Shangri-La, but do users really want to fire up a special program to read the New York Times, then open another one to read Wired and yet another to check out my latest blog post? It makes sense to have a single app for reading with a uniform user interface and set of features, including the ability to link between and perform full-text searches on different documents regardless of their provenance.

We are to blessed to have a front-row seat at the epic transformation of the media landscape. It's hard to maintain perspective, and it's tempting to see every step on the way as the end of the journey. But when the pieces finally slot into place, the web browser won't have been replaced by a bunch of single-purpose native apps. It will have given birth to a limited set of more focused browsers, based on the same core engine but designed for different tasks. It doesn't make sense to have a hulking general-purpose browser that you use for booking flights, accessing Facebook, playing games and reading the Economist. This is not, however, the fault of the browser technologies themselves. Better to spin out the actual apps into isolated processes using something like Prism, while offering a browser specifically for all reading activities, yet another for watching video while sprawled on your couch and doubtless others that I haven't thought of yet.

Seen in this light, the idea of isolating browser tabs into separate processes, currently in vogue among browser vendors, is a chimera, a vain attempt to preserve the viability of the web browser as an inseparable monolith. The right way to counter the app invasion is to embrace it by making the underlying browser platform a great way to deploy standalone apps that live in their own process. General-purpose browsers will live on, but even they will target specific types of content. There are already special browsers for watching video (Boxee, Zinc.tv, etc.), addressing the weakness of traditional browsers in that area. If it knows what's best for it, the web browser as we know it will then return to its roots as a tool for finding and reading documents, an area also ripe for improvement. For starters, how about a way to provide those poor misguided publishers with a viable business model?

Matt

Matt