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.f...@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ó" <j...@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".
>>>
>>>
>
