Five reasons a developer should avoid Adobe AIR

Dec 01 2008 Tags: review

Last week I spoke about five reasons you should develop in Adobe AIR, which got surprising amount of hits even if there were no comments. I was pleased enough with the response to write the promised second installment of my review – because every coin has three sides.

It’s javascript

Even though I touted this as the biggest advantage of Adobe AIR it also happens to be its biggest handicap. The reason behind this is that javascript is invariably slow, no matter how fast your computer, no matter how fast Adobe’s javascript implementation, it’s still a scripting language – albeit compiled and will thusly run much slower than native code.

This is of course a criticism geared towards all scripting languages, but fact remains that most desktop applications are not written in them. Why do you think things like OpenOffice and other mission critical systems are written in C++? Because it’s extremely fast and efficient. There is no way of getting something like that out of javascript.

Imperfect abstraction

Adobe toutes AIR as a great, almost perfect, abstraction layer between operating systems that enables developers to painlessly develop for all platforms. But as I’ve recently found in dveloping Twitulater this is not so. One problem I’ve found was that on Mac the javascript implementation automatically translates http://user:pass@domain.com uri’s to proper authentication and does all that’s needed seamlessly, whereas on Windows (Vista) trying to access such an address produces an error.

That was one very long debugging session before I figure that one out. The solution was telling AIR to ignore authentication and make my custom auth headers – which is dirty if you ask me. AIR should do that seamlessly and without annoying pop-ups.

Oh and on Linux it simply doesn’t work yet at all, but Adobe are working on it so I remain hopeful.

Mitigating window managers isn’t easy

Another issue I’ve found is that there is no simple way to adjust your application for different window managers. You can’t count on what size scrollbars will be, resizing the window is based upon outer height and width even though window decorations could be covering your content.

This wouldn’t be a problem if styling Adobe AIR appplications was done in a similar way native applications are, where you can just position the elements and the window manager takes care of the rest. Because you’re constrained to html you have no access to the window manager’s settings. You’re as constrained as if you were developing a website.

Tacky interfaces and flawed integration

Because developing with Adobe AIR is much like creating a website a big issue crops up. You can’t make your application look like the rest of what the user is seeing. Whatever you create will invariably stick out of the user’s desktop like a pack of wolves amongst three sheep. If users weren’t picky this, of course, woudln’t be a problem at all, but as we all know users are more and more concerned with how things look and less with how they work.

Or has it been like that all the time? Whatever it is, there are bound to be users out there who will refuse using your application just because it doesn’t integrate well with their overall user experience and you, as a developer, will feel dirty for it.

Only for widgets

Adobe AIR is a powerful widget framework, perhaps the best I’ve had the pleasure of working with. But that’s all it’s for and everyone trying to build proper applications should opt for something a bit (or a lot) more powerful.

Lately I’ve seen different kinds of important applications like Klok for time managment and some lovely thing De Monsters are making built and create on Adobe AIR. While this might be nice and lovely for the time being, I don’t think it will really survive. They will hit a glass ceiling when trying to improve their product and at some point will be forced to completely remake it. In that light Adobe AIR could be seen as a great prototyping tool for important apps, but I fear many developers aren’t realising that.

Conclusion

Let me conclude by saying that Adobe AIR is a wonderful compromise, but it should never be confused with being anything more than a good compromise between simplicity and speed of development and functionally and user experience. You get a quicker development cycle with a shallow learning curve, but sacrifice integration and efficiency.

---
Need a freelance developer? Email me!

You should follow me on twitter
Follow @Swizec Subscribe to RSS

17 responses so far

http://http%3A%2F%2Frobertbasi.com%2F Robert

I like this post more than the other

When I first discovered AIR, I thought: “WOW! Awesome! I can make desktop apps without need to learn something new!!!” WTF? I want to learn new things. And of course the drawbacks you listed here made me turn my back on AIR and start learning Python.

Cheers,
Robert
http://dan%40sumption.org Dan

The points you make are all valid, but where exactly does a widget end and an application begin?
http://http%3A%2F%2Fswizec.com Swizec

@Robert: sometimes you just want to make something without learning too much new stuff (like Twitulater), whereas sometimes you have time and get to learn new stuff

As for python, do learn Qt if you want to make serious things, please.

@Dan: I think it’s a distinction that comes from experience, you “just know” what’s a widget and what isn’t. For a simple heuristic I’d say something that you need quickly available and on screen at all times (almost) is a widget and what you open to do a task and then most often close is a “proper” application.
http://http%3A%2F%2Frobertbasi.com%2F Robert

Yes, well, my application that I meant to make with AIR started out as a widget like thingy, but with new ideas poping into my head, it turned out in a fairly big (big for me and my available time) app.

And yes, I am learning QT And loving it.
http://http%3A%2F%2Fagileui.blogspot.com Rob

First of all, AIR is not Javascript… is can be but it could be Actionscript. Even Javascript-based AIR applications are not what you typically think of as Javascript. Many of the problems people associate with Javascript such as cross browser compatibility are just not there when running in the AIR runtime. C++ is not doubt faster than Javascript but Adobe is making great strides with things like Alchemy (http://labs.adobe.com/technologies/alchemy/)

Tacky interfaces and flawed integration…really? And some other language automatically prevents this? AIR does not eliminate the need for good Interaction, Experience and Visual Design. Saying that the fact that an interface is different means it won’t get used is just not true. What percentange of Windows users have “refused” to use ITunes because it is different? There are plenty of applications out there that don’t follow the “normal” OS look and feel that are very successful. If your application is designed well, user’s will not even care or even notice it is different.

As far as the argument that AIR is good for widgets but not applications is also not true especially given the fact that widgets are a just a type of application. Drawing a line between what is a “real” application and what isn’t is really artificial.

As the developer of Klok, mentioned above, I am interested in why you say: “While this might be nice and lovely for the time being, I don’t think it will really survive. They will hit a glass ceiling when trying to improve their product”

I have had no problem improving the product and have a clear vision of what I plan to add without any worry about how I would implement them.
http://http%3A%2F%2Fswizec.com Swizec

Hey Rob I’m glad your commented.

Let me clear something up about javascript, it’s really just a flavour of ECMAscript, just as is actionscript. They’re in essence the same thing and you will notice I never said anything about cross-browser differences when it comes to AIR and javascript. All of my reservations were about efficiency and there is no arguing that a compiled language is always faster than a script language.

There aren’t languages that automatically prevent tackiness, but there are frameworks or how should it be called. There’s Swing for java, Qt for C++ and the Apple C++ libraries. All of these make it quite hard to create something that is out of whack with the rest of the GUI because the basic settings are drawn directly from what overall look and feel.

Now when it comes to AIR there are no basic settings and also no clear way of making something integrate seamlessly. I’m sure it can probably be done, but there isn’t any simple way and far as I know you could at best configure it to look like, say, Aqua, but someone might run it on Vista and eh … problems.

To be honest I only mentioned Klok because I noticed it briefly today and didn’t have the time to properly test it. But it looked awesome and I will probably start using it.

But I fear it might not scale very nicely when somebody starts REALLY using it … somehow similar issues to what Twitter had I guess. It will only go so far and while it could go further if it was made in C++ it will require a hardware upgrade to go further in its current form.

Maybe I’m just a power user, but when you have dozens of apps running at once it starts being really important how greedy each of them is.

Even so, I wish you all the luck with Klok
Michele

WRT your comment about AIR only being good for widgets, there are a number of companies building full-blown apps on AIR, including AOL, Direct TV, Fiat, and a number of enterprises that have their apps running behind the firewall. Agree with the other comment that it’s hard to define where a widget ends and a app begins, but you haven’t done your homework on the number of AIR apps out there if you think they are all widgets.
http://http%3A%2F%2Fswizec.com Swizec

Michele, I dind’t say they were all widgets, in fact I specifically said AIR was being abused to build other stuff than widgets. Of course it’s possible to make a full-blown app in AIR, hell it’s always been possible to do it in javascript/actionscript, but there’s are reason why it hasn’t pushed out things done in C++.

The only reason anything remotely like a full-blown app is possible in AIR is because people nowadays have computers that are thrice as powerful as they need be.
http://robotoole.com Rob%20OToole

Your problem is that you’re using AIR with Javascript. If you were building an AIR app using Flex (AS3/MXML) you wouldn’t see any of these problems. Great skinning, scalability, and speed.

Javascript has it’s flaws and it’s flaws arise in whichever environment you use.
http://http%3A%2F%2Fpromethe.net promethe

This post should be called “I bet I can make a (really (very)) poor use of AIR (and make it look like it’s not me who’s dumb)”, which is obviously true at least.

JS and AS have nothing in common except they are both implementation of the ECMAscript standard. Developing AIR application in JS is possible, but it does NOT mean that ‘AIR is [still] javascript’. Saying JS and AS are the same is just like saying C, objectiveC, C++ and C# are the same because they are all C-style languages. Which is completely dumb of course. Instead of being happy to be able to build full-blown app in JS, you should have taken a look at AS3… which is much more powerful.

GUI and interface design have _NOTHING_ to do with the language you use. Whether your application has the look’n'feel of the OS is a matter of development choice. Plus with the Flex/AIR framework, skinning is really easy and your app can easily look like any other so called ‘real’ application.

A lot of developers have proven that Flash/Flex and Actionscript as a language can be used to do a lot more than just widgets. you say that AIR is not capable to build full-blown app because otherwise it would have replaced C++. Sure! C++ is popular because it is simple and accessible, not because it is on the market since…. 1983!!! When AIR is only a few months old.

All your propositions are completely wrong and they only prove that YOU make a very poor use of AIR.
http://http%3A%2F%2Fswizec.com Swizec

Ok, so apparently I don’t know a lot about AIR. Just tell me two things:

1. How can I detect the native look and skin my app accordingly?

2. How close to Qt can I get my app’s resource greediness?
http://http%3A%2F%2Fswizec.com Swizec

Oh and about the skinning … all I’m saying is I shouldn’t have to. When I build an app in java it automagically looks exactly like the rest of the user’s interface. In AIR I have to make an effort and I honestly don’t think it’s even feasibly possible to get it 100% right.
http://robotoole.com Rob%20OToole

1. How can I detect the native look and skin my app accordingly?

You would first detect which OS you’re running on.
var os:String = Capabilities.os.substr(0, 3).toLowerCase();

Then you would load your external CSS compiled into a .swf at runtime. You would have two .swf’s (1 for windows, 1 for mac).

if(os == “mac”) //load mac css else //load windows css

2. How close to Qt can I get my app’s resource greediness?

The way flash player works now, it depends on the users memory. It creates a “ceiling” for memory and tells the GarbageCollector to come through and clean up unused variables. This ceiling is different for every single user. Some may have more memory, some less, but either way if it’s developed properly, it won’t be a huge issue.

There are some new things happening in Flex 4. One of them is allowing C++ libraries to work inside of AIR. There’s also a project called Merapi that creates a bridge between Java and AIR. That allows for multi-threading and the full power you’re looking for. It’s still in development but it’s worth looking into.
http://http%3A%2F%2Fswizec.com Swizec

1. See. that’s not what I’m looking for. I know I can detect what OS the app is running on, but can I detect what the skin is? Say someone is running Vista but with a winXp skin for performance issues.

Or someone’s running the App on linux and they’re using gnome or kde or xfce and even then, what skin, what does it ACTUALLY look like? The only truly predictable OS to skin translation is on Mac’s … momentarily.

2. My worries don’t go so much towards memory because I know that in garbage collection languages there isn’t much you can do about that and will most likely have a smaller memory footprint because it’s harder to make memory leaks.

My worries go more towards CPU performance because I’ve seen my app easily bottoming out a dual core 2.4GHz laptop when doing something difficult. When I do something much similar in C it barely registers. And when you have many AIR apps running (I usually have three or four) you can run into quite some problems.

For example Snackr, which is a RSS ticker, constantly eats away 20% of my CPU. TweetDeck (even when just sittin ghtere doing nothing) is eating away 11% whereas something as complex as Opera or Firefox when it’s “just sitting there” eats up a whole 0%.

While this might not be an issue for desktop computers, on laptops you want that battery life and constant CPU grinding isn’t helping.
Nick%20Collins

Really, I don’t think it has so much to do with the languages inherent speed, in terms of what you’re referring to, so much as it does the platforms hardware support. C++, etc. all have the ability to make direct use of the full hardware capabilities, such as the GPU for 3D. This has the advantage of allowing the apps to run faster, because they have all that extra hardware to handle more intensive processes. To top that off, they also allow for multi-threading. This is all well and good, unless you want your application to be truly cross-platform. Write once, run anywhere, remember the original promise of Java that it never truly delivered on? This is where AIR necessarily makes the comprimise. It does sacrifice some hardware “acceleration” capabilities for the sake of platform independence. It’s this same premise that prevents users from using native DLLs or other libraries because it creates platform dependencies. However, that does not mean that one cannot develop a “real” application on the runtime, it only means they need to be aware of the advantages and limitations and architect their applications accordingly. AIR was never billed as the ideal platform for any and all applications, but for the specific class of occasionally connected RIA applications.
http://gyanlabs.com Kishore

We are not suppose to write OpenOffice kind of application with AIR. That is not what it is intended for, AIR is mostly for UI or WebUI, FrontEnd for Web Applications…
http://qmsconsultants.com/NABH.html NABH

I really appreciate your post and you explain each and every point very well.Thanks for sharing this information.And I’ll love to read your next post too.
Regards:
NABH

Hey you!