On 11/21/12 3:49 PM, "sébastien Paturel" <sebpatu.f...@gmail.com> wrote:
> If you consider Cordova only as short term answer, for POC achievement,
> thats ok for me.
Cordova will be around long-term if it proves viable for enough people.
> But its not viable as a final solution, because it would be giving up on
> great performances for native apps compared to native code usage directly.
It isn't guaranteed that any solution we do that has multiple targets
wouldn't have extra overhead in its abstractions.
>
> We have to find out how much work it really is to create something like
> FalconJava. If its not much time of work, its ok, if not, its a big
> weakness against Haxe which has already a great background and decent
> community around it!!
> But moreover, you'r talking about FalconJS, FalconJava etc but if i
> understand your strategy it will be needed only for Logic code right?
> But the big performances killer on mobile is more on the UI side if i'm
> not wrong. especially when you compare HTML5/JS with Flash.
> And targetting a new device, does not mean only to get FalconNewLanguage
> but also the MXML transcompilation to the new native UI runtime. And i
> believe that its the biggest amount of work for each new target.
I'm not planning on transcompilation of MXML.
>
> If AS3/Cordova POC and Haxe POC are two satisfying results.
> What do you thing of keeping both?
We can certainly keep both.
> As we are starting from scratch, its not so hard to keep synch of two
> code base with two different languages (but very similar. using
> automatic tools to do at least half of the translation).
> With such a dual solution, we can use the best of the two solutions for
> our needs.
>
> I still don't understand why you say that if we don't use AS3, current
> flex users would have wider choice.
Because if I offer a solution that doesn't require porting your existing
code you might be willing to accept other tradeoffs. But if you have to
port, you will then look at all frameworks.
> We are all pushing flex future, especially because there is no mature
> alternative that can really compete with flex.
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui