I'd like to be wrong, but i have serious doubts about the Cordova web
view rendering performances
"multiple targets wouldn't have extra overhead in its abstractions"
of course, but flex apps can have heavy UI work
"I'm not planning on transcompilation of MXML"
How you plan to use MXML?
Le 22/11/2012 01:18, Alex Harui a écrit :
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.
