On Feb 20, 2012, at 8:45 AM, Niel Drummond wrote: > 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...
Just wondering. Concerning ruling out Haxe. did you look at jeash and nme? I didn't see those on this list yet when people talked about haxe. http://jeash.com/ haxe --> html5 not sure but might solve some performance concerns with default haxe to javascript "settings" http://www.haxenme.org/ implements the flash displaylist api (most part) and can deploy to c++ / neko / html5 / ios / android ... heck we might even map starling on nme to use stage3d api's when deploying to flash. both nme and starling implement the flash api (more or less) so seems possible. nme seems a rather mature framework and is there for 4 years now, MIT license and is actively developed. I'm by no means a compiler guru, but it seemed that this option is overlooked. so i guess i'm still wondering if "flex 5" could be faster realized by building a mxml parser on top of haxe. The Haxe language seems very nice to me. > 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 Met vriendelijke groet, Arnoud Bos Artim interactive E arn...@artim-interactive.nl W www.artim-interactive.nl T +31 6 246 40 216 A Elisabeth Wolffstraat 77-3 1053TT Amsterdam
