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. -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
