incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <>
Subject Re: Starling + Flex
Date Mon, 22 Oct 2012 00:47:36 GMT

On 10/21/12 1:01 PM, "s├ębastien Paturel" <> 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

> 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

Alex Harui
Flex SDK Team
Adobe Systems, Inc.

View raw message