Rich Internet Applications (RIA)! It’s still a hot topic. Last time, the hype was for Microsoft’s WPF/E platform. This time it’s Adobe’s Apollo platform. Due to be released sometime before mid 2007, Apollo is a neat platform built on Flash, Flex and Webkit. Adobe recently had an invite-only event, Engage, to show off the platform and demo some applications. It created quite a bit of blogbuzz.
I am not really convinced that Apollo will be the next big thing, but I could be wrong. There are some aspects of Apollo, WPF/E (or any runtime wannabe) that cause me to stop and think before falling head-over-heels.
- Platform vendor lock-in: Vendor lock-in is not a black/white issue. Some form of lock-in is always present. It’s more of a sliding scale. Tight lock-in (think MFC/COM apps) to Light lock-in (think cross-browser DHTML).
- Platform openness: Can you fork or hack the system? Can you supply bug fixes?
- Ability to extend with native code: You’ll likely need a feature not supported by the platform. Can you create an extension or plugin? Can you interact with the native OS or 3rd party databases?
- Interaction with desktop: Blending into the native OS is important to user experience.
Of course, the Mozillian that I am, I can’t help but think of XULRunner… Hmmm
Update: Ted Leung and Anne Zelenka have some “stop and think” posts too. I agree a lot with Ted. The day I stopped sharecropping for Microsoft was fantastic.
I view it as a set of trade-offs. I’ve developed 4 applications with XULRunner, and a few with the Flex 2 SDK.
Apollo will likely have great documentation (guess based off of Flex 2/ActionScript 3 Docs), it will be clear and quick to develop for.
XULRunner, and related technologies (currently) have spotty documentation, the learning curve can be a little steep to grasp all the different tentacles. (XUL, XBL, XPCOM, etc.)
A very important aspect to watch closely will be the user experience for application *and* runtime installation. Also management and versioning of that runtime.
We will get to see how Apollo handles it very soon here. I haven’t seen anything promising so far for streamlined runtime and app installation for XULRunner. So that is something I am eagerly awaiting.
I like XULRunner a lot, and developing with it. And you’re right, if you need to create a native code component, XULRunner wins on that.
I also like developing with Flex/ActionScript, less hassle for whipping an app together.
Looks like both Firefox 3 and Apollo are set to be having final releases Q4 07, so it will interesting to see how they end up getting used, and what their individual strengths and weaknesses are.
Thanks for the comments, Mark.
That “platform openness: can you fork or hack the system?” topic is an interesting one for me… I see layers of functionality, stacked atop each other, and some parts different individuals can change, other parts they cannot. This is particularly true with clientside engines: things which run on Other Peoples Machines.
With Apollo, as I currently understand, you can hack any app you wish, any interface, using either SWF or HTML/JS. You can’t change the engine someone has installed on their machine to render your SWF or HTML/JS, but you can confidently deploy atop that predictable capability on their machines.
We’ve got two dynamics here: the urge to customize and control our own devices and our own operating environment, and the value in providing others with a known capability to work within upon our own machines (and, conversely, each of our abilities to predictably deploy upon the machines of others). In a sense, the API is not a hackable layer — there are reasons that no HTML browser renders STRONG as BLINK — the assumption of particular capabilities on Other Peoples Machines allows us to deploy whatever we wish within that known API.
The section on extensions is also of interest to me. Again, it’s a layering thing… getting your own OS-native code onto Other Peoples Machines is always difficult. But getting your own ECMAScript customizations onto the known engines on the world’s machines then becomes easy. I don’t know of any Adobe work in making it easier for other people to adopt your own system-level code, but I do know that much of the Adobe work is in providing a predictable cross-OS platform atop which anyone can then deploy.
XULRunner is probably one of the closest models, I agree — both seem to attempt to provide a common and widely-trusted framework, upon which anyone is then free to build.
It’s a work in progress, though, and like most new things, will take a lot of experimentation and consensus to finally get right. If you could help in this guidance when it arrives, then that’d be great… thanks!
jd/adobe
I started tinkering with XUL when Mozilla 0.9.1 came out, and almost seven years later, it’s not that much easier to write an app in XUL.
Openness is nice, but as I wrote elsewhere, “if the UX rocks, it’s (probably) not free”.
~L