BTW is there any plans to support things like Margin in the Flex SDK since they can't be native in the JS anyways?
-Mark -----Original Message----- From: Alex Harui [mailto:aha...@adobe.com] Sent: Thursday, December 04, 2014 1:06 PM To: dev@flex.apache.org Subject: Re: Porting To Typescript/Javascript On 12/4/14, 5:08 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote: >You should take a look at FalconJX (same repo as Falcon): it is >designed specifically to be a cross-compiler that can compile to >various output languages. It sounds to me you are trying to re-invent >the wheel by starting from Falcon. FalconJX currently has code >branches that handle the various flavours of JS we're putting out, but >you can use those as the basis and your guide for creating a path that >will result in nice clear C# output. To add a bit more to this: The falcon repo has a compiler.jx folder that contains the FlexJS cross compiler. Inside it uses an Emitter to emit the AST into JS. IMO, it would be totally awesome to see someone create an Emitter to emit the AST into TS. Erik did get “all” of Flex cross-compiled into JS, so there may be things you can learn from him on that. My approach for FlexJS is a bit different: I believe that Flex needs a new API that is better suited for cross-compilation. There are some things in the Flash runtime that are painful or tricky to implement in browsers so the FlexJS API set simply tries to not use them. My vision for FlexJS is that folks will code in MXML and AS, and then choose a JS runtime library and output language as the target. We are building our own JS library full of widgets, but also have prototypes of libraries based on Jquery and CreateJS and hope to add others someday. And if folks would rather output TS instead of JS, that’s totally fine as well, so that’s why what you are working on is interesting to me. >> >> Anyway that's what I'm doing and if anyone is interested in the end >>result, >> let me know. Right now I have a question. While pouring over falcons >> source, I noticed comments where MXML "now gets compiled directly to >> bytecode". The comment goes on to imply that once upon a time, the >>compiler >> used to convert from MXML to Actionscript and then to ABC. Does anyone >>know >> anything about this and if so, can they point me to it? Thanks and all >>the >> best. >> The MXMLC compiler currently effectively generates AS and then compiles it. For Falcon, the design team felt they could improve compiler performance by skipping the AS generation and simply go straight to ABC, but also felt that there could be better/faster run-time performance if they had the option to generate ABC in ways that don’t directly map to AS. AFAIK, there is no hard evidence that it was the correct thing to do, and it will be interesting as more folks use Falcon whether they miss the ability to examine the generated AS, but my understanding of why things are the way they are. -Alex
