Why Apollo?

There has been a lot of excitement, interest and discussion around Apollo, especially since we released the public alpha on labs last week. One thing that has come up a couple of times, is confusion over what Apollo is as well as what value it provides. A lot of the discussion has focused on uncertainty about why would you want to move web applications outside of the browser.

A lot of times when this question gets answered, the answer focuses on specific Apollo features (file I/O API, working offline). While these are things that Apollo can do today, that are difficult if not impossible to do consistently in the browser, a feature based discussion doesn’t address the fundamental question of why would you want to move applications out of the browser.

I had been planning to write up my thoughts on this, and realized that I already had as part of the Apollo Pocket Guide for Flex Developers. Below is chapter one from that book, which explains what Apollo is, and what problems it is trying to solve. (You can download the entire book from here).

Note that the excerpt does contain a discussion of features, but one of the primary advantages of Apollo, which isn’t a specific feature, is that it allows applications to run outside of the browser. This is not a ding on browsers, or web technologies, and as I point out, the browser has some strong advantages that often outweigh its disadvantages.

Ultimately though, because browser based and Apollo based applications are built using the same technologies, it is possible to deploy to both platforms, taking advantages of the strengths of each. Because of this, Apollo applications compliment web applications. They do not replace them.


What is Apollo?

Apollo is a new cross-platform desktop runtime being developed by Adobethat allows web developers to use web technologies to build and deployRich Internet Applications and web applications to the desktop.

In order to better understand what Apollo enables, and which problemsit tries to address, it is useful to first take a quick look over atthe (relatively short) history of web applications.

A Short History of WebApplications

Over the past couple of years, there has been an accelerating trend ofapplications moving from the desktop to the web browser. This has beendriven by a number of factors, which include:

  • The growth of the Internet as a communication medium
  • The relative ease of deployment of web applications
  • The ability to target multiple operating systems via thebrowser
  • The maturity of higher-level client technologies, such thebrowser and the Flash Player runtime

Early web applications were built primarily with HTML and JavaScript,which, for the most part, heavily relied on client/server interactionsand page refreshes. This page refresh model was consistent with thedocument-based metaphor for which the browser was originally designed,but provided a relatively poor user experience when displayingapplications.

However, with the maturation of the Flash Player runtime, and morerecently Ajax-type functionality in the browser, it became possible fordevelopers to begin breaking away from page-based application flows. Inshort, developers began to be able to offer richer applicationexperiences via the browser. In a whitepaper from March 2002,Macromedia coined the term Rich Internet Application (RIA), to describethese new types of applications in browsers, which “blendcontent, application logic and communications…to make theInternet more usable and enjoyable.” These applicationsprovided richer, more desktop-like experiences, while still retainingthe core cross-platform nature of the Web:

Internet applications are all about reach. The promise of the web isone of content and applications anywhere, regardless of the platform ordevice. Rich clients must embrace and support all popular desktopoperating systems, as well as the broadest range of emerging deviceplatforms such as smart phones, PDAs, set-top boxes, game consoles, andInternet appliances.

You can find the complete whitepaper and more information on RIAs here.

The paper goes on to list some features that define RIAs:

  • Provide an efficient, high performance runtime forexecuting code, content, and communications.
  • Integrate content, communications, and applicationinterfaces into a common environment.
  • Provide powerful and extensible object models forinteractivity.
  • Enable rapid application development through components andre-use.
  • Enable the use of web and data services provided byapplication servers.
  • Embrace connected and disconnected clients.
  • Enable easy deployment on multiple platforms and devices.

This movement toward providing richer, more desktop-like applicationexperiences in the browser (enabled by the Flash Player runtime, andmore recently by Ajax techniques) has led to an explosion of webapplications.

Today the web has firmly established itself as an applicationdeployment platform that offers benefits to both developers and endusers. These benefits include the ability to:

  • Target multiple platforms and operating systems.
  • Develop with relatively high-level programming and layoutlanguages.
  • Allow end users to access their applications and data fromvirtually any Internet-connected computer.

The growth of web applications can be seen in both the Web 2.0movement, which consists almost entirely of web based applications andAPIs, as well as the adoption of web applications as a core businessmodel of major companies and organizations.

Problems with DeliveringApplications via the Browser

As web applications have become more complex, they have begun to pushthe boundaries of both the capabilities of the browser and theusability of the application. As their popularity grows, these issuesbecome more apparent and important and highlight that there are still anumber of significant issues for both developers and end users whendeploying applications via the browser.

The web browser was original designed to deliver and display HTML-baseddocuments. Indeed, the basic design of the browser has notsignificantly shifted from this purpose. This fundamental conflictbetween document-and application-focused functionality creates a numberof problems when deploying applications via the browser.

Conflicting UI
 
Applications deployed via the browser have their own user interface,which often conflicts with the user interface of the browser. Thisapplication within an application model often results in userinterfaces that conflict with and contradict each other. This can leadto user confusion in the best cases, and application failure in theworst cases. The classic example of this is the browser’sBack button. The Back button makes sense when browsing documents, butit does not always make sense in the context of an application.Although there are a number of solutions that attempt to solve thisproblem, they are applied to applications inconsistently; users may notknow whether a specific application supports the Back button, orwhether it will force their application to unload, causing it to loseits state and data.

Distance from the Desktop

Due in part to the web security model (which restricts access to theusers machine), applications that run in the browser often do notsupport the type of user interactions with the operating system thatusers expect from applications. For example, you cannot drag a fileinto a browser-based application and have the application act on thatfile. Nor can the web application interact with other applications onthe user’s computer.

RIAs have tried to improve on this by making richer, more desktop-likeinterfaces possible in the browser, but they have not been able toovercome the fundamental limitations and separation of the browser fromthe desktop.

Primarily OnlineExperience

Because web applications are delivered from a server and do not resideon the users machine, web applications are a primarily onlineexperience. While there are attempts underway to make offline web-basedapplications possible, they do not provide a consistent developmentmodel, they fail to work across different browsers, and they oftenrequire the user to interact with and manage their application andbrowser in complex and unexpected ways.

Lowest Common Denominator

Finally, as applications become richer and more complex and begin topush the boundaries of JavaScript and DHTML, developers areincreasingly faced with differences in browser functionality and APIs.While these issues can often be overcome with browser-specific code, itleads to code that is more difficult to maintain and scale, and takestime away from function-driven development.

While JavaScript frameworks are a popular way to help address theseissues, they can offer only the functionality provided by the browser,and often resort to the lowest common denominator of features betweenbrowsers to ease the development model. While this issuedoesn’t affect Flash-based RIAs, the end result forJavaScript-or DHTML-based applications is a lowest common denominatoruser experience and interaction model, as well as increaseddevelopment, testing, and deployment costs for the developer.

The fact that web applications have flourished despite these drawbacksis a testament to the attractiveness of having a platform with a gooddevelopment model that has the ability to deliver applications tomultiple operating systems. A platform that offered the reach anddevelopment model of the browser, while providing the functionality andrichness of a desktop application, would provide the best of bothworlds. This is what Apollo aims to do.

Introducing the ApolloRuntime

So, what is Apollo, and how can it make web application development anddeployment better?

Apollo is the code name for a new cross-operating system runtime beingdeveloped by Adobe that allows web developers to leverage theirexisting web development skills (such as Flash, Flex, HTML, JavaScript,and PDF) to build and deploy Rich Internet Applications and content tothe desktop.
In essence, it provides a platform in between the desktop and thebrowser, which combines the reach and ease of development of the webmodel with the functionality and richness of the desktop model.

It is important to step back for a second and point out what Apollo isnot. Apollo is not a general desktop runtime meant to compete withlower-level application runtimes. This means that you probablywouldn’t want to build Photoshop on top of Apollo.Apollo’s primary use case is enabling Rich Internet and webapplications to be deployed to the desktop. This is a very importantbut subtle distinction, as enabling RIAs on the desktop is the primaryuse case driving the Apollo 1.0 feature set.

Apollo is also not a browser. While it does allow developers to use webtechnologies such as HTML, and Flash to build applications, it does notprovide any default UI to the user for browsing web pages. It ispossible to build a browser on top of Apollo, but at a basic level,Apollo is a runtime that enables developers to build end userapplications, and is not an end user application itself.

At its core, Apollo is built on top of web technologies, which allowweb developers to develop for and deploy to the desktop using the sametechnologies and development models that they use today when deployingapplications on the Web.

Primary ApolloTechnologies

There are three primary technologies included within Apollo, which fallinto two distinct categories: application technologies and documenttechnologies.

Primary ApplicationTechnologies

Application technologies are technologies that can be used as the basisof an application within Apollo. Apollo contains two primaryapplication technologies, Flash and HTML, both of which can be used ontheir own to build and deploy Apollo applications.

Flash

One of the core technologies Apollo is built on is the Flash Player.Specifically, Apollo is built on top of Flash Player 9, which includesthe ECMAScript-based ActionScript 3 as well as the open source Tamarinvirtual machine (which will be used to interpret JavaScript in futureversions of Firefox).

You can find more information on the open source Tamarin project at onthe Mozilla website site at http://www.mozilla.org/projects/tamarin/.

Not only are all of the existing Flash Player APIs available withinApollo, but some of those APIs have also been expanded and/or enhanced.Some of the functionality that the Flash Player provides to Apolloincludes:

  • Just-in-time Interpreted ActionScript engine for speedyapplication performance
  • Full networking stack, including HTTP and RTMP, as well asBinary and XML sockets
  • Complete vector-based rendering engine and drawing APIs
  • Extensive multimedia support including bitmaps, vectors,audio, and video

Of course, the Flex 2 framework is built on top of ActionScript 3,which means that you can also take advantage of all of the features andfunctionality that Flex offers in order to build Apollo applications.

HTML

The second application technology within Apollo is HTML. This is a fullHTML ren•dering engine, which includes support for:

  • HTML
  • JavaScript
  • CSS
  • XHTML
  • Document Object Model (DOM)

Yes, you read that right. You don’t have to use Flash tobuild Apollo applications. You can build a full-featured applicationusing just HTML and JavaScript. This usually surprises some developerswho expect Apollo to focus only on Flash. However, at its core, Apollois a runtime targeted at web developers using webtechnologies— and what is more of a web technology than HTMLand JavaScript?

The HTML engine used within Apollo is the open source WebKit engine.This is the engine behind a number of browsers, including KHTML on KDEand Safari on Mac OS X.

Why WebKit?

Adobe spent a considerable amount of time researching which HTML engineto use within Apollo and used a number of criteria that ultimately ledthem to settle on WebKit.

Open project.Adobe knew from the very beginning that it did not want to create andmaintain its own HTML rendering engine. Not only would this be animmense amount of work, but it would also make it difficult fordevelopers, who would then have to become familiar with all of thequirks of yet another HTML engine.

WebKit provides Apollo with a full-featured HTML engine that is undercontinuous development by a robust development community that includesindividual developers as well as large companies such as Nokia andApple. This allows Adobe to focus on bug fixes and features, and alsomeans that Adobe can actively contribute back to WebKit, while alsotaking advantage of the contributions made by other members of theWebKit project.

Proven technology thatweb developers know. As discussed earlier, one of thebiggest problems with complex web development is ensuring that contentworks consis•tently across browsers. While something may workperfectly in Firefox on the Mac, it may completely fail in InternetExplorer on Windows. Because of this, testing and debuggingbrowser-based content can be a nightmare for developers.

Adobe wanted to ensure that developers were already familiar with theHTML engine used within Apollo, and that they did not have to learn newall of the quirks and bugs of a new engine. Since Safari (which isbuilt on top of WebKit) is the default browser for Mac OS X, developersshould be familiar with developing for it.

Minimum effect on Apolloruntime size. The target size for Apollo is between 5 and9 MB. The WebKit code base was well-written and organized and had aminimal impact on the final Apollo runtime size. Indeed, the currentruntime size with both Flash and HTML is just a little over 5 MB.

Proven ability to run onmobile devices. While the first release of Apollo runsonly on personal computers, the long-term vision is to extend theApollo runtime from the desktop to cell phones and other devices.WebKit has a proven ability to run on such devices and has been portedto cell phones by both Nokia and Apple.

Primary DocumentTechnology

Document technologies within Apollo refer to technologies whose primarypurpose is for the rendering and interaction with electronic documents.

PDF and HTML are the primary document technologies available withinApollo.

PDF

PDF functionality is not included in Alpha 1 of Apollo, so we cannot gointo too much detail of how it is implemented. However, in generalApollo applications, both Flash- and HTML-based, will be able toleverage and interact with PDF content.

HTML

HTML was originally designed as a document technology, and today itprovides rich and robust control over content and text layout andstyling. HTML can be used as a document technology withinApollo—both within an existing HTML application as well aswithin a Flash-based application.

What Does An ApolloApplication Contain?

Now that we know what technologies are available to applicationsrunning on top of the Apollo runtime (see Figure 1-1), let’slook at how those technologies can be combined to build an Apolloapplication.

Applications can consist of the following combinations of technologies:

  • Flash only (including Flex)
  • Flash-based with HTML content
  • HTML/JavaScript only
  • HTML/JavaScript-based with Flash content

All combinations can also leverage PDF content

Technology Integrationand Script Bridging

Because WebKit and the Flash Player are both included within theruntime, they are integrated together on a very low level. For example,when HTML is included within Flash content, it is actually rendered viathe Flash display pipeline, which, among other things, means thatanything that you can do to a bitmap within Flash (blur, rotate,transform, etc.) can also be done to HTML.

This low-level integration also applies to the script engines withinApollo (that run ActionScript and JavaScript). Apollo provides scriptbridging between the two languages and environments, which makes thefollowing possible:

  • JavaScript code to call ActionScript APIs
  • ActionScript code to call JavaScript APIs
  • ActionScript code to directly manipulate the HTML DOM
  • Event registration both ways between JavaScript andActionScript

Note that the script bridging is “pass byreference.” So when passing an object instance fromActionScript to JavaScript (or vice versa), changes to that instance inone environment will affect the instance in the other environment.Among other things, this makes it possible to maintain a reference toHTML nodes from within ActionScript and modify them, or to register andlisten for events.

This low-level script bridging between the two environments makes itvery easy for developers to create applications that are a combinationof both HTML and Flash.

The end result of all of this is that if you are a web developer, thenyou already have all of the skills necessary to build an Apolloapplication.

Apollo Functionality

Apollo provides a rich set of programming APIs, as well as closeintegration with the desktop that allows developers to buildapplications that take advantage of the fact that they’rerunning on the user’s desktop.

Apollo Programming APIs

In addition to all of the functionality and APIs already offered by theFlash Player and WebKit engine, Apollo provides additionalfunctionality and APIs.

Apollo APIs will be exposed to both ActionScript and JavaScript.
Some of the new functionality includes, but is not limited to:

  • Complete file I/O API
  • Complete native windowing API
  • Complete native menuing API
  • Online/Offline APIs to detect when network connectivity haschanged
  • Data Caching and Syncing APIs to make it easier to developapplications that work on- and offline.
  • Complete control over application chrome
  • Local storage/settings APIs
  • System notification APIs (that tie into OS-specificnotification mechanisms)
  • Application update APIs

Note that functionality may be implemented directly within the Apolloruntime or on the framework layer (in Flex and JavaScript), or by usinga combination of both.

Apollo Desktop Integration

As discussed earlier, applications deployed via the browser cannotalways support the same user interactions as desktop applications. Thisleads to applications that can be cumbersome for the user to interactwith, as they do not allow the type of application interactions withwhich users are familiar.

Because an Apollo application is a desktop application, it is able toprovide the type of application interactions and experience that usersexpect from an application. This functionality includes, but is notlimited to:

  • Appropriate install/uninstall rituals
  • Desktop install touchpoints (i.e., shortcuts, etc.)
  • Rich drag-and-drop support:
    • Between operating system and Apollo applications
    • Between Apollo applications
  • Between native applications and Apollo applications
  • Rich clipboard support
  • System notifications
  • Native Icons
  • Ability for applications to run in the background

Once installed, an Apollo application is just another nativeapplication, which means that the operating system and users caninteract with it as it does with any other application. For example,things such as OS-level application pre-fetching and switching work thesame with Apollo applications as they do with native applications.

The goal is that the end user doesn’t need to know they arerunning an application that leverages Apollo. They should be able tointeract with an Apollo application in the same way that they interactwith any other application running on his desktop.

Apollo DevelopmentToolset

One of the reasons web applications have been successful is that theyallow developers to easily deploy applications that users can runregardless of which OS they are on. Whether Mac, Windows, Linux,Solaris, or cell phones, web applications provide reach.
 
However, success is based not only on cross-platform deployment, butalso on the cross-platform nature of the development environment. Thisensures that any developer can develop for—andleverage—the technology. Neither the runtime nor thedevelopment tools are tied to a specific OS.

The same is true of Apollo. Not only does Apollo provide thecross-platform reach of web applications, but, just as importantly,Apollo applications can be developed and packaged on virtually anyoperating system.

In fact, Apollo itself does not have a compiler or specialized IDE.Apollo applications just consist of web content, such as Flash andHTML. Any tool that can edit an HTML or JavaScript file can also beused to create an Apollo application.

A beta version of Flex Builder with Apollo support is included with theApollo Alpha. Because Apollo applications are built with existing webtechnologies such as HTML and Flash, you can use the same tools thatyou use to create browser-based content to create Apollo applications.The Apollo SDK provides a number of free command-line tools that makeit possible to test, debug, and package Apollo applications withvirtually any web development and design tool.

The included command line tools are:

ADL – AllowsApollo applications to be run without having to first install them
ADT -Packages Apollo applications into distributable installation packages

While Adobe will be adding support to its own web development anddesign tools for authoring Apollo content, they are not required. Usingthe Apollo command-line tools, you can create an Apollo applicationwith any web development tool. You can use the same web development anddesign tools that you are already using today.

Is Apollo the End of WebApplications in the Browser?

So, by this point, you may be saying to yourself, “Gee,Apollo sure sounds great! Why would anyone ever want to deploy anapplication to the browser again? Is Apollo the end of web applicationswithin the browser?”

No.

Let me repeat that again: no.

Apollo solves most of the problems with deploying web applications viathe browser. However, there are still advantages to deployingapplications via the browser. The fact that there are so many webapplications despite the disadvantages discussed earlier is a testamentto the advantages of running within the browser. When those advantagesoutweigh the disadvantages, developers will still deploy theirapplications via the web browser.

But is it not necessarily an either/or question. Because Apolloapplications are built using web technologies, the application that youdeploy via the web browser can be quickly turned into an Apolloapplication. You can have a web-based version that provides thebrowser-based functionality, and then also have an Apollo-based versionthat takes advantage of running on the desktop. Both versions couldleverage the same technologies, languages, and code base.

Apollo applications complement web applications in the browser. They donot replace them.  

11 Responses to Why Apollo?

  1. Alexander Marktl says:

    I also thought about that. You know: will Apollo replace the browser? Will it be a new Browser…I’m currently working on an Apollo based Business Application. Today such apps are still mainly classical desktop software but there are some attempts that bring them Online.The problem is: Browsers are just not the best way to do such an Application but on the otherside the Internet just has so many advantages (no installs, no backups, no updates, access everywhere …).Apollo is the solution: It’s a combination of both worlds.But why is it a complement to the Browser and not a replacement?Well there are still situations where you just cannot or don’t want to install a desktop app, like at public PCs, at your private PC,…The really cool thing with Apollo is, that we don’t have to decide between Web or Desktop anymore. Just take your existing code and with a few modifications it runs within a Browser or on the Desktop.You can offer both versions to your customers and let them decide, what they prefer…Btw: I’m using Flex Builder since 3 months now and the learning curve is massive.

  2. Brian says:

    My question is how large is the Apollo runtime for normal users? If it’s a lot bigger than say a flash download, then Apollo suffers from the same major weakness that Java suffers from.Flash installation seems automatic and painless… if Apollo isn’t the same, then that’s one strike against it.

  3. Jamie Badman says:

    The biggest problem from a personal point of view, using Apollo is, in a large corporate intranet – which is the arena I’ve developed in for the last five years or so, desktop security is often very tight. This means that installing a new application can often not be accomplished by a standard user; a support call needs to be placed for a support engineer to install a required application – provided it’s been passed by an apps security group etc etc.This has been the great strength of developing apps in Flex (or prior to that, Flash/Firefly etc). All that was needed was approval for Flash to be installed on the corporate build and everything else just works.Apollo steps back a little in that regard though; it’s back to ‘each application has its own install’ and therefore is likely to run afoul of corporate security/policy.However… all the above might be total rubbish – I’ve not tried Apollo yet – except to install a few demos on my PC – *perhaps* an install is less than it appears to be – if, for example, an Apollo install (assuming the runtime already exists on the PC) is actually the transfer of a single file/directory onto the user’s machine – with no registry or system modification – then *maybe* this isn’t such a problem – because of course each user will *always* have a writeable directory somewhere. Is this the case ? Or is an Apollo app install spreading itself out and about on the user’s machne ?Cheers,Jamie.

  4. leslie says:

    Some thoughts on Apollo, XUL, and WPFe:http://jinsync.com/?q=node/12~L

  5. Brian Lee says:

    Why Apollo will probably not make it (or how Flash kicked Java’s ass as a Web UI)?I could be wrong, but if Apollo’s install is a lot longer and larger than Flash’s installation, say closer to Java’s time to install (think of it on the consumer’s end as opposed to developer’s), Apollo will suffer the same fate as java for the consumer. Not many people want to take time to install something that doesn’t do anything specific (instant messaging, playing music, etc…). This is why web apps and flash games have taken off in popularity – most people just don’t like to install software.This isn’t Macromedia/Adobe’s first time in trying to do this. If I remember correctly there was a desktop version of flash as well. Those who don’t study history, tend to repeat it….

  6. Simon Lord says:

    I have to agree with Brian on this one. We were hoping that Apollo was a wrapper for our apps so that we could create an installer for our clients to run. But now it looks like we need to get our clients to install Apollo first THEN install our app? How is this appealing? Psycologically this makes the apps more complex because users have to install “all this other stuff”.Ok, yes, once Apollo is installed then the user can omit that step. But how does THAT make our documentation any easier or smaller? Now we have to descibe HOW to *check* for Apollo AND how to *install* Apollo or how to *update* Apollo. That’s a LOT of extra documentation to write in *our* product docs about ANOTHER companies product.This is no different than having to ask users to install HyperCard in order to run Stacks. And, as Brian suggests, the act of having to depend on the user to go through all these hoops to install Apollo before installing our app is for us, simply too risky.

  7. Thank you for taking the time to write such an awesome article! It is exactly the type of overview I was looking for.RegardsTim

  8. Great article, and certainly interesting technology. Most applications I’ve worked on the last years would certainly have taken advantage of such a mixed model.If I may add my two cents:* It’s unfortunate that there is no role for a Java. The prospect of having to use JavaScript for more than a little tweak here and there would be a big turn-off for me (and many fellow programmers I’m sure).* The conflicting UI argument makes sense, but has two sides to it. I think that many of the leading web applications, especially some of the 2.0 apps, got popular because they had a UI that set them apart, as much for the looks and innovations as for the bare functionality.

  9. SimonH says:

    Having to install the runtime before you run the app could be a problem for some people. But, because the Apollo app may have a link with an existing web application you’re already using, the incentive to install it is much greater than Java.The Ebay app is a good example, it’s not reinventing Ebay, just extending it. A user would much rather install the Apollo runtime that extends Ebay over the Java runtime for an untested/unused Java auction app.

  10. Jean-francois Nepton says:

    I have heard mentioning of more audio support, would this happen to include support for recording audio from the microphone and saving to the local file system as opposed to just hearing the sound with Flash’s default API?