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.

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.

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?

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.

Javascript has it’s flaws and it’s flaws arise in whichever environment you use.

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.

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

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.

And yes, I am learning QT And loving it.

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.

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