When Adobe released its Apollo runtime preview last week, it described the technology as an enabler of a new class of applications that combine the best of the desktop and browser-based experience. Based on the open-source WebKit, upon which both Apple's Safari and the KDE project's Konqueror browsers are built, Apollo can be thought of as a custom Web browser: Indeed, you can write an HTML-based application and deploy that on user desktops with Apollo. In addition to HTML and JavaScript, Apollo applications can be written in Adobe's Flex language.

Adobe's Apollo project is hardly alone in offering some combination of online and offline experience: Microsoft's WPF/E (Windows Presentation Foundation Everywhere), and even the next-generation Firefox browser, promise similar functionality.

Subsequent to Apollo's initial preview release, many developers pondered in blogs and articles just what sorts of application capabilities a desktop/browser hybrid could offer, and even the point of moving things to the desktop at a time when ubiquitous high-bandwidth networking is becoming available to an increasing number of users. In an Artima discussion, for instance, Dick Ford commented that,

Apollo looks interesting from a development perspective, but I'm not sure that moving to the desktop will be all that enticing for developers.

In response to similar developer questions, Mike Chambers, an Adobe engineer, recently published an illuminating essay that goes into some detail on how offline and online experience can be combined in future applications, Why Apollo?:

Applications deployed via the browser have their own user interface, which often conflicts with the user interface of the browser. This application within an application model often results in user interfaces that conflict with and contradict each other...

Due in part to the web security model... applications that run in the browser often do not support the type of user interactions with the operating system that users expect from applications. For example, you cannot drag a file into a browser-based application and have the application act on that file. Nor can the web application interact with other applications on the user’s computer... RIAs have tried to improve on this by making richer, more desktop-like interfaces possible in the browser, but they have not been able to overcome the fundamental limitations and separation of the browser from the desktop...

As applications become richer and more complex and begin to push the boundaries of JavaScript and DHTML, developers are increasingly faced with differences in browser functionality and APIs... While JavaScript frameworks are a popular way to help address these issues, they can offer only the functionality provided by the browser, and often resort to the lowest common denominator of features between browsers to ease the development model.

Having listed some of the drawbacks of delivering applications inside a browser, Chambers also notes that:

The fact that web applications have flourished despite these drawbacks is a testament to the attractiveness of having a platform with a good development model that has the ability to deliver applications to multiple operating systems. A platform that offered the reach and development model of the browser, while providing the functionality and richness of a desktop application, would provide the best of both worlds...

What do you think Chambers' description of the browser/desktop application hybrid, and of Adobe's take on that approach?