incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sébastien Paturel <sebpatu.f...@gmail.com>
Subject Re: What is the essence of Flex? its future and the Next runtime
Date Fri, 19 Oct 2012 15:35:36 GMT
I'd like to complete my thoughts:

Flex is a framework, not a runtime, not a language (except for MXML maybe).
The strenght of flex is the features, the architecture, the components, etc.

So i see 3 area of work to ensure a bright future for flex as a multi 
target SDK.

1- the modularity of the architecture:
     Everyone seems to agree on that one. For multi target strategy, we 
need to be able to disconnect some parts of the framework unsupported by 
some specific targets.
     As we need to be able to have a lightweight SDK when we don't use 
every features of it.
     The break of UIComponent seems also needed to be able to more 
easely change the rendering layer. Maybe i am wrong?
     Did some work or discussions have already been done on this? as it 
seems there is a consensus on this point.

2- rendering layer.
     In a multi target strategy, we cant rely on the flash player 
Display list rendering anymore.
     We need to target new layers like straling2D? openGLES, HTML5 Canvas...
     What does it mean to do so exactly? what is the amount of work?
     Some research has been done to try to target starling2D, what is 
the state of it? what are the remaining issues?

3- the transcompilation, or the trans coding of the framework.
     as targets have different languages, and some have interpreted one, 
and some targets don't allow plugins, we can't rely on a VM anymore.
     the sdk has to be transcompiled to several bytecodes or interpreted 
languages.
     Falcon will be very helpfull for that.
     The first step already undergo is the MXML support, FalconJS is 
already on his way to be donated. let's see what the next step will be. 
Next runtime bytecode?

Questions are:
- Do we have a clear view of what tie the Flex SDK to the Adobe's 
runtime, and need to be handled for a multi target strategy? in the 
rendering layer but also everything else?
If we identify clearly what are the difficult points, it would be more 
easy to take decisions, of what can be dropped (like e4x) and what need 
a solution.
It seems that the work on FalconJS has already given a good start on 
such information.
Can we have a clear list of such issues?

- How difficult is it to change the rendering layer? Is the current sdk 
architecture a break to make it easely possible to do? Do we have to 
rewrite from scratch a Display list system without all the optimization 
that Adobe put on the flash player one? Does starling2D give a good 
solution for that purpose?

- Is it realistic to think about using Falcon to change the codebase 
language of flex to another? I mean to transform flex from an AS3 
framework to another language framework of the community choice, like 
Dart, or C# or whatever. And be able to work on this generated code, not 
only for transcompilation purposes.
I mean we may need it in a near future to ensure a successfull multi 
target strategy. (im still not sure of this need though but im trying to 
see if its a realistic option to keep in mind)
Its still more realistic than talinkg about starting a new framework 
from scratch.

As a conclusion:
There were several discussions about the multi target essence of flex, 
and HTML5 target especially. but no conclusion has been given. no clear 
view of what it means to change target and get out of flash player runtime.
Lets use this flash player Next subject to clarify it.
I think that getting a better understanding of what commiters have in 
mind regarding those subsjects, would give away some of the frustration 
(see 'Is Apache model killing this project?' discussion). I'm not 
talking about roadmap, but at least a vision of what flex future should 
be, and what it needs to get there.
And giving more precise informations of what the difficult points are, 
what is possible and what is not, would get the whole subject broke in 
several smaller projects, in which some little groups (or even 
individuals) of the community could get confident enough to work on it.
Flex is a big beast, so the answer "do it yourself and we will check it 
later" will get us anywhere. We'r not talking about a new component, but 
big architectural choices and changes.
IMO the community needs some clarification, and some smaller issues, 
smaller projects, but included in a global consistent strategy, to be 
able to contribute.
That was also my answer to the 'Is Apache model killing this project?' 
discussion.

Thanks
Regards,



Le 19/10/2012 14:59, sébastien Paturel a écrit :
> Thanks Gordon for asking about the nature of Flex.
> Flex is a RIA sdk and not a gaming SDK, ok thats quite obvious.
>
> But flex must be multiscreen ! and if flex don't run on all screen it 
> has no future!
> What has put Flex in a difficult position last month is the fact that 
> HTML5 could not be targetted!
> What has kept Flex alive is to be able to create apps for iOS and 
> Android with the same mature framework.
> And what can give a bright future to Flex is to be able to target as 
> much screens as possible, again, including HTML5.
>
> So lets define a multiscreen strategy here!
>
> Today:
> Flex is multiscreen because it runs on Adobe's Flashplayer and AIR.
> One of its big strenght is to be able to create apps for Desktops 
> (starting from flash player 10 which has unbeatable ubiquity thanks to 
> the monopoly of flash player on the video streaming area), smartphones 
> and tablets, including  iOs AND android.
> but it can't run on HTML5. Its not a big deal yet because HTML5 is not 
> mature enough (performances) and the user usage is not much on the 
> webapp area yet, so native apps is the place to be for now.
> It can't target linux well since AIR runtime will not target it 
> anymore, and flash player is not quite stable. Its sad but its not big 
> deal as an economic point of view, as theres not much users on it.
> Thats what makes Flex still a rationnaly good solution nowadays, even 
> in an HTML5 hype world.
>
> Tomorrow:
> If there is new mobile hardwares smartphones and tablets, Adobe will 
> probably target it with its runtimes, but according to its new 
> strategic shift it will be with the new gaming runtime only!
> So flex won't run on those new hardwares even being based on Adobes 
> runtimes, if we do not port the framework to this new runtime 
> architecture! Am i wrong?
> It would kill Flex for mobile, as a viable commercial solution.
> So if the port to new Adobe runtime is a manageable amount of work 
> (threw starling2D), i think we should do it for this reason.
> If we need to change architecture of flex sdk for it (more modularity 
> and break the UIComponent as everyone wants to), lets start with it 
> anyway.
> In that case Flex would still rely on Adobes runtimes for multiscreen, 
> but being inline with the new Adobe strategic shift so it would give 
> the project more time to be able to run on Adobe's free runtimes.
> And being based on a stage3D renderer, would make the future shift to 
> openGLES more easy. Am i wrong?
>
> Near future:
> IMO the goal is that:
> Flex target openGLES and native runtimes of all mobile hardwares. My 
> personnal dream is to be able to target all screens including smart 
> TVs and gaming consoles (but for RIA apps dev)
> Flex target HTML5 which has become mature and viable for serious RIA.
>
> In conclusion,
> The first priority for flex IMO is to stay multiscreen.
> targetting HTML5 is big priority but in a long term.
> targetting new coming mobile hardwares is big priority in short term!
>
> The final questions are:
> is it really a more rapid solution to target Next Adobe's runtime as a 
> first step before being able to target any new mobile native runtimes 
> (threw openGLES directly) or not?
> And what we need to change first in the framework to make it possible?
> Do flex need a language port to stay multiscreen? stay with AS3? AS4? 
> Dart? Haxe? etc.
>
> I'm eager to read your thoughts and arguments, pro and against.
> Thanks
>
>
> Le 19/10/2012 01:28, Gordon Smith a écrit :
>> Yes, the community has to figure out what the essence of Flex really 
>> is. To me, it's an rapid-development application framework, the 
>> combination of a procedural language with a declarative language, and 
>> a widely-deployed runtime that can support RIAs. The runtime of the 
>> future for RIAs seems to be native code for mobile devices and 
>> HTML/Javascript for browser apps. The best procedural language is 
>> anything that can be compiled to these runtimes. MXML is a perfectly 
>> good declarative language for UIs.
>>
>> - Gordon
>>
>> -----Original Message-----
>> From: Michael A. Labriola [mailto:labriola@digitalprimates.net]
>> Sent: Thursday, October 18, 2012 4:07 PM
>> To: flex-dev@incubator.apache.org
>> Subject: RE: ASC 2.0 and Falcon
>>
>>> PS I don't think Apache Flex needs to stand for what Flex is today 
>>> though, and this is where innovation in the future needs to happen 
>>> in this project.
>> +65535
>


Mime
View raw message