{ 2007 05 19 }

Rethinking Apollo

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:

  1. Browser based
  2. Java based
  3. Dynamic language based: Perl, Python, Ruby, Tcl
  4. Native cross-platform development environment, e.g Qt
  5. Apollo
  6. 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.

Posted by Pete on Saturday, May 19th, 2007, at 4:57 pm, and filed under Tech.

Follow any responses to this entry with the Atom 1.0 feed.