incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niel Drummond <niel.drumm...@grumpytoad.org>
Subject Re: [gosh] Goshhawk language choices and more [Was: Adobe / Apache / Spoon Flex Tour]
Date Mon, 20 Feb 2012 07:45:23 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message