Adobe said in the public they will donate falconjs and I believe in that (please observe that they are very cautios with all of the promises recently), you can observe the progress on the blog:
http://blogs.adobe.com/bparadie/ For me it looks very promising regarding compilation of pure AS3 -> JS with rendering. As you said falconjs is just compiler not the solution to migrate / enhance legacy system without some rewrite / refactoring to target HTML5. As many of you know there is openlaszlo which since years has dual output, we can take the knowledge of limitation of dual output from them. In my opinion we The Community, should press the adobe falconjs team to give more light on strategy of rewriting the framework in order to release FlexyFlex ;). There should be public discussion of what to do in order to refactor the framework. Which parts of thechnology should be abandoned from framework (i.e. pixel bender, flex video?), which should be downgraded (FXG -> SVG?), which should be refactored (TLF?). I believe that if we have more ligths from adobe, then the community can together with Alex and other adobe engineers (they know the internals of flash player -> flex framework, we know mostly only the Flex API) construct the strategy to refactoring. Then when falconjs is out we will have at least FlexyFlex in alpha state, and with known limitations to current legacy systems / workflows. In that way we can save months. In paralell there is place for supporting the single, rich Flash Player only based branch with new mature spark components (DataGrid, MenuBar...). Just my 2 cents. 2012/2/20 Niel Drummond <niel.drumm...@grumpytoad.org>: > 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 leaderIn > 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
