incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Hart <jonathan.h...@gmail.com>
Subject Re: Cross-compiling Flex to HTML5/Javascript (Was : Update on Falcon donation)
Date Wed, 29 Aug 2012 01:30:49 GMT
Hi all, this is my first post here..

I would recommend (if you have some time to kill) watching this deep
dive on the Flash player rendering engine:

http://tv.adobe.com/watch/max-2010-develop/deep-dive-into-flash-player-rendering/

After seeing what goes into rendering in the flash player, it would
become quite obvious how FalconJS would prove to be challenging to
provide something on par. To get complete coverage of the drawing API
would be pretty much impossible.

This is my own opinion, but the cliche Maslow's Law of the Hammer
seems to ring true here. There are a lot of very optimistic and
enthusiastic people who are convinced HTML5/JS is the hammer and
everything that you can poke on a screen is a nail. This is a false
hope, as the technology has fallen far short in (somebody's) promise
of good performance, cross-browser consistency, etc. The list goes on.

I'm not saying FalconJS doesn't have a place somewhere, to someone,
but considering Adobe has stated that its primary focus for AS
scripted content will be focused on games and mobile, FalconJS will
not see much adoption in those industries because of its
inappropriateness for game development and its poor performance on
mobile (I refer to Facebook's recent ditching of its HTML5 iOS app in
favor of a natively written one as an example of people abandoning
HTML5/JS).

Jonathan


On Tue, Aug 28, 2012 at 6:10 PM, Gordon Smith <gosmith@adobe.com> wrote:
>> if I were to create <js:FancyButton> where would the specialization code go?
 In JavaScript or ActionScript?
>
> I had in mind writing in a subset of ActionScript that cross-compiles cleanly to JavaScript,
which is basically the idea of FalconJS. But, not having worked on FalconJS, I never understood
what it did with Flash classes like Sprite that are implemented in native code in the player.
>
> - Gordon
>
>
> -----Original Message-----
> From: omuppi1@gmail.com [mailto:omuppi1@gmail.com] On Behalf Of Om
> Sent: Tuesday, August 28, 2012 5:46 PM
> To: flex-dev@incubator.apache.org
> Subject: Cross-compiling Flex to HTML5/Javascript (Was : Update on Falcon donation)
>
> On Tue, Aug 28, 2012 at 5:00 PM, <teotigra@teotigraphix.com> wrote:
>
>> IMHO, problems like this are best solved with some type of framework
>> that creates a high level abstraction, where you are taking the load
>> of the generation and putting it into the API that the generator implements.
>>
>> I think in the past, there has been to much talk about emulating as
>> you say Gordon, instead of actually solving problems that relate to
>> the future development of applications using new technology and platforms.
>>
>> I really doubt a project like this would last or survive trying to
>> emulate anything. It needs to solve a problem and be written from the
>> ground up solving that problem.
>>
>> My point is, what is the end result in HTML5? To find it, work
>> backwards from something you want in HTML to the implementation in
>> ActionScript and the cross compilation API.
>>
>>
>> Mike
>>
>>
>> Quoting Gordon Smith <gosmith@adobe.com>:
>>
>>  My personal opinion is that outputting to HTML5+JS+CSS could make
>> sense
>>> if ActionScript is restricted to the subset that maps well to JS and
>>> if you don't try to emulate any flash.* APIs. There is nothing about
>>> MXML that is tied to DisplayObjects, for example. Instead of writing
>>> <s:Button> and having it make me a DisplayObject-based Button where
>>> DisplayObject is implemented using HTML5 Canvas APIs or something, I
>>> would want to write <js:Button> and have it make me a new Button
>>> component that is implemented using HTML5 drawing APIs directly. I
>>> think the approach of emulating one API with another is generally
>>> filled with gotchas that frustrate developers, because there is too
>>> much mismatch and the emulation isn't complete enough.
>>>
>>> - Gordon
>>>
>>>
>>
>>
> This would work fine if Flex is just MXML.  But the power of Flex is to be able to use
ActionScript to create custom components that can be used in MXML.
>
> From your example, if I were to create <js:FancyButton> where would the specialization
code go?  In JavaScript or ActionScript?
>
> I am not sure if JavaScript, then this means that we are not really creating a Flex app.
 What is the point of creating the app in Flex?
>
> If it is ActionScript, then we need an AS to JS translation layer.
>
> IMO, the biggest drawback of HTML5 is the lack of extensibility [1]  If we tie MXML to
HTML5, then we run the risk of losing extensibility in Flex.
> Instead, trying to emulate AS in JS, even though a harder problem to solve, will probably
take us further.  Which I believe was the reason that FalconJS took the approach it did.
>
> But I agree that staying away from trying to emulate flash drawing api would be a good
idea.
>
> [1] http://www.alistapart.com/articles/semanticsinhtml5/
>
> Thanks,
> Om

Mime
View raw message