incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Wasilewski <>
Subject Re: FalconJS has landed
Date Mon, 26 Nov 2012 11:10:33 GMT
That's sounds promising. Having ability to specify grammar on output 
will give Falcon a lot more horse power.
I was pointing at HaXe JS output as an example, because it is the best 
(performance/footprint wise) out there.

However scope and chain of accessibility in JS slowing down a lot.
And they've decided to represent entire source structure exactly the way 
you have your namesapces in that source.
Each link of this chain is represented as an Object. It sounds like a 
safe solution to avoid clashes but it comes with a cost.
This is a biggest drawback of HaXe, but definitely something that can be 

There is another concept of extern classes that can be implemented 
directly in the output and Compiler can map the code on architecture level.
Eventually inject missing bits directly into it. Does Falcon could be 
adopted to this?

I wonder how Falcon will deal with a display list.
Is it going to be similar to the output of Edge? Or just Canvas based api?

I am having big hopes for Falcon as the only part of the hand-over 
process to be honest.
And not necessarily in conjunction of flex but as a pure AS3 - JS evaluator.


On 11/26/2012 10:48 AM, Erik de Bruin wrote:
> Hi,
> FYI, I'm working on an POC for using a Module Pattern combined with
> Google Closure annotations to get a Javascript class as close to AS3
> as I can get it. This might serve as a starting point for defining the
> FalconJS output.
> EdB
> On Sun, Nov 25, 2012 at 4:59 AM, Alex Harui <> wrote:
>> On 11/24/12 3:42 PM, "Daniel Wasilewski" <> wrote:
>>> And here is a little example of
>>> the very nature of this problem:
>> I must be missing something, but I don't see where the output code calls
>> Object.create().
>>> We don't know what future will bring, maybe they will go crazy and
>>> built-in jQuery interpreter in their browsers, or do more crazy things...
>>> I am not saying that current output is wrong, but did you consider
>>> different styles?
>> This is not my code or Gordon's.  Another engineer on another team put this
>> together very quickly.  I just made it appear to work before donation.  We
>> have no way of knowing what he did or did not consider, all we know is what
>> is in the code that was donated.
>>> Or at least have a choice to spit out a code in the
>>> way you can configure, specify some rules of AST?.
>> I think you can change the code there, but I don't see any config options
>> other than it appears to be able to hook into Jquery.
>>> Take a look at HaXe
>>> output for instance.
>>> I don't care if the output code is ugly and messy. What I do care about,
>>> is that this very code is the best performer. I am writing AS3/Flex code
>>> for clarity and speed of production, and what I expect is the best
>>> performance on the other side. No more slow downs and bloated stuff.
>>> Because it will only tell people, pick one of the native JS framework if
>>> you need to develop RIA application for HTML5. The last thing Flex need
>>> is reputation of over-bloated stuff on the future platform of the web.
>>> Do this the best way, or do this well enough otherwise don't do it at all.
>> Well, that is all in our control now.  I will say that there is a good
>> chance that the final output won't be the absolute fastest as we are
>> translating from AS to JS so there is likely to be some impedance mismatch
>> there.
>> For example, it appears that the current code has chosen a fancier
>> inheritance scheme than the bare bones object.prototype pattern, potentially
>> to allow for class reflection kinds of stuff.  I'm not sure how much this
>> costs us and whether we truly have to have it.
>> I also noted the output code calls newObject in certain cases.  I'm not sure
>> if that is done for object pooling or memory management or for some other
>> reason.  The adobe.js file I checked in was written by me and only has
>> enough code in it to make my demo run.  I have no idea how much other
>> infrastructure was actually behind those calls.
>>>>> 2. adobe.extend / adobe.classes? shouldn't be apache?
>>>> Well, it shouldn't be "adobe", but I'm not sure what we should change it
>>> If apache sounds too general maybe just flex? Keep in mind that
>>> apache.flex.classes will destroy performance a bit, yeap that's what JS
>>> is about, shallow water ;)
>> I left it as "adobe" until we argue over what to call it and make a
>> decision.
>>> Dan
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.

View raw message