Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of sebpatu.flex@gmail.com
 designates 209.85.214.47 as permitted sender)
Message-ID: <508525FE.9080105@gmail.com>
Date: Mon, 22 Oct 2012 12:54:54 +0200
From: =?ISO-8859-1?Q?s=E9bastien_Paturel?= <sebpatu.flex@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: flex-dev@incubator.apache.org
Subject: Re: Starling + Flex
References: <CCA9E5B8.47788%aharui@adobe.com>
In-Reply-To: <CCA9E5B8.47788%aharui@adobe.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Thanks a lot Alex for sharing this,
thats such a discussion im looking for in the ML :)
i hope many commiters will join in

* "performance penalties on the new target"
its obvious, and you always have to choose between performances and ease 
of deployment

* "granularity and extensibility ... two things are what folks want to try to do to the current framework, but it is a big mess to untangle."
What is the state of this discussion among commiters today? If i understand well, there is no consensus yet, and some are still trying to find a way to make it possible?

* "But to me, right now, it is the ability to take some MXML tags, add some AS3 code and create an app."
So you would still keep AS3? starting over, can be the perfect time to question the viability of such a choice?
Regarding the essence of flex, i would add that its also a great set of high level components.

* "backward compatibility, I think you have to give up on 100%"
I know but theres room between 100% compatibility and complete rewrite with new language and new API.
The only thinkg i want is to get the multi target effort, the more productive as possible.

* "get some bare-bones Flex-like framework up and running short-term, and grow it long-term.  If we get enough community involvement, it may gain most of the things you miss from the existing framework."
I don't personnaly think that its a short term need either. if there is a transition plan with current Flex SDK for short term, and new SDk for long term, which will get as close to current flex as possible in term of needed features, its great plan for me either.
I was not worrying about short term for current flex until this new VM thing. I thought that flex could still use the Adobe's runtime for new device surfing on their Gaming shift, and with it, having the time to prepare the future even if it means to start from scratch.
If following Adobe's runtime for short term means to rewrite to AS4, its not an option. If it means to render on starling, it seems still realistic if i understand well.

* "a new Flex framework that has most of what the current Flex framework has"
If its realistic plan thats fine for me. Regarding the amount of work put in Adobe's flex, we will have to be quite creative to get the same features with less coding effort.
One of the drawback to start from scratch is that you will probably losse all the surrounding efforts like third party components and libs, or all the documentation and help forum threads.
and that is an issue if you keep the same name for a very different API.

* "not go all-in on the new framework"
I understand, my question was a bit stupid.
I just want that there is deep discussion about this subject, and that we see the feedback in ML.

* "Hopefully, we don't need to get that close to what Flex currently has in
order to be succesful."
I agree, thats more a matter of transition, like i said previously.

* "I'm not sure what your definition of "efficient" is.  If it is developer
productivity, then you certainly have a point.  I think the main draw of
Flex is that you can crank out an app pretty easily"
Thats exactly what  meant :)

Thanks

Le 22/10/2012 02:47, Alex Harui a �crit :
> On 10/21/12 1:01 PM, "s�bastien Paturel" <sebpatu.flex@gmail.com> wrote:
>
>> AVMNext may not worth it, but any other target would.
>> So you are saying that trying to patch the framework is too much hard
>> work to get it run on other targets?
> In the history of computing, I'm not clear there has ever been a 100%
> foolproof migration tool, at least one that didn't pay performance penalties
> on the new target.
>
>> And you'd better try to write a new one from scratch?
> My current thinking, which could certainly be completely reversed by what I
> learn over the next few days, is that you need to design for multiple
> targets in order to know what features of certain targets cannot be relied
> upon or over-used.
>
> IMO, any new framework would be simple, leverage as much of the target
> platform code as possible, and have granularity and extensibility via
> composition as primary principles.  The latter two things are what folks
> want to try to do to the current framework, but it is a big mess to
> untangle.  When you start over, you get to question how important every line
> of code is and whether what you are bringing over is in need of a re-design.
>> But why would it still be called Flex if it has nothing to do with
>> previous Flex SDK, and if it does not have backward compatibility etc
> Well, this is a better question for the "What is the essence of Flex"
> thread, and I hope to get a better sense of that from everyone on the list
> as we get feedback for any proposals.  But to me, right now, it is the
> ability to take some MXML tags, add some AS3 code and create an app.  But
> how important is, for example, skinning vs styling?  Accessiblity? What else
> couldn't you live without?
>
> As far as backward compatibility, I think you have to give up on 100%
> backward compatibility.  We have proven that most of you can learn Spark
> after MX so 100% compatibility is not required.  And yes, a proposal should
> try to leverage as much existing knowledge as possible, but performance on
> the target is actually more important.  And maybe some key features like
> accessibility.
>
>> Nothing could be used back from actual Flex, it would be such a waste,
>> and too much work to get back in the race of every other mature
>> frameworks...
>> Why would it even be written in AS3?
>> And without AS3 or easy transcoding solution, all previous Flex projects
>> already written have no future.
> I honestly don't see a way to magically transform existing Flex apps onto
> other targets in the short-term.  And I'm not sure if we have to have it
> long-term.  My current thinking is that we get some bare-bones Flex-like
> framework up and running short-term, and grow it long-term.  If we get
> enough community involvement, it may gain most of the things you miss from
> the existing framework.
>
> One way of thinking about is this:  If you have a large Flex app and want to
> target other platforms, how much work will it be to rewrite it in some other
> language and tool-chain, vs "re-write" it on a new Flex framework that has
> most of what the current Flex framework has?  And if this new framework
> turns out to have benefits for new projects in terms of developer
> productivity, then we can even attract new developers.
>> And why is the community still waiting for every other Adobe's donation,
>> or trying to make mustella work if there's no future in all that?
> While all of this future talk is quite interesting, I am told that there are
> still a bunch of folks who are updating existing Flex apps and even starting
> new ones who desire bug fixes, performance improvements, and new components.
> The next series of Apache Flex releases should help these folks, and my
> current plan is to spend some portion of my time on these short-term issues
> and not go all-in on the new framework.
>> i'd love to get other commiter's vision of flex future.
>>
>> Alex, i 'll try to wait your detailed explanations after 360Min, but do
>> you really think it's realistic to start a new framework from scratch,
>> regarding all the hard work needed to get any close to what Flex offers?
> Hopefully, we don't need to get that close to what Flex currently has in
> order to be succesful.
>> I feel that everything is going back in time. We're not talking about
>> abandoning an old technology, to get new modern and better one, we're
>> talking about abandoning a very efficient technology, with no
>> alternative with the same level of possibilities.
> I'm not sure what your definition of "efficient" is.  If it is developer
> productivity, then you certainly have a point.  I think the main draw of
> Flex is that you can crank out an app pretty easily.  But the code base is
> 10 years old, and I see lots of bad infrastructure in it and stuff that will
> be hard to make work on other targets.  When I watch a Flex app startup in
> the profiler, I see anything but efficiency.  I've tried to refactor
> UIComponent and found it daunting.  I've tried starting over and found it
> promising.
>