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.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".
