Re: FalconJS has landed

Mon, 26 Nov 2012 03:11:05 -0800

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 avoided. 


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.

Best
Dan


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 <aha...@adobe.com> wrote:



On 11/24/12 3:42 PM, "Daniel Wasilewski" <devudes...@gmail.com> wrote:


And here is a little example of
the very nature of this problem:

http://jsperf.com/object-create-with-object-literal-vs-prototype

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 to.

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.
http://blogs.adobe.com/aharui



































					Reply via email to