Apollo’s Platform Appeal
Pete Lacey provides a fair analysis of Adobe’s Apollo. It’s a helpful post since it’s not really trying to strongly influence opinion about Apollo either way, even if it may inflame advocates of some of the technologies given somewhat gruff treatment. All told, the analysis sounds fine to me, but the development story still leaves me cold. If this is a packaged browser designed to normalize a web-based platform, are the critics morally, as well as technically, wrong for calling it a browser extension? I’m just not seeing it yet, I suppose. Ease of deployment is a worthy feature, but the Apollo deployment mechanism doesn’t seem easier than navigating to a URL in a browser. So, if it’s less easily deployed than a traditional browser-based app, it has to offer some combination of a better development story or better technology.
The technology advantage seems focused on the off-line access, a problem which sounds like it may soon be answered by the already-incorrectly-applied label of “browser extension.” There is also fairly vigorous debate about just how useful this feature is, so, by itself, it is not a killer technology feature, in my opinion. (Note: I am ready to be proved wrong on that.) The development advantage is similarly less than overwhelming. Rather than the promise of a new language, or even a new API that will streamline the typical workflows of RIA architects, we get languages and technologies we’ve seen before on top of a rationalized runtime environment. The unfortunate part about this is that platform normalization is a remarkably un-sexy feature that is actually way more important than over-inflated promises regarding new languages or libraries. Well, it’s unfortunate for Adobe, but I don’t know that such pragmatic concerns will lure developers still flush with the possibilities opened up by the eradication of replication and distribution costs.
Here’s my analogy for this situation: video game consoles (e.g. PlayStation 3, Xbox 360, Nintendo Wii) are introduced with a huge splash centering on new capabilities, but provide real, long-lasting value by defining a platform. What’s interesting about the video game console life cycle is that they gain initial adoption by providing something new, something flashy: better graphics, better sound, new controller. Such intuitively appealing benefits of the technology target consumers, whom developers rush to serve with games for the new systems. The developers, meanwhile, benefit tremendously from having compatibility testing largely eliminated when compared to PC game development. After the spark and sizzle has faded, consumers are left with a system that developers can become more and more familiar with, leading to greater resource utilization and less time spent figuring out how to get “Hello World” to run. Developers are comfortable, and consumers get games that just work as they should without any fiddling: it’s a good thing.
Apollo has the potential to be a developer-friendly environment by virtue of its stability and availability (assuming those things work out). But if the deployment is worse than a web page (i.e. the video game console costs a bit too much), and there’s nothing to grab consumer interest, what is going to drive adoption?
“If this is a packaged browser designed to normalize a web-based platform, are the critics morally, as well as technically, wrong for calling it a browser extension?”
I’m not sure.
The Adobe Flash Player runs within the various browsers, and does extend their capabilities. But the Adobe Apollo project aims to make it easy to create real desktop applications, using regular webpage development techniques.
WWW browsers are valuable because you can safely visit any page in the world. Apollo helps trusted sites gain a little more interaction with your computer… full windowing control, file system access, notifications.
Use webpage techniques to make cross-platform standalone applications, that’s what Apollo does. Sound right to you…?
jd/adobe
John, what I’m trying to get at are the specific technology advantages Apollo provides over using regular webpage development techniques to build regular webpages. I think what you refer to as “a little more interaction with your computer” needs to be a higher impact selling point for Apollo to really gain traction.
I am 100% interested in a cross-platform execution environment for creating visually rich applications. But I am questioning why I should consider Apollo over existing web browsers. That is not to suggest that Apollo is any way technologically inferior in terms of application support, quite the contrary. It is just that I have yet to be convinced that it’s advantages as a platform outweigh the negatives regarding distribution and reach when compared to traditional web development.
Apollo, for me, is currently sitting in a middle ground between the cases where I target the browser or I target the desktop, and I am struggling to identify cases where it would pull me away from either of those extremes.