In a previous post I said that Mozilla Prism is not an alternative to Adobe AIR. Thinking about it a little bit more, I think XULRunner is a more likely contender against Prism on its own. Like AIR, XULRunner is a tool for developers to use “web technologies” to make desktop applications. So I’ll just go ahead and make a table comparing the two:
| XULRunner | AIR | |
|---|---|---|
| Provider | Mozilla | Adobe |
| License | Open source | Some components are open (the VM, SQLite, WebKit) but the runtime is proprietary. |
| Cross platform | Yes | Yes |
| Stable? | Not yet, it needs work. I’ve had problems with the Mac version. | Linux version is alpha. The others are stable. |
| HTML engine | Gecko – Memory hog |
WebKit – Uses less memory |
| JavaScript engine | SpiderMonkey – Reasonable speed |
Tamarin – Fast (JIT compiler). |
| SpiderMonkey will use Tamarin starting with Firefox 4. | ||
| API | Primarily XUL, JavaScript and XPCOM. You can replace XUL by HTML. I don’t believe that you can use most Ajax toolkits. In any case, the application structure is different enough that porting an existing web application to run on XULRunner would be difficult. I don’t believe that porting web apps is a design goal of XULRunner. | Ajax and Flash. You can probably keep your existing Ajax or Flash application mostly unchanged. If you are using Dojo you need to upgrade to version 1.1.0. AIR does provide an additional API, but you only need it if you want to use functionality that Ajax and Flash do not normally have, like accessing the file system. Porting web apps to AIR is definitely a design goal. |
|
Personally I find XPCOM complicated and hard to work with. AIR is much easier. 95% is just doing whatever you’d normally do on your web app. The rest (e.g. read/write files) looks simple to me. Example: Create a “file” object that you can use to read/write files: XPCOM:
var contractId = "@mozilla.org/file/local;1";
var interface = Components.interfaces.nsILocalFile;
var fileClass = Components.classes[contractId];
var file = fileClass.createInstance(interface);
file.initWithPath("/home/daniel/hello.txt");
Adobe AIR: var file = new air.File(); file.nativePath = "/home/daniel/hello.txt"; |
||
| Deployment | The developer must make his own packages and must include XULRunner in the package (the situation might later improve on Linux). Thus, the package size is quite large and you have to maintain multiple packages for each platform you are targeting. | Easy. Adobe AIR takes care of the distribution, and the user only has to download Adobe AIR once. If installing from a web page, Adobe AIR is downloaded at the same time as your application, so the user doesn’t have to go to some other website like with Java. |
| Security | Nothing in particular. No different than downloading any other application from the internet and installing it. | All AIR apps are digitally signed. Though apps can be self-signed. What’s the point of self-signing an app? Well, at a minimum it provides an integrity check. To learn how to self sign packages : go to the manual and select AIR development tools > Creating an AIR application using the command line tools > Creating a self-signed certificate with ADT. |
| Documentation | I’ve had a hard time figuring out XULRunner’s documentation. I had to pull bits and pieces from various places and often had a hard time finding what I needed. | I am very happy with Adobe’s documentation. Though no documentation is every perfect, I think this one is very good. |
| Other features |
- Multithreaded. - Call external libraries. - I believe you have pretty much full access to the computer but I’m not sure. |
- Read/write access to the file system. - Access to the clipboard. - It comes with a database (SQLite) that you can use. - Drag and drop support. - Having Flash available means you can have fancy graphics and multimedia. |
| With AIR you don’t get full access to the computer (e.g. can’t run system libraries) but it has many great features that XULRunner lacks (SQL, easy multimedia, etc). | ||
