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.

If web applications liberated us from the domination of a single company on the desktop, why would we be eager to be dominated by a different company on the web? Yet, this is what Adobe would have us do, as would the many who are (understandably, along some dimensions, anyway) excited about Flex? Read Anne Zelenka’s post on Open Flash if you don’t think that Flash has an openness problem. I’m not eager to go from being beholden to Microsoft to being beholden to Adobe.

Ted’s thesis is echoed by many proponents of the “open web”. Microsoft has had a huge influence on this way of thinking both because they were so dominant for so long and because they abused this dominance in so many unappealing ways. The web has finally liberated us from Windows bondage, and naturally we are in no hurry to find ourselves locked once again into a proprietary environment.

Nevertheless, there is a worrying tendency to promote the open web for its own sake as well as for the real advantages that it brings. This is particular true among the open source software crowd, which sometimes treats openness with a quasi-religious reverence that ignores the many benefits of the proprietary approach. Since nothing should be accepted on faith alone, let’s explore some counterarguments to the “open is good, closed is bad” doctrine.

First of all, Microsoft’s hegemony in the 80′s and 90′s was an aberration. It stemmed from a lock on distribution (through OEM agreements with hardware manufacturers) and a lack of plausible competition at the platform level. This gave Microsoft exceptional market power, which it duly abused. None of this is applicable to vendors like Adobe. People use Flash because there are compelling applications built on top of it, not because it was pre-installed on their computer when they bought it. And Adobe will be hard-pressed to take undue advantage of its technology’s popularity since we can always fall back on healthy competitive alternatives (both open and closed).

And the flip side of the open vs. closed debate is that proprietary approaches can be instrumental in advancing innovation. This was even true of Microsoft, who arguably accelerated the widespread adoption of personal computers by providing a much-needed uniform platform (a standard, if you will) for independent software vendors. Of course, many will counter that open ecosystems are most conducive to innovation, as in the piece by Anne Zelenka cited above:

Decentralized, emergent development models work better than central planning for broadly applicable technologies like Flash. Why? Because the people who might come up with the next great enhancement to Flash may not be within Adobe. Flash is a foundational technology for Internet development–because of its broad use, it should have an equally broad community evolving it for the future.

[...]

It is a bit akin to the difference between a centrally planned and a market economy. In the centrally planned economy, the oligarchs and eggheads who make decisions think they know better than what the aggregation of individual decisions might come up with. In fact, market economies beat centrally planned ones over and over again. You have a certain dynamism in market economics that’s not present in centrally planned one. The same goes for the development of technology.

Seen from the perspective of Flash, this is doubtless the case. But with respect to the broader web, the market vs. centralized planning argument takes on a different dynamic. In order to benefit from the Darwinian principles that Anne evokes we want as many parties as possible in the fray, duking it out for dominance. One of the most powerful forces in real markets in the profit motive, and it is naive to think that this consideration evaporates just because we are talking about software and the web. In other words, letting companies deploy their proprietary technologies and fight for profits will enrich the web by offering more and more compelling alternatives.

This may be anathema to some, but a level-headed look at what Adobe has accomplished reveals much to evoke envy in its open counterparts. Flash runs uniformly on all platforms, unlike Ajax (which still requires much tweaking and tailoring depending on the operating system and browser being used). Its interfaces are beautiful, sometimes jaw-droppingly so. While the open crew are still hashing out standards for video on the web, Flash video has crushed the competition and enabled a generation of popular video sites like YouTube.

Mozilla CTO Brendan Eich made an interesting point about Flash and other closed formats:

I assert that there is something wrong with web-like “rich” formats that aren’t hyperlink-able or indexable by search-engines. You could argue that these bugs could be fixed, and Flash is wisely becoming more URI-addressable and view-source-able over time. But it still ain’t the Web. It is not hand-authored, easily tweaked incrementally, copy-and-paste-able. It’s hardware.

Well I would assert that some hardware-like characteristics would do the web (and computing in general) a great deal of good. We’re leaving the last vestiges of the hobbyist era behind us. If normal people are to get full benefit from the web, it has to be as easy to use as a refrigerator or toaster. Is it really a bad thing if Adobe and others like it are bringing us closer to this state of affairs?

The biggest advantage that AIR has, though, is Flash Player 9’s near 97% penetration rate. In addition, rumor has it that Adobe will issue an update to the Flash player that would include the AIR runtime making it a highly desirable target for building new applications. We’ll have to see if the rumor holds true.

Unfortunately, when I went to grab the link and milk it for maximum gloating potential, it had been amended:

Update: Adobe’s Rob Christensen has sent me an update letting me know that Adobe has no plans at this time to bundle AIR with the Flash Player. One of the primary goals of the Flash Player is to keep the download size as small [as possible] so that they can continue adding powerful features like h.264. Thanks for the update Rob.

Why do I have a funny feeling I know who started that rumor? (I should mention that the bet specifically mentioned a contingency where Adobe would provide an AIR stub in Flash that would download the rest of the runtime when needed, which would mitigate the footprint issue that Rob cites. I’m not ready to make a down payment on a new apartment just yet, but I remain hopeful.)

Update: In the comments, Enefekt points out the Adobe has a pretty convincing deployment story already. I’m not sure whether this qualifies as “providing an AIR stub in Flash”, but I hope it does, because with this solution in place I’m not sure that Adobe will feel the need to integrate the AIR runtime more deeply into Flash.

This comment was made to me by Benjamin Smedberg, who is the driving force behind XULRunner, Mozilla’s platform for building portable, web-enabled applications. Obviously the remark is largely tongue-in-cheek (and in fact “measly stub” was my own joking characterization), but there is a kernel of truth to what he says. To understand why, some background is in order.

The original architects of Firefox were impressively visionary in building their browser on top of a general-purpose framework that has helped them to manage the complexity of deploying a sophisticated product on dozens of different operating systems. This platform is so powerful that other companies have decided to build their own applications on top of it. Prominent examples are Songbird, Joost and Miro. Benjamin has done a great deal of work to take what used to be the pile of stuff that makes Firefox tick and turn it into a product in its own right: XULRunner.

The current confusion has stems from a blog post written by then CEO Mitchell Baker last May. In her defense, Mitchell devotes the vast bulk of the piece to explaining that Mozilla is planning to continue supporting XULRunner in a variety of ways, particularly as the foundation for Firefox and as a platform that other software developers can use for their own apps. But many seem to have latched onto the last section, where she says that “the Mozilla Foundation does not plan to invest in a pre-packaged or stand-alone XULRunner at this time.” In the game of telephone that is the technology press, this was apparently communicated as “we’re discontinuing XULRunner”.

In reality, nothing could be further from the truth. Benjamin is referring to what is doubtless the least understood but most significant of many exciting innovations in Firefox 3. Previous versions of Firefox used the XULRunner source code but couldn’t share it with other apps at runtime. The upcoming version ships with a complete XULRunner runtime, and actually lets you turn Firefox into XULRunner with a simple command line switch.

This is important because the browser wars are evolving into runtime wars. Players like Adobe and Microsoft are trying to convince software developers to build on top of their RIA platforms (AIR and .NET/Silverlight, respectively). Programmers are understandably wary of doing so if users will have to download a hulking runtime just to use their applications. This is one of the key factors that has prevented Java and previous incarnations of .NET from gaining widespread penetration on the desktop.

The only company that’s been really successful thus far in getting its runtime onto users’ desktops is Adobe, whose Flash player has achieved something approaching ubiquity. It’s a safe bet that they are planning to leverage this installed base to push the AIR runtime, and in fact I made precisely this bet with another Mozillian, Mike Shaver, who will be paying me 100 euros if Adobe finds a way before the end of 2008 to sneak AIR onto surfers’ machines when they upgrade to a newer version of Flash. (And if anyone from Adobe is reading this, there’s 50 euros in it for you if you can make this happen.)

The player with the strongest cards, however, is Mozilla. Unlike Adobe and Microsoft, they have a true killer app in the form of Firefox. When its 150 million odd users upgrade to Firefox 3, they’ll be getting XULRunner as a surprise bonus. This will seed the market and make it a whole whack easier for software developers to deploy XULRunner-based applications. Right now people are focused on the “awesome bar“, a slimmer waistline and other cool new additions planned for Firefox 3, but the platform it conceals under the hood may turn out to have the most revolutionary impact.

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.

As web apps have continued to encroach on what was previously the sole realm of the desktop, the “airplane problem” has become increasingly evident. Although Ajax applications actually download their code onto the client before running it, they are still impossible to use if you’re not connected to the internet. In part this is because browsers don’t yet have the smarts to hold on to code that might be needed later. Leave your Gmail inbox and you won’t to be able to get it back without a live net connection. Moreover, you wouldn’t be able to do anything interesting anyway since all of your data is stored on some remote server and thus inaccessible when you’re offline.

The iPhone is a poignant illustration of this problem. When Apple announced that Safari would be the SDK for its new phone, industry observers were skeptical. Although the central theme of this blog is that the distinction between web apps and their desktop-based counterparts is eroding, Safari is simply not yet up to the task. One of the main lacks is the need to be online to use third-party web apps. There are many instances when this is impossible or inconvenient: on airplanes, as mentioned, but also when roaming, when you don’t have an unlimited data plan (you dirty hacker you) or any time you’re away from a wifi connection and have to rely on the glacial EDGE network.

Mozilla began tackling the problem at the beginning of 2007. Browsers already store JavaScript downloaded from web sites in their cache to speed subsequent loading of these sites, but not in a way that makes it usable when offline. What is needed is a persistent cache specifically designed for this purpose. The new functionality, which is based on a specification being fleshed out inside the WHATWG, is slated to be included in Firefox 3. Complex applications like Zimbra have already been adapted to take advantage of it. According to Ars Technica, Apple is “jamming on adding offline storage capabilities to Safari” for use on the iPhone. Since Apple is an active participant in the WHATWG, it’s reasonable to expect that their implementation will be compatible with Mozilla’s from the perspective of web developers.

The other contender is Google Gears, which also provides capabilities for storing code and data locally for use without internet access. Google has a couple of advantages over the WHATWG. For one thing, it controls some of the most popular Ajax applications on earth. Also, Gears is distributed as a browser plugin and supports Internet Explorer as well as Firefox (with Safari support on the way). This gives Google end-to-end control analogous to that enjoyed by Apple with iTunes (both the music store and the client) and the iPod. The WHATWG crowd has to convince web application developers to support its specification, and it has to deal with the fact that IE users are currently out in the cold.

So where is Microsoft in this story anyway? I couldn’t find any indication that they have offline capabilities at all, existing or planned. I suspect we may be in for a big surprise announcement when IE 8 is released this year. Perhaps they are even planning to support the WHATWG spec. That would be a real shocker but might make sense if they perceive their real rival in this game to be Google rather than Mozilla or Apple.

No discussion of offline capabilities for browsers would be complete without mentioning SQLite. Every solution in this space has one thing in common: they all use this small, fast, reliable embedded SQL database. Adobe has also adopted it for use in AIR, its platform for standalone web apps. It’s safe to say that SQLite has accelerated the rollout of offline-capable browsers by at least a year or two. It also has some of the most liberal licensing terms out there. D. Richard Hipp, its creator, is a genuine tech hero.

Next time in browser trends we’ll explore the rise of site-specific browsers and rich internet applications.