In for a penny, in for a pound.
So I dug around in Apollo a little bit, and I did a little bit more thinking about my reflexive dismissal of the technology. And I admit to misunderstanding and miscategorizing Apollo. Here’s what I learned.
Apollo is not a browser plugin, nor does it leverage or extend your browser in any way. It runs completely outside the browser. It is a run-time environment for building cross-platform desktop applications. It contains an HTML rendering engine (coutesy of WebKit), JavaScript and ActionScript engines, a Flash player and numerous other components. Developing for Apollo is allegedly easier than developing towards other desktop environments, and that’s probably true.
An exercise in positioning Apollo
Lets say you want to build a RSS/Atom reader. I’m using a news reader as an example because it divorces the client from the server. In other words, the server is as Web-ish as you want. However, you can pretend that you’re developing any old app, even—especially—business apps.
If you were targeting a single desktop environment, say Windows XP, you might choose to use the native development environment, .NET. Or maybe C++. But lets add a requirement: my news reader must be cross-platform. That eliminates .NET as a development platform, but still leaves C++. However, with C++ I have to carefully separate my common functionality from my OS-specific functionality and become more of an expert on OS and windowing quirks then I would like, so that’s out. Fortunately, there’s quite a few other ways to go:
- Browser based
- Java based
- Dynamic language based: Perl, Python, Ruby, Tcl
- Native cross-platform development environment, e.g Qt
- Apollo
- Others, e.g. Eclipse RCP
All of these have pros and cons. Browsers are limited in functionality, and quirky. Java is a pain to develop towards-especially GUI apps, has spotty HTML rendering ability, and a non-native look and feel. The dynamic languages are far from guaranteed to be installed on any particular machine—especially Windows machines, and (likely) also have their own look and feel issues. Qt still leaves me in C++ land; that is it’s hard to develop towards. Apollo also has its own look and feel, and will require a download of the runtime environment if it’s not already there (I’m ignoring its alpha release state). I don’t care about any others cross-platform techniques right now.
If we add another requirement: time to market (aka ease of development), we can eliminate Java and Qt (and its ilk). Adding one more: end user experience (ease of installation, richness) gets rid of the dynamic languages.
That leaves us with the browser and Apollo. Now lets add one more requirement: off-line mode. It’s an absolute requirement that my users be able to read feeds when disconnected from the Internet. And that’s it, Apollo is the only reasonable choice for me given my constraints.
Does that officially put Apollo in my good graces. Well, yeah, I guess it does. But that’s not to say that I don’t have reservations. For one thing, in the real world I would weigh off-line access (to pick an Apollo feature not available in browsers) very carefully against ubiquitous access. Even imagining a world where Apollo is widely deployed, it will never be as universally deployed as a browser. There will most likely never be a Win2K version, and I can imagine a large number of Linux desktop environements will be left out in the cold. Let alone other Unixes, BSDs, and so on. Moreover, even for supported OSs I think it’ll be a crapshoot as to whether Apollo’s installed or not. Right now, I can be sitting at any one of four different operating systems on six different computers without leaving my house. What are the odds, then, that I will find Apollo installed on my friend’s computer, on my client’s computer, on my phone, at the library. Even imagining 100% deployment on every machine I sit down in front of, there’s still the need to download the Apollo app locally, which I would be reluctant to do, assuming I was allowed.
That said, Apollo is probably not targeting the kind of application that the peripatetic user might need. They are more likely targeting the corporate user on a locked-down PC. This is certainly much more reasonable, but I would still be hesitant to develop Apollo applications for this environment. Why? Things change. Will Apollo be around forever? Will its release and support schedule match my retirement/upgrade schedule. Not too long ago a corporate developer could safely (if unwisely) assume that using IE specific features and quirks was fine, after all everyone in the company uses Windows and IE is the corporate browser. Now, of course, that’s coming back to bite them. The kids in IT are all using Linux (and three different flavors) and OS X, all the creatives and a handful of VIPs are using OS X too, and 20% of the company ditched IE for Firefox despite corporate policy.
The long and the short of it is this: I would develop Apollo applications if, and only if, my application was deployed inside the firewall and I had a set-in-stone requirement that could not be met by a browser-based app. But, again, that’s just me. YMMV.
My apologies to Adobe. Next up: Silverlight.
{ 9 } Comments
Excellent follow up. Thanks for taking the time to investigate and summarize - saves me the time!
I think it should be pointed out that one of the key differences with Apollo is the ease with which desktop applications can be developed in comparison with the other paradigms discussed. It is not an exaggeration to say that a useful Apollo application, whether targeted for a locked down, firewalled environment, or on a wide-open computer, can be built with nothing more than HTML, CSS, Javascript, and a few easy to understand, Apollo specific commands.
What got me so excited about Apollo to the point where I formed a website to try to assist people developing with Apollo (ApolloApps.com) wasn’t so much the capabilities or implications of desktop-based apps, but the ease with which they can be deployed in comparison to some of the other technologies you identified, all of which are much less accessible to the non-programmer.
I believe this ease of development will increase the volume of developers and hopefully will accelerate the ubiquity of the runtime. It should be noted that it seems from an outsiders perspective that some of the same people from Macromedia/Adobe responsible for getting the Flash Player installed on over 98% of the world’s computers are also behind the Apollo project.
This is a very cool writeup Pete, and it’s good to see more people “get it”.
=Ryan
Adobe Evangelist
Ru kidding me? “The dynamic languages are far from guaranteed to be installed on any particular machine—especially Windows machines”
How many machines is Apollo installed on now?
L&F is given far too much weight…if it truly mattered, then web apps wouldn’t look vastly different then for ex say Office. Tell me what L&F reminds you of Facebook?
“(…) built with nothing more than HTML, CSS, Javascript, (…)”
You mean, just like a web browser application?
“(…) and a few easy to understand, Apollo specific commands (…)”
Not quite. Because it will depend on Adobe’s proprietary runtime environment.
Given how Adobe Acrobat Reader morphed from a utility into a bug-laden monster, I’ll stay with web standards, thank you!
And if somebody ask a standalone executable decoupled from the browser, there’s a stable and open source XUL runner, free as in free beer *and* free speech.
“Ryan: Adobe Evangelist”
Ah … kind of explains why a Zeepe-ish link sent to to Ryan on his ZDNet blog:
http://www.zeepe.com/zeepeinfo/scottgu.asp
fell into such a deep dark hole.
The benefits of Apollo go beyond off line ability. The real advantage is access to your computer.
Something like a web browser for example can’t put icons in the notification area next to the clock. An Apollo RSS reader could use native notifications to tell the user when new feeds are available.
An even bigger advantage is true cross platform development. Imagine writing a program that can target Windows, Linux, Mac OSX (via Apollo), and the web browser (via Flash). The same code base can run directly in the browser on Flash or on the desktop using Apollo.
Imagine writing an mp3 player - when I’m at work I want to be able to listen to streaming music, but when I’m at home I want to listen to both streaming music and my own collection. It would be a huge security hole if Javascript or Flash in the browser could access the files on my desktop, but a stand alone desktop application running on the Apollo runtime has no such weakness. So the developers of this mp3 player can use the same code and write an mp3 player that works in the browser as well on the desktop with additional functionality like access to the filesystem, and non-rectangular or transparent windows. See http://www.finetune.com.
My biggest concern with Apollo is the breadth of deployment of the runtime.
However, I suspect that Adobe will have a solution for that.
I wouldnt be surprised if Flash 10 had the Apollo runtime built in. Flash 9 has good penetration, so I would be happy with that scenario.
http://www.adobe.com/products/player_census/flashplayer/version_penetration.html
I’m curious why Eclipse RCP didn’t make the cut for intranet biz apps. The following reasons don’t apply AFAICT (except maybe spotty html rendinging–not sure on that one):
“Java is a pain to develop towards-especially GUI apps, has spotty HTML rendering ability, and a non-native look and feel.”
Possibly the only reason would be getting up the RCP learning curve, but I know of nothing that indicates it would be any worse than Apollo. And I have seen some impressive productivity by non-experts compared to development with web technologies.
{ 3 } Trackbacks
[...] 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. [...]
Behind the stonewall…
Pete Lacey: “I would develop Apollo applications if, and only if, my application was deployed inside the firewall and I had a set-in-stone requirement that could not be met by a browser-based app. But, again, that’s just me. YMMV.” For……
Silverlight understanding…
Silverlight understanding: BBC has an article here describing the late-May view of Microsoft’s push into browser plugins. They pick up that the big win is in enabling .NET shops to do those Flash-y types of sites they’ve seen, but I think they get it…
Post a Comment