The Pros and Cons of Adobe AIR

Adobe AIR is really getting a lot of press and I have to say that I am a fan of the technology. Having come from a client-server background, its nice to leverage the technologies that I’m currently using to build desktop apps.

There are pros and cons, though, and I think Tim Anderson has done an excellent job of listing some of the good and bad of Adobe AIR:

Some pros:

1. Fast execution. ActionScript 3.0 has a JIT (just-in-time) compiler, putting it on a par with Java or .NET for raw performance.

2. Cross-platform. AIR apps will run on Windows XP and Vista, Mac OS X (PowerPC and Intel), Linux (though not in the beta).

3. Easy conversion of existing Flex or HTML applications. It’s the same basic runtime. In the case of HTML, AIR apps rely on WebKit, the core component in Apple’s Safari web browser.

4. Easy installation. Provided the runtime has installed successfully, installing AIR applications is likely to be be trouble-free, since all the files go into the application directory.

Some cons:

1. Limited extensibility. AIR apps have file access, clipboard access, support multiple windows, support drag and drop, and can trigger notifications (”toast” in Windows). If you app needs to interact with the desktop in other ways, the chances are that AIR is not suitable. For example, there’s no access to COM automation, and no way to execute external applications. The reason is to maintain cross-platform compatibility. That’s a worthy goal, but it would be good to have a way out of the sandbox. Unlike Java or .NET, you cannot extend AIR with custom native code libraries. Nor can you call operating system APIs.

2. Database access limited to SQLite or web services.

3. Enterprises need to roll out applications over the network in a controlled manner. AIR has no specific support for enterprise deployment. On Windows, AIR does not use the Windows Installer service. Either Adobe or 3rd parties will need to create deployment wrappers to overcome this.

4. Proprietary technology. AIR applications depend on Adobe’s runtime.

Two things that I’m not quite in line with are his concerns about the proprietary nature of AIR and security concerns. First, being “proprietary” doesn’t mean its a bad thing. I realize that people have become accustomed to OSS but that doesn’t mean that EVERYTHING needs to be OSS in order to be a valuable solution.

Secondly, I had a great conference call with Adobe regarding the security considerations with building AIR apps and can say that they are very much in tune with this. They’ve had conference calls with some JavaScript industry heavyweights and are taking security VERY seriously.

Overall, though, Tim does touch on some very key points and its definitely a good read for those considering Adobe AIR.

(Via Ajaxian.)