On 11/21/12 1:22 PM, Alex Harui wrote:
And, what isn't clear is how well AIR will run on that device,
if at all. There are so many devices it will be hard for AIR to keep
running well (in captive runtime of course) on all of them.
The exact same thing was true for desktop/laptops with Flash. I offer as
proof - every single Flex, ever, especially on any of the "Pentium" or
"Celeron" powered budget wintels (or even some older higher level
equipment). There are also plenty of other middleware platforms that are
in a worse position than AIR (stage3d is magic - there should be a
Cocoa-like API on top of that), who are doing just fine supporting all
these divergent hardware platforms. And, ARM is doing a fantastic job
holding things in some semblance of order on the hardware side. Intel
may be crying in their beer, but they aren't not the captain of the
mobile ship, which is already miles out to sea without them.
Besides, I haven't been advocating for AIR anyway (Adobe should, but
they aren't) - I've been advocating for AIR like APIs, but a compile
system that routes through a native build system. That's how Haxe works,
and I think that's actually easier to deal with over time, as hardware
and OS platforms evolve. Adobe could do that with AS4 (and proprietary
AIR libs like Stage3D, DRM, video, etc.), but they don't seem
interested. Instead, they just want to add a highway tax for rich
industries like "Console Quality Games" to gain access to their their
huge (but diminishing) install base. I mean that'll work, for a year or
two. Until Native Client or something else eats Adobe's lunch (maybe
that's why Google is destabilizing Flash in Chrome, heh).
This is why, even though Flash will be running in browsers on desktops with
keyboards "forever", more and more of the folks most of you are targeting
won't be using a browser/keyboard combination that is Flash capable.
And, eventually, the network speeds and prices and device speeds will reach
the point where zero-install browser-delivered apps on those devices become
the predominant paradigm again.
You are talking year and years out for device speeds, and I doubt it the
market will go back anyway. I wrote a while back that the problem of
native apps in the web browser era was app delivery and discoverability.
With new battery life constraints on mobile systems, and the relatively
hampered experience you get from browsers measured against native apps -
and most importantly the easy access to app store content in modern
operating systems - I don't know know if browser apps will ever come
back into dominance in quite the same way. Maybe with the right tooling,
and adjustments to the actual mobile browsers, even then I'm skeptical.
Apple has already shown unwillingness to make things easier to bypass
their app store - hampering "webapps" in various ways for example.
I actually think both sides will resist movement back to browser as the
primary app distribution model - those that run app stores, and those
that sell apps through them. App stores are just too easy to sell
through and monetize. In an important way they fill a gap the ads only,
search and discovery web based e-commerce system couldn't fill. It's so
lucrative, BTW, that no one seems bothered by the 30% tax they lose on
each app sale. That speaks volumes about the acceptance, and is perhaps
a sign of the entrenchment of app stores.
I suppose maybe HTML5 app store apps could still work, but I'm skeptical
they'll ever deliver the better speed and battery life they'd need to to
make it in there. And, developing in JS is the pits. Many of us have
been forced to try it over the last year, and it's just not great. The
tooling sucks, probably always will, and the language itself has
scalability issues, and that's before you even get into the DOM and all
the platform inconsistencies. Adobe jumped way too early off the stable
steal Flash ship, onto the rickety hobbled together by twine raft of HTML5.
For sure, there are plenty of reasons to keep maintaining the current code
base, and I will invest time there. But I see it as my mandate to try to
shape a next generation of Flex that is designed to be ported to other
platforms. By going to JS, we get the most coverage for the least amount of
work, but we have to give up fidelity and performance. Over time, with
enough resources, we may be able to target other platforms natively, but
that will take a lot of time and effort.
But if we are to change languages, why not go with a language that,
looks a lot like AS3 (and ports easy), addresses the language
scalability issues of JavaScript (lack of classes, typing, a compiler,
etc.), and can compile to JS as well as other languages? Haxe can be
compiled into JS, ABC/SWF, C++, C#, etc. Why NOT use Haxe?
Of course, the decision hasn't been made to switch off of AS3 just yet,
but AS3 just seems to be a dead end, both in the wild, and at Adobe. AS4
would be the most obvious way forward, but that's not possible without
first class support from Adobe, and they've sent clear signals will not
happen.
Those of you who are Haxe fans should definitely start your own rewrite. We
can't just keep talking about it in email. We won't know how it will truly
be to move to Haxe until there is something to actually play with. We don't
have to decide as a community which language to use for a re-write without
actually trying a couple of different angles. For me, I will stay on AS3
unless I get strong signals that there is no value to any of our current
Flex developers by staying on it.
That's not a bad idea. Someone should just throw some stuff into github
and get started. :-)
Kevin N.
