Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of sebpatu.flex@gmail.com
 designates 209.85.215.175 as permitted sender)
Message-ID: <50A7D0F4.9020802@gmail.com>
Date: Sat, 17 Nov 2012 19:01:24 +0100
From: =?UTF-8?B?c8OpYmFzdGllbiBQYXR1cmVs?= <sebpatu.flex@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: flex-dev@incubator.apache.org
Subject: Re: What to expect from FalconJS
References: <CCCCF5B0.48A80%aharui@adobe.com> <50A7C08E.4080505@gmail.com>
 <CAK1VXSoAnOHR3m_XM=Bm9L4hYhaAScJqEJNt68JU0AjOCTmCjw@mail.gmail.com>
In-Reply-To: 
 <CAK1VXSoAnOHR3m_XM=Bm9L4hYhaAScJqEJNt68JU0AjOCTmCjw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

it depends.
if the plan is to fully transcode flex app in HTML/JS and then use 
cordova to make it run as native app, yes i have reasons to think that 
it will have poor performances, because in the end it is still an 
HTML/JS app.
if you only use this path for UI, and managed to transcode the logic in 
a real native code, why not.
If separating the UI management make the cross compilation more easy, 
maybe it can be a viable solution. but it gets back to the question "how 
can you cross compile AS3 to native code".
And haxe made the choice to change AS3 language to make it more easy to 
cross compile. it means that it is not easy task.


Le 17/11/2012 18:08, Joan Llenas Masó a écrit :
> I'm not Alex, but IMHO taking into account that most UI code will have to
> be written natively for each output target and that UI code tends to be the
> main bottleneck in nowdays apps there's no reason to think that this new
> system would output very poor performant code or bytecode.
> Also, for very performance intensive business operations (I guess) we could
> do the same as with UI code and create native versions and execute them
> through narrow interfaced proxies.
> Same philosophy as Randori I'd say.
>
> Cheers
>
>
>
>
> On Sat, Nov 17, 2012 at 5:51 PM, sébastien Paturel
> <sebpatu.flex@gmail.com>wrote:
>
>> Hi Alex,
>> do you also have in mind to use HTML/JS as main output before cross
>> platform achievment (for example using Cordova)?
>> if so, don't you expect very poor performances with this strategy?
>>
>>
>> Le 17/11/2012 17:05, Alex Harui a écrit :
>>
>>
>>> On 11/17/12 2:47 AM, "Joan Llenas Masó" <joan@garnetworks.com> wrote:
>>>
>>>   I think I'm able to get your point after watching these slides and mixing
>>>> it together with what you mentioned earlier on in another thread.
>>>> So instead of going through direct UI AS3->{MyOutputTargetOfChioce}
>>>> translation we just concentrate our efforts in the business logic code
>>>> translation AS3->{MyOutputTargetOfChioce}.
>>>> The views on the other hand are implemented natively in the language of
>>>> choice, being it AS3, JS or whatever.
>>>> Finally MXML comes to rescue giving us the power of componetization and
>>>> view declaration.
>>>> This way we can implement same set of components for different output
>>>> targets but declare them in the same way.
>>>> FalconJS will take care of the rest.
>>>>
>>>> Am I right? or did I make my own movie...
>>>>
>>> Believe me, my vision and prototype is not completely thought out.  I'm
>>> depending on the rest of the community to help steer and create, but I
>>> think
>>> that you have the basic idea that I have in my head.
>>>
>>>> Anyway, I see maaaaany advantages here. Wow, I love it. This is actually
>>>> the essence of Flex taken to the next level :)
>>>> Well, I see Haxe fitting here as well. Actually we could plug many
>>>> packaging tools in the FlaconJS "output port".
>>>>
>>>>