On Mon, Feb 20, 2012 at 4:07 PM, David Arno <da...@davidarno.org> wrote:
> > From: niel.drumm...@googlemail.com [mailto:niel.drumm...@googlemail.com] > On Behalf Of Niel Drummond > Thank you. > > 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. > I agree. > > 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. > Maybe. The idea might be appealing, since it's always nicer to start with a clean house. However, I think it will also take the longest time to accomplish, and much of it is re-inventing the wheel. It takes time to develop a stable compiler, it takes time to get cross-platform language features ironed out in a conform way, it takes even more time to get all the GUI features working in a stable way across runtimes. Many of these stumbling blocks were dealt with by the haxe compiler, and what I personally feel the haxe community can bring to the flex community, is a general experience in making libraries work on other runtimes. > > 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. > Writing a compiler is even less trivial. For the 95 percentile, porting AS3 to haxe is trivial. I have ported large and complex AS3 libraries (25-30K LOC) to haxe in a matter of weeks, other haxe community members have too. Some of those exclusive AS3 features you mention could be emulated/implemented using haxe's macro feature. I would be surprised if you said not having global functions is a blocker. The biggest problem mentioned is e4X. Though, if you were to write your own compiler and insist upon e4X, you would need to implement e4X in javascript for non-mozilla browsers, which I think is quite a bit harder to get right in a performant way than to take a step back, and think about a more cross-target solution. 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. > haxe supports swc files, there are a number of projects that can combine these (hxswfml, samhaxe, swfmill) which in my mind is what is meant by flash modularity (though, I admit, I only use flash to port it to javascript). If you use your own compiler or falconjs, you would still need to implement your own javascript modularity functionality. In comparison, some recent haxe code can read swf files to pull assets out, I'm not sure what could be done about code. Regarding compile speed, the compiler is fast, if you are invoking the compiler more than once, then there is something wrong your project setup. The exception to this is macro heavy code, which invokes the neko interpreter during a compile phase and is noticeably slower. 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. > Code conditionals are generally used at a package level, you can avoid it altogether by simply redirecting a package subtree to another one at compile time, depending on the target (this is what jeash does). > 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, but that's all very political, and IMHO ignores proven technical advantages, time-to-market considerations, and the fact that you still have to convince your clients that your new compiler is better than adobe's one too. - Niel > 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. > >
