So is Prism dead in the water? It has one clear advantage over Chrome, which is that it runs on Linux and Mac. (I’ll be ranting more about that tomorrow.) Also, Prism has a lot of cool bells and whistles (tray icons and menus, popup alerts, etc.). Google’s approach is better integrated with the browser, but there is a Firefox extension that accomplishes essentially the same thing. (And yes, I really must update it to work with Firefox 3.0.1.)

The main advantage of Chrome is that its architecture was conceived in advance to provide Prism-like functionality. One of the biggest challenges with Prism has been to bring its functionality up to the level of a modern web browser. Rendering web pages is a no brainer for any XULRunner application, but people have come to expect much more from a browser. There is a whole slew of bugs filed for Prism for everything from type-ahead find to proxy and security certification management.

The problem, in a nutshell, is the current dichotomy in the Mozilla platform between XULRunner, which offers all the nuts-and-bolts to build a browser-like app, and Firefox, which is a specific browser implementation. Ideally there would be an intermediate layer which gives you a complete browser without all the Firefox-specific stuff. From my perspective, the only thing that should be specific to Firefox is the user interface.

Rearchitecting Firefox in this way would be a massive effort, of course. (Consider the difficulty just getting tab browsing implemented in a way that lets different browsers use a common implementation.) In the meantime, a solution might be to base Prism on Firefox instead of XULRunner. In this way, we would get all the browser functionality for free. The problem is then flipped on its head, since we would need to find a way to hide anything Firefox-specific (including most of the user interface). Considering the ambitious improvements the Mozilla platform has benefited from recently, a restructuring of the browser functionality is perhaps not out of the question. However, moving Prism onto Firefox (something we’ve already discussed) is doubtless a more expedient approach that would immediately bring Prism up to the level of Chrome web apps (but with all the advantages mentioned earlier).

Another issue is that it is still too difficult to add the bells and whistles to Prism apps that make them really shine. We need more documentation and examples (something that has been on my to do list for far too long). Ideally, we would have a library of ready-made customizations for popular web apps that users could access directly, similiar to the library of scripts available for Greasmonkey. Chrome certainly doesn’t render Prism obsolete, but it does make it clearer how much work we still have to do.

A Google browser has been rumored for as a long as there have been rumors. Well, not quite that long, but reckoned in internet years it’s been a near eternity since the first whisperings of a “gBrowser”. Back in January I speculated that Gears had subsumed the role that a fully-fledged browser might have filled:

Remember the rumored GBrowser? Well it looks like Google decided instead to build a stack of web application-focused services that run in a range of browsers using plugins or ActiveX. After all, why buy the cow when you can have the milk from all the cows for free? From where I’m sitting this was a very smart decision. Even Google doesn’t have the market power to impose a new browser brand on the world, so supporting third-party browsers is a reality that it has done well to embrace.

Oops, I got that one wrong. Google 1, Gertner 0.

That said, I retain my scepticism regarding the imposition of a new browser brand. The signature feature of the browser market is that every new personal computer comes with a pretty decent browser pre-installed, so third-party vendors are fighting over the scraps that Microsoft and Apple leave on the table. The genius of Firefox has been its ability, through high-quality engineering and equally impressive marketing, to carve out significant market share despite this. It is far from clear that “even Google” (to echo the language of my January post) will succeed in doing the same. And if it does, I can’t help but think that this would be bad news for Firefox. This town, so to speak, ain’t big enough for the two of us, sandwiched as it is between the Microsoft and Macintosh metropolises.

The good news is that the browser space, already in the throes of a Golden Age of innovation thanks to WebKit, is going to heat up even more. As Mozilla honcho John Lilly puts it:

Competition often results in innovation of one sort or another — in the browser you can see that this is true in spades this year, with huge Javascript performance increases, security process advances, and user interface breakthroughs. I’d expect that to continue now that Google has thrown their hat in the ring.

Mozilla makes a lot of the fact that Firefox single-handledly forced Internet Explorer to end its years-long stagnation. Justifiably so, and now WebKit and Google appear to be returning the favor. Firefox has made great strides recently in performance and memory consumption, and a long-overdue Mozilla Mobile effort is now in full swing. Increased competition has been a significant factor in acclerating these efforts.

So what about Google Chrome? It’s a no-brainer for Browser of the Week as soon as it’s available for download (later today, supposedly). In the meantime, the only source of detailed information is a sprawling technical treatise-cum-comic book. As an attempt to make dense discussion of process isolation, test-driven design, hidden class transitions and the Biba integrity model more palatable by surrounding it with fun and friendly illustrations of Google engineers, the comic is not entirely unsuccessful. Not that Joe Sixpack will be particularly impressed, I don’t suppose, but it’s a cute way to communicate the key aspects of the browser’s technical architecture and user interface. (But please, please provide a single scrolling page next time.)

I didn’t see much in the Chrome technical overview that is truly new. A big deal is made of the fact that each tab is isolated in its own operating system process, but IE8 already does this. Chrome uses the location bar to provide easy access to previously visited sites, which would be more impressive if Firefox 3 hadn’t already launched with the aptly named Awesome Bar. The JavaScript virtual machine with just-in-time compilation and fancy-optimization-tricks-that-I-don’t-really-understand sounds a lot like the Tamarin virtual machine (with equally fancy and, to me, incomprehensible optimization tricks) donated to Mozilla by Adobe. Displaying something useful in newly opened tabs has long been a feature of Opera and was mooted the other day as a possible addition to Firefox by Aza Raskin.

No single browser has actually implemented and released all of the above-mentioned features, and Chrome could be pretty kick-ass if they pull it all off. But it’s hard to shake the feeling that it would have been a heck of a lot more ground-breaking if it had been released a year ago, before Firefox 3 and the endless string of IE8 betas. Considering the daunting challenge of getting users to switch browsers, this could prove to be of crucial importance.

To me, the most interesting question is also the most fundamental: is tab process isolation the future of web browser architectures? Michael Arrington speculates that Google Chrome is a shot across Microsoft’s bow, not an entirely absurd notion. The idea of the browser user interface replacing the operating system desktop has been kicking around since the days of Netscape. I was a proponent of this approach for a long time, but since starting to work on Prism I’m come around to the view that modern desktops are unlikely to be dethroned any time soon.

The fact of the matter is that web browsers are doing double duty nowadays, filling their traditional role of rendering textual pages while hosting applications of ever increasing complexity. Browsers are pretty great for browsing documents, and HTML/JS/Flash-based applications delivered over HTTP have proven to be a great alternative to traditional fat client software. But it’s far from obvious to me that the browser chrome is the best place to deliver web apps. Just because web standards provide an array of compelling advantages for app developers, this doesn’t mean that these apps aren’t best hosted in a modern desktop GUI.

This may turn out to be the key to Chrome’s eventual success or failure. Hopefully one of the major browser manufacturers puts its full weight behind a single-site browser offering, and we will be able to witness the two approaches duke it out in the marketplace. (Gosh, I hope my agenda isn’t too transparent!) Unsurprisingly I put my money on SSBs, but either way it will be fun to watch the fireworks.

The other day Todd Ditchendorf (aka Mr. Fluid) tweeted the scope of this single-site browsing ambitions:

My goal is to remove any reason for someone to prefer Safari over a Fluid SSB for general browsing due to a missing feature. Getting there…

Then Mark Finkle gave in to mounting pressure from the ruthless Prism user community and landed a patch to add “basic browsing buttons” (i.e. back, forward and the like) in an optional toolbar. This comes on top of an ongoing struggle to get a preferences dialog into the product since Firefox’s version is not part of the platform. User requests continue to stream in for things like a user interface for configuring proxies and browsing in multiple tabs (a gotcha because the tab browser control is also specific to Firefox). From what I’ve heard, building a usable browser on top of WebKit is at least as onerous, requiring the implementor to reinvent the finer points of the browser’s user interface and high-level functionality one painstaking line of code at a time.

Any preconceptions about where the underlying platform ends and the actual browser begins are likely to be confounded immediately by some unanticipated real-world use case. Future browser architectures should simply do away with the issue altogether by making the entire codebase reusable, right up the finer details of the user interface. Deploying something like an SSB should require an hour or two of tweaking, not weeks or months of intense development.

Some might argue that SSBs are an exception because, for all intents and purposes, they are just normal browsers that happen to restrict which sites you can visit (and do away with some of the UI elements made unnecessary by these constraints). But we didn’t anticipated the idea of an SSB when today’s generation of browser architectures were conceived, so what reason do we have to assume that we are able now to foresee what the future of browsing might bring?

My conclusion:

AIR has the full weight of Adobe behind it, great tool support and a lot of mindshare in the web space. If enough vendors are convinced by its advantages and decide to use it to create desktop-enabled versions of their web apps, it may be hard for the other SSBs to compete. API standardization will be key in determining how things pan out. A common, well-designed API for single-site browsers would even make it realistic for vendors to integrate desktop-oriented code directly into their web apps. If this were to happen then loading an application like Gmail or Flickr into Bubbles, Fluid or Prism would give you all those fancy dock menus, popup notifications and the like with no customization required at all. Considering that users are increasingly leery of downloading and installing standalone apps, this would be a compelling advantage indeed.

Note: The link to my script customizing Bubbles for use with TechCrunch isn’t online yet in the main article. I’ve posted it here for those who are interested in taking a look.

Immediately, problems with running a tool so vital to my work inside my normal Firefox instance became apparent. Not insignificantly, I had to right-click on the Firefox dock icon and select the right window every time I wanted to call up the timer. When you’re doing something potentially dozens of times a day, every little bit of superfluous effort starts to get on your nerves. More importantly, I sometimes restart Firefox, which causes the timer to stop (costing me money, or at least mental effort as I try to reconstruct my hours forensically after the fact).

Today it dawned on me that I should serve myself a heaping portion of my tasty dog food, so I fired up Prism and entered the SlimTimer URL. Maybe it ain’t rocket science, but a minute later it was running as a standalone application in its own process. This means that it can be accessed with a single click on the dock icon (even when it isn’t running since I’ve configured it to leave the icon in the dock).

I’m biased, of course, so let me make it clear that similar products like Fluid and Bubbles would doubtless yield the same results. But anyone who says that single-site browsers are just like other web browsers with a bunch of useful stuff stripped out are plain wrong. For web apps that you use a lot, this type of desktop integration is of great value. My next task is to implement a dock badge that shows me state of the timer for the active task, in real time (which should involve nothing more than a short snippet of JavaScript).

It’s extremely early days for all of these products. I wouldn’t recommend any of them for use by mainstream users, but if you’re technically minded enough to be reading this you’re definitely a good candidate to take a look at them in their current form. By the end of the year, I expect them to have matured considerably. Soon enough we won’t know how we got along without them.

This might have been overly pessimistic. Only a month has passed since I wrote these lines, and already Matt Asay is reporting that Zimbra (recently acquired by Yahoo) is shipping a desktop version of its web-based email client using Prism. Mark Finkle, the Mozilla employee in charge of Prism development, provides his own thoughts on the announcement, including a run-down of its latest and greatest features.

[Author’s note: I am a contributor to Prism.]

As Mark points out, adding desktop-like capabilities to web apps entails certain challenges:

You’ll notice that we want to create ways for webapps to manipulate some of the desktop-enabling features (dock badging and systray support for example). We don’t want to create custom, Prism-only APIs to access these features. We’re looking for feedback and discussions on how webapps can support these kinds of features without breaking when running in traditional browsers.

He goes on to ask for specifications for site-specific browser extensions to be standardized under the aegis of the WHATWG. In my opinion, it’s a bit early to be launching a formal standards effort, but there’s certainly no harm in vendors getting together and comparing notes. One particularly intriguing question is what additional features could meaningfully be added to products like Prism to make web apps more competitive with their desktop brethren. Some, like offline storage, are being added to traditional browsers anyway. Are there features that only make sense for an application that is running in its own process?

Remember the rumored GBrowser? Well it looks like Google decided instead to build a stack of web application-focused services that run in a range of browsers using plugins or ActiveX. After all, why buy the cow when you can have the milk from all the cows for free? From where I’m sitting this was a very smart decision. Even Google doesn’t have the market power to impose a new browser brand on the world, so supporting third-party browsers is a reality that it has done well to embrace.

Most significant may be the mooted Desktop Shortcut API. Right now this creates a shortcut that runs in the browser that created it, but it’s not too much of a stretch to imagine it launching a standalone browsing process of some sort in the future. This would put Google smack dab in the middle of the site-specific browser game. Note also that the createShortcut function is attached to a Desktop class which is positively screaming to be the beneficiary of new desktop integration functionality in the future.

Does this mean that Google is rejecting nascent web standards like those of the WHAT WG? Someone pointed out to me that Ian Hickson, the brains behind WHAT WG and the Acid web compatibility tests, is a Google employee. You can hardly blame them for forging their own path, however, considering the frustration inherent in most standardization efforts. My guess is that they’re planning to fold their work into WHAT WG at some point in the future, but they don’t want that to slow them down.

Personal computing is currently in a state of transition. While traditionally users have interacted mostly with desktop applications, more and more of them are using web applications. But the latter often fit awkwardly into the document-centric interface of web browsers. And they are surrounded with controls–like back and forward buttons and a location bar–that have nothing to do with interacting with the application itself.

[Author's note: I am a contributor to Prism.]

The reality is that the current generation of web apps are trying to shove a square peg into a round hole. The fact that they’ve managed to jam it in there as far as they have is a testament to the ingenuity of the software developers involved, but it’s not a particularly satisfying solution. One possibility would be to address this by adding more and more application-oriented features to the web browser. But why bother when many years and countless investment in R&D have led to modern operating systems like Windows and OS X that already give us everything we need?

There are a number of other reasons to prefer running a web app on the desktop rather than in the browser. By giving it its own operating system process, you isolate it from other applications. If it locks up or crashes, it doesn’t bring down the whole browser. You can use all the fancy docks and taskbars that the operating system provides to gain easy access to your applications. You can use tools like the Windows Task Manager to see how much memory and CPU power it is consuming. Once again, we could theoretically add these capabilities to existing web browsers, but the effort would be massive. Clearly the idea of fusing web apps with the desktop is a promising one.

The other main contender (besides Prism) in what have come to be known as site-specific browsers is Adobe AIR. Both products integrate a standalone browser engine (Gecko in the case of Mozilla and WebKit in the case of AIR). Both support SQLite so you can store application data locally. In other respects, however, the products are quite different.

The aim of Prism is to provide the aforementioned benefits to web developers with minimal effort on their part. In fact, you can run existing applications in Prism without any modification at all. In the future, developers will be able to write special configuration files that adapt the application to make it fit more comfortably into the desktop paradigm, adding things like a menu bar, drag-and-drop capabilities and popup notifications.

AIR is more about getting Flex, which lets developers write Flash applications using markup similar to HTML (and even more similar to Mozilla’s XUL), to run on the desktop. The product does support HTML as well, but the clear focus is on all-singing, all-dancing Flex-based user interfaces.

This distinction has already led to a minor skirmish between the principal actors. Mozilla’s Prism blog post claims that “unlike Adobe AIR and Microsoft Silverlight, we’re not building a proprietary platform to replace the web.” In the comments, Adobe’s Mike Chambers takes offense:

Adobe AIR is built on top of web standards and can run existing web applications and content. It runs on Windows and Mac (and soon Linux), and it also provides additional desktop functionality.

This is correct but somewhat disingenuous. It’s no coincidence that Adobe is showcasing an array of slick-looking Flex-based applications while Mozilla is touting its support for web stalwarts like Gmail, Facebook and Meebo. This doesn’t mean that one is bad and the other is good. Blind adherence to standards is not always the best way to drive innovation, and it’s hard to deny the visual appeal of Flash when compared with plain-jane HTML. Some canny moves on Adobe’s part might even lead to Flex becoming a standard in its own right.

There are other players entering this space, notably Fluid, which currently runs only on Mac OS 10.5 (Leopard). It’s also worth keeping an eye on Google Gears. Originally announced as a way to let web apps function without a live internet connection, it is being extended to support features like placing a shortcut to the application on the desktop. The implication is that Gears will evolve into a direct competitor to Prism, AIR and Fluid.

It’s extremely early days for all of these products. I wouldn’t recommend any of them for use by mainstream users, but if you’re technically minded enough to be reading this you’re definitely a good candidate to take a look at them in their current form. By the end of the year, I expect them to have matured considerably. Soon enough we won’t know how we got along without them.