The Hype Around Apollo - Am I Missing Something?
Adobe’s new cross-platform “rich desktop application” platform has just reached the stage of “public alpha” release. That means, people will be free to download it, but it’s not going to be either bug-free or feature-complete. Now, we all know that Flash is a fantastically successful browser-based technology for building Rich Internet Applications, especially with Flex.
However, I’m really struggling to understand the huge amount of hype surrounding Apollo (e.g. see TailRank). As far as I can see, the new Apollo platform is essentially Flash, bundled with a web-browser (WebKit, which is what Safari is based on), plus a handful of APIs. Is it really going to make that much of a difference to developers?
Is this really so different from what we already have? I mean - I understand the point of developing Rich Internet Applications for the Desktop. But, I don’t see how Apollo adds to the mix particularly.
I get the whole Flex thing. I have to say, though, I’m not really getting Apollo… What am I missing?
Steve Sarakas wrote:
Several things my friend. Even rich web apps have been largely confined to the browser. It was a big improvement when the server could actively update the client (ie AJAX w/XMLHttpRequest), even as you are working on a page, a form, or whatever. You no longer had to click when you were ready to send everything up to the server. JS could do some client side grunt work, but the server still didn’t know what was going on at the client end, JS or no JS.
Being confined to the browser means, among other things, the web app and server STILL have no access to the local resources including the disks, CPU, etc. Windows now provides Isolated Storage for .NET, and this helps a little.
Now imagine a runtime environment that provides a “sandbox” for the web app to operate in, that grants access to the client resources. The web app can use the browser if it wants, but it doesn’t have to. An application can be deployed from a server, run on the client and use all the local power and storage of the client, and more.
Then the server wouldn’t have to do all the work, only handle updates. You wouldn’t have to install an application, then install update upon update upon update, on the client. Applications have to go in this direction now. Many can’t keep up with the updates. As BW and connectivity increases, it makes more and more sense.
This is just one aspect. Others are emphasizing how you will be able to continue running a web app even after a connection is lost, then when it is restored, invisibly update a session with the server. Still others emphasize how they will no longer have to support multiple versions of an application - one for MacOS, one for Windows, etc.
Older technology made attempts to do this, because the need was seen long ago. But those failed in one way or another. They had security problems they couldn’t iron out, or their runtime was huge and clunky. The Apollo runtime will succeed if it is small, and take up is as great as the Flash Player. It will play a big role in astounding improvements in web apps. The browser may well fade away.
For an example of earlier attempts to do the above, visit the Java WebStart site and play with their Notepad demo. ActiveX was the last technology in wide use that granted a server some client side authority, but security issues have all but shut it down.
Posted 26 Mar 2007 at 4:10 pm ¶
simon wrote:
Steve, thanks for taking the time to post all that. I do get that stuff. As I said in the blog, “I understand the point of developing Rich Internet Applications for the Desktop.” We were developing these kind of distributed, zero-config, self-updating non-browser, web-based technologies ten years ago. They have big benefits for end-users over browser-based apps in certain scenarios.
The bit I don’t get is what Apollo adds to the mix fundamentally. You mention runtime size as being an important differentiator. I’m not sure that’s the case - the size of the Apollo runtime will most likely end up being around the same size as the Java runtime.
Posted 26 Mar 2007 at 6:10 pm ¶