> From: niel.drumm...@googlemail.com [mailto:niel.drumm...@googlemail.com] On Behalf Of Niel Drummond > Sent: 20 February 2012 07:45 > > 1) Wait for falcon, projected stable release late 2012, early 2013. This to my mind is the most risky of your three options. We wait a year, then maybe get a compiler, which will be of unknown quality and usability. Then we'd have to start work on getting it to support MXML properly.
> 2) Write a cross-compiler for flex from scratch. This is, IMO at least, the best of your three options. It will be tough, but if enough people get involved then I see no reason why we couldn't achieve it. > 3) Port the SDK to haxe (or build a converter) Tried that and gave it up as a bad idea. There are numerous problems with this approach: 1. haXe doesn't support numerous aspects of AS3, such as custom namespaces, E4X, global functions and internal and private namespaces. Porting Flex to haXe would be a non-trivial task. 2. haXe compiles everything from source files. It has no support for partially compiled library files. Whilst it is fast for small numbers of files, this really doesn't scale well for larger applications, such as those using the Flex SDK. From the tests I did, I estimated that needing to recompile the SDK source files every time one did an application build would add 1 - 2 minutes to the build. 3. The SDK wouldn't just need porting to haXe, it would need rewriting to add lots of conditional compilation directives to it to control how it built to SWFs and to JavaScript. haXe is a great little hacking language (though don't call it that or indeed a toy language in front of Nicolas Cannasse, as he took offense when I -in my subtle-as-a-brick fashion - referred to it as the latter,) with a great community around it. It just isn't the sort of thing I like to offer up to an enterprise-type customer who'd normally consider Flex solutions. Of course it's worth wondering why no one except Michael Labriola is considering the fourth option in all of this: stick with the existing mxmlc and compc compilers. They may be slow, but they work and in theory we are supposed to be getting the source for them straight away, not in a year's time. Perhaps we should be putting more effort into investigating modifying them to output JavaScript, Android and IoS native etc? David.
