flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Newman <Capta...@unFocus.com>
Subject Re: Flex 5 in haxe
Date Wed, 21 Nov 2012 20:53:37 GMT
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 

> 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.

View raw message