Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <20121128191958.75295rv4wokzddta@teotigraphix.com>
Date: Wed, 28 Nov 2012 19:19:58 -0500
From: Michael Schmalle <apache@teotigraphix.com>
To: flex-dev@incubator.apache.org
Subject: Re: [FalconJS] concepts
References: <CCDBC556.492C4%aharui@adobe.com> <50B68DFB.2000004@gmail.com>
 <20121128172617.99734qine25om1zd@teotigraphix.com>
 <50B6979D.1040905@gmail.com>
 <20121128180855.49354x2ufd84t37r@teotigraphix.com>
 <CAD8jDGJJ8_4fgyM0M51poVwPEQXdu+hLLdE3V_rfX6YrAweFSw@mail.gmail.com>
 <20121128190659.43825l2988b3qqeb@teotigraphix.com>
In-Reply-To: <20121128190659.43825l2988b3qqeb@teotigraphix.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=ISO-8859-1;
 DelSp="Yes";
 format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) H3 (4.3.11)

I hate adding on to my own reply but I have on more comment on this.

As Dan and I were discussing and others as well, performance.  
Obviously browser execution is top most priority but what about the  
other performance not mentioned... the community contributions.

If you have something as complex as what FlaconJS is on the backend,  
with 1 maybe two part time developers to push it forward only because  
they are the only ones that understand it (JBurg, SWF). Then where  
does this actually leav the performance of the project as a whole?  
Dead locked in stale code as the months and years role by.

I'm usually not this passionate about something but, I think it would  
be a serious mistake to count on FalconJS in it's current  
implementation. I have years of experience in a different area then  
the professional engineers, which just means maybe I have a unique  
perspective here.

So bottom line is, I really think we need to think about whether the  
current js generation of js or whatever other platform we do is  
feasible to carry on into the future being maintained by developers  
that may not have a computer science degree.

Long story short, by not choosing the correct implementation of the  
cross compiler now, we could seriously be affecting the other  
performance area of this project in the future, lets not neglect this  
important area.


Go look at TypeScript's parser and emitters, they use the same visitor  
pattern using straight AST!

Mike


Quoting Michael Schmalle <apache@teotigraphix.com>:

>
> jangaroo/jooc/backend/JsCodeGenerator.java
>
> This is the exact pattern I was talking about implementing. I think  
> it's so solid and you have done a great job at implementing it.
>
> As I have said in previous posts today, The way FalconJS digests  
> it's AST is through SWF visitors. You are using straight AST from  
> your parser.
>
> Folks, having Frank drop this line and the discussions going on at  
> the moment, there are definitely a couple different paths that can  
> be taken with producing javascript.
>
> If I have my way we would use an implementation like Franks, the  
> problem with it as it stands in Apache is there is no infrastructure  
> built like Frank has built, this is why the engineers used an SWF to  
> represent that infrastructure.
>
> The problem with the current SWF/JBurg implementation is it VERY  
> confusing for most developers. With Franks implementation I was able  
> to understand what he was doing today within 20 minutes and could  
> jump right in and start coding things. With the current FalconJS  
> emitters there is no way that would happen.
>
> So, I would love to see if we could think about a common goal to  
> energize both projects and see where one could help the other. I  
> truly believe now by looking at the code BEFORE this post our  
> projects have the exact same goal but can do different things.
>
> Mike
>
>
>
>
>
>
>
>
> Quoting Frank Wienberg <frank@jangaroo.net>:
>
>> Hi folks,
>>
>> here is another "outsider" who would like to contribute to the JS runtime
>> format, if you are interested.
>> I am co-founder of the Open Source project Jangaroo, and as such have been
>> dealing with JavaScript-to-ActionScript-3 compilation for several years now.
>> In response to Bernd Paradies blogging about FalconJS, I blogged about
>> "simulating ActionScript 3 language features" extensively:
>>
>>   -
>>    
>> http://blog.jangaroo.net/2011/11/simulating-actionscript-in-javascript.html
>>   -
>>    
>> http://blog.jangaroo.net/2011/12/simulating-actionscript-in-javascript.html
>>   - http://blog.jangaroo.net/2012/01/simulating-actionscript-parameter.html
>>   -
>>    
>> http://blog.jangaroo.net/2012/01/simulating-actionscript-rest-parameter.html
>>
>> All described solutions are actually implemented in the Jangaroo Runtime,
>> which takes care of the code translated from AS3 to JS by the Jangaroo
>> Compiler coming alive.
>> In principle, we follow the "classic route", with the exception of how we
>> simulate private members: see the first two blog posts.
>> At first look the Jangaroo Runtime may seem overly complex to you, but it
>> does many more things (class loading / dependency management; class
>> initialization = execute static code at the right time; allow keeping
>> generated JS code and source AS3 code as similar as possible; automatic
>> method binding / correct "this", etc.), and the concepts described in the
>> blob posts also work without these additional features.
>> The Jangaroo Compiler is written in Java and has a separate code generator
>> (well you obviously won't need the parser) which might be worth having a
>> look at:
>> https://github.com/CoreMedia/jangaroo-tools/blob/master/jangaroo/jangaroo-compiler/src/main/java/net/jangaroo/jooc/backend/JsCodeGenerator.java
>> If you dare to use Maven ;-), it is really easy to play around with our
>> code generation: Just set up your own projects within minutes, starting
>> from an example project like
>> https://github.com/fwienber/jooflash-app-template or
>> https://github.com/CoreMedia/jangaroo-ext-as-examples .
>>
>> Greetings,
>> -Frank-
>>
>> Frank Wienberg
>> Software Architect & Jangaroo Evangelist
>>
>> *frank.wienberg@coremedia.com*
>>
>> * frank@jangaroo <frank@jangaroo.net>.net*
>>
>> CoreMedia AG
>> content | context | conversion
>>
>> Ludwig-Erhard-Str. 18
>> 20459 Hamburg, Germany
>> www.coremedia.com
>>
>> Executive Board: Gerrit Kolb (CEO), Dr. Klemens Kleiminger (CFO)
>> Supervisory Board: Prof. Dr. Florian Matthes (Chairman)
>> Trade Register: Amtsgericht Hamburg, HR B 76277
>> --------------------------------------------------------
>>
>
> -- 
> Michael Schmalle - Teoti Graphix, LLC
> http://www.teotigraphix.com
> http://blog.teotigraphix.com
>
>

-- 
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com