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.f...@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.
