incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Dalton <>
Subject Re: Flex 5 in haxe
Date Fri, 16 Nov 2012 16:01:12 GMT
Not to add fuel to the fire, but is choosing another platform like Haxe as
a core dependency of our project really a good idea?

I like Haxe as a concept, but I'm not 100% sold on the way they implement
the multiple compile targets (especially JS/HTML) AND am certainly
concerned that the future of Flex would be so intertwined with this other
relatively obscure project.

Though it would enable a shorter path in the near term, depending on
another translation/compilation layer looks risky to me both in terms of
Flex's capabilities and longevity.


On Fri, Nov 16, 2012 at 7:51 AM, Carlos Rovira <> wrote:

> > But bad news - in this situation i think guys from Adobe doesn't help us
> with new compiler.
> This should not be the motivation to go one way or another. Adobe's
> position is already shared and know: They want only gamming. They throw
> flex away. Tools, AVMs and languages are updated and designed only with
> gamming in mind...
> Alex, Carol and others are here payed by Adobe, but this project is made of
> individuals (although some of them are payed by a company). It's clear that
> Adobe could close the participation of their people, but this is a risk we
> could take if the main direction choosen is what Apache Flex need.
> We must think in what is the best for Apache Flex, and my position is that
> a rewrite make us free of technology or tool to choose. And we should not
> depend exclusively on Flash Platform and Adobe decisions. It's only a
> matter of choose a open source platform that's working and could give us
> support in the long term.
> Some months ago my thoughts was very different, but right now that a full
> rewrite is required, my opinion is clear about what to choose, and for
> something new, I choose Haxe.
> --
> Carlos Rovira
> Director de TecnologĂ­a
> M: +34 607 22 60 05
> F:  +34 912 35 57 77

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