Rudeness and frustrations aside, in the light of desiring an html/javascript flex SDK and taking into respect the timeline for a flex (cross?)-compiler there really is only three options on the table:
1) Wait for falcon, projected stable release late 2012, early 2013. It is both hopeful and debatable whether it will have a JS backend (correct me if I am wrong), and even if it does have one, developing the flex SDK system around HTML and accommodating low-level browser graphics libraries will actually be more work than writing the compiler in the first place - so realistically nothing ready until 2014? 2) Write a cross-compiler for flex from scratch. A venerable idea, but it does take years to develop a mature compiler, it needs a development leader capable of pulling it through (is there one here?), and again, you still need to develop the SDK around it, which is arguably more work than the compiler itself. Take a look at, for example, Jetbrain's Kotlin - a fully funded open source cross-compiler (JVM, javascript), which after one year is in beta. 3) Port the SDK to haxe (or build a converter), take advantage of the experience of developers and maturity of libraries that have been cross-compiling half a decade before you thought it necessary to do so. It's not a trivial task, but it is less trivial than writing a compiler from scratch, and has a less uncertain future than hoping for FalconJS. Most of the work will be building the flex SDK around an HTML/javascript output, and the timescale for the first releasable code is probably within about half a year. IMHO, if you want a JS backend, with a marketable HTML/javascript flex SDK by the end of the year, something you can read in the papers with a headline of "Apache made Flex HTML5 ready!", then you actually do not have any other option than to go with (3). From a purely product marketing perspective, and taking into account that the apache flex community is dedicated and willing to move the SDK to a new runtime (is it?), it doesn't make sense to do anything else. If you go with (1), you are running the risk that you will not get a javascript backend, and even if you do, the time to market is in years. It really only makes sense if you do not care too much about javascript, and wish to place your bets on a continued AVM existence. If you go with (2), you run the risk of never completing the compiler before Falcon is released, potentially splitting the flex community, and not being able to concentrate the full open source work potential on an HTML/javascript flex SDK. It's obvious to me, reading through the archives, that (3) is not a serious option, which I deduce as a half-hearted willingness to target javascript... which is fine, but it should really be made clear that a javascript flex SDK _will not be anytime soon_ unless you take a more drastic approach. - Niel
