Hacker News Reader

Comment by tkiley | Hacker News Reader

The Flash history lesson is cool. However, the idea that Adobe has "admitted defeat on mobile" is just plain wrong.

In spite of the massive hype differential vs. appcelerator and phonegap, Adobe's AIR is one of the best ways to build & deploy cross-platform mobile apps right now. That's flash, that's mobile, and it's a far cry from "admitting defeat".

Flash on the desktop browser is increasingly limited to a small set of niche uses. Flash inside a mobile browser was never a good idea, and it's dying. The decline of those two specific use cases should not be construed as a general death of the flash platform.

View on HN

Adobe's AIR is one of the best ways to build & deploy cross-platform mobile apps right now

As someone who has built and deployed a cross-platform app on AIR, I must respectfully disagree.

AIR doesn't give you access to a lot of native features of smartphones. As the most glaring oversight, I had to do some deep hacking on AIR's launcher to support in-app billing. Phonegap's extensible plugin approach looks a lot easier.

And the user experience is different, too. After months of work, my first review rolled in: one star, and said simply, "AIR crap." And no wonder. Without so much as the ability to display my own splashscreen beforehand, AIR simply asks the user, "Hi, would you like to do a 16 MB download to support this app that you don't even know what it does yet?" I've had my friends give me funny looks at that prompt. "When I'm done looking at this, I can delete that, right?" one of them asked.

If you do Phonegap -- or heck, even just raw HTML5 -- I'm not sure your users even need to know.

Yikes - sounds very similar to trying to deploy Java desktop apps. Not a pleasant experience. Why don't they just bake the AIR runtime into the original download? Sure it would be bigger and you'd end up with duplicate copies, but almost anything is better than trying to get end users to download runtimes.

Well, 16 MB is a really quite a nasty large size for an app. For reference, one of the low-end phones I target has 180MB of internal memory. (And I don't think I can tell an app -- and certainly not an AIR app -- to install itself on the SD card, though a wizardly user certainly can.) You can get away with 16 MB in a graphics-heavy game, but something that's mostly forms and screens really ought to come in under a megabyte.

Phonegap gets to bundle the platform because their hello world is only 300k. I really don't think AIR could get away with that.

But I agree, the user experience might be better if that was an option.

And to think I've been balking at a couple MB overhead for Monotouch. I guess that puts things in perspective.

I think bundling makes it a lot smaller than 16MB. Rather something like 8MB (which is still a lot of course).

You can bundle the runtime with your app to avoid this. Also trying to use a feature that exists only on one platform isn't really cross-platform, that said AIR does support Native Extensions to do exactly that. They aren't hard to write, I was involved in the beta program to help write the first ones.

That's good to know. I suppose my experience with AIR was about a year ago--right when they first came out with support for mobile--which is about two decades in phone years. And it sounds like my research wasn't complete.

Nonetheless, between a heavyweight and power-hungry executable, an expensive editor, and a scripting language and library for which the most complimentary term I have is "quirky", I really don't understand how AIR is considered even a serious contender in the space of cross-platform . . . platforms. Let alone the best.

I benchmarked AIR against Tcl/Tk on my desktop by implementing the same app in both - it used something like 80x the memory and 20x the CPU IIRC. It's not even a good GUI toolkit, let alone a good cross-platform one, compared to tech from the 90s.

That's a ridiculously biased comparison - of course tech from the 90s will use less memory and CPU, that was a higher priority in those days. A more relevant question is whether AIR was easier to develop in, or resulted in something that looked better.

Tcl/Tk was easier and used the native widget set.

I like adobe AIR a lot, because every time I see an app that uses it I don't even have to install it to know that it isn't worth my time.

Having worked in a few languages I can say without a doubt that MXML is one of the most fun languages I've used in a long time. How many times I've wished that HTML5 too had <HBOX> and <VBOX> implementations. They make your life so much easier (than floating DIVs, etc). The data binding of MXML and Actionscript are also one of the niftiest feature I've come in web development. It is like knockout.js only easier and implemented several years ago.

Even their web services like Adobe LiveCycle have been a breeze to use and were able to accomplish real-time collaboration in multiple Flash project with maybe 100 lines of total code. That's powerful.

Flash, esp. after MXML is an amazing platform for development but it is dismissed a lot by people who have never used it or maybe got biased using a poorly created end-product.

P.S. It's similar to how I used to think that Java was the worst programming language owning to regular "null pointer exceptions" and "slow loading" applets which I now clearly understand are not the fault of the language but the people who used it (esp after seeing awesome projects like Eclipse). Same goes for Flash. There are some super amazing stuff done in Flash, which is ultra fast, ultra robust and beats the pants down of any HTML5 application.

Funny, I walked away from Flash/Flex with the exact opposite impression. Data binding is good in theory but horribly slow in practice - any time something changes it dispatches a gazillion change events to be processed, and debugging problems with bindings can involve going really deep down the rabbit hole...

It's one of those things that seems nifty from a developer convenience point-of-view but results in poor user experience - pretty much every Flex app I've seen that made heavy use of bindings ran horribly slowly.

You mean, like the CSS flexible box layout model?

[0] http://www.w3.org/TR/css3-flexbox/

[1] http://caniuse.com/flexbox

[2] http://flexiejs.com/ (try the "Play with it" link)

Reply on news.ycombinator.com