incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niel Drummond <>
Subject Re: Haxe and Flex
Date Tue, 13 Mar 2012 21:07:37 GMT
I think if some work were to go into this, it would be a great primer for
the issues around targeting javascript/HTML regardless of which compiler is
used. Many issues that were raised in the "porting to haxe" threads
revolved around generic issues that would need to be dealt with regardless
of whether falconJS or a separate custom compiler is used instead. I think
this puts haxe into a bad light, and offsets the problems the flex
community will have further down the road, when it's finally decided to put
some work into cross-compiling.

Nicolas didn't mention how haxe can be used from AS3/flex with minimal
work, because that's only possible over the flash runtime, which is only a
great reason if you wish to interface with flex from the haxe source code
(so the other way around).

>From my point of view, being a little bit naive about flex, and having
plenty of experience cross-compiling flash->js code with haxe (my first
demo was end 2008 [1]), looking at the flex code is quite intimidating at
first, and it would take me a considerable amount of time to find a
starting point. It would make it hugely more approachable if a tiny cross
section of core classes + one independent component were identified from
another expert as a potential candidate for a POC, ignoring any parsers,
ignoring tooling and most importantly not dependent on other parts of the

Regarding Arnoud Bos' suggestion of using as3hx, this might be a solution,
if (and only if) it's desired to keep as3 as-is, but I doubt it will be a
satisfactory solution, because I suspect eventually flex will want to
migrate some of it's components to pure HTML equivalents, which is
difficult to do purely on an NME basis.


- Niel

On Tue, Mar 13, 2012 at 4:23 PM, Michael A. Labriola <> wrote:

> >Hasn't the MXMLC Flex compiler been open source since version 3?
> No, not really. If you look at the licenses (which are contradictory in
> some cases) the modules directory containing the compiler source *may* have
> been Adobe license and not Mozilla so we may not have the right to
> redistribute. This is one of the long-ish battles Spoon was fighting as we
> wanted to modify this source.
> Mike

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message