@Gordon ActionScript 2.0 was introduced in 2004 and is still supported in Flash Player. As you say, AS3 / AVM2 will not disappear from one day to the other, and Adobe, also, was clear on this point. Maybe an average Flex application just doesn't need the new features that will be introduced in AS4 (gaming / GPU oriented features I can imagine)? Maybe AS3 is solid and mature enough for an average Flex application? Maybe here Adobe should communicate in a better way: AS4 will be the language dedicated to game development, AS3 will be the language dedicated to business application development. I think companies will have more and more interest in Flex if they see that new components are added very often by the community, that bugs are corrected in a decent delay by the community, that they can have a quick support on any point from an active community. For "mobile" oriented applications (smartphones / tablets), I really think that there is no "perfect" solution at the moment, except doing pure native applications for each OS. I would say that Flex is not so bad for doing an average business application on mobile. There are performance issues, of course, but I think in a near future (mobile devices are more and more powerful in terms of CPU), and with some optimisations on the framework itself, Flex can achieve a very decent work. As far as I know, there are 2 clear performance issues for Flex Mobile applications : 1) Big Lists + complex itemRenderers 2) Transitions between views Concerning point 1) it is very easy to implement a HTML List with StageWebView and to interact with it with Javascript, if ever the list is too big to be displayed properly by Flex List component (for example on last Ipad Retina screens). It would be maybe interesting to wrap this functionality in a new "StageWebList" component. Concerning point 2), there are more and more applications that don't use these transitions anymore (e.g. Twitter application) and even HTML5/JS applications perform very poorly on most devices. I even tested Starling+Feathers UI and the performance is also not so good compared to native applications list components. Except these 2 points, Flex is really not so bad to deploy business applications on mobile devices. And if we have to use captive runtime in the future, it is not a big deal in my opinion. To conclude, I am currently working on a big project done with Flex (mostly dedicated to desktop), and I do it with Flex because it would be a nightmare to do it with HTML5/Javascript, in the current state of these technologies (technologies that I know very well). I don't care to be able to target GPU for this project, I just need a solid and mature framework, and I'm very happy that Apache Flex is here now, because it gives me the hope that if I encounter bugs, there will be an active community to help me to correct them or to find workarounds with a shorter delay than before.
Nils 2012/11/16 Alain Ekambi <jazzmatad...@gmail.com> > @Gordon > We actually see an increasing interest in Flex/AIR coming for our > customers. > With the small team that we have we actualy cant keep up with the requests. > But i have to say we have a different approach to Flex development tho. > > > 2012/11/16 Alex Harui <aha...@adobe.com> > > > > > > > > > On 11/16/12 1:52 PM, "Fréderic Cox" <coxfrede...@gmail.com> wrote: > > > > > I'm glad Alex is here because I believe he does not only have > > > the experience but also great ideas where Flex should be headed. And he > > > might have been blocked previously by business decisions but now can > take > > > Flex to a even higher level. > > > > > Keep in mind that I'm the biggest proponent of the full re-write. We may > > still find a few performance mistakes in the current code (like the Chart > > styles init that just got fixed), but really, some very smart people have > > spent a lot of time on the current code and haven't found any easy wins. > > IMO, the framework is slow because lots of code is running just in case. > > This is especially true for mobile apps where you have the most > constrained > > runtime environment. The issue that came in today on the users list > about > > slow List performance I'm sure is in part due to TextLine being a bit > > slower, but probably more due to lots of other code running as well. > > > > Plus, as many have recently said, the intertwined code we currently have > > makes it hard for the volunteer to be successful in their spare time. > > > > I tried the big refactor and it was too difficult for me, but one of the > > main difficulties was the fact that there was lots of other development > > going on in the trunk at the same time and keeping my branch running was > > nearly impossible. It could be that there won't be as much active > > development in Apache Flex and a refactor branch will be manageable, but > > the > > other problem you run into is that every line of code is needed for some > > reason at some point, and you tend to start leaving code in. > > > > Starting over definitely has its risks, but I think it will have the best > > outcome. It won't make 100% parity ever and I'd shoot for 80% over two > or > > three years. But it will be designed to port to other platforms, and be > > modular so the volunteer has a chance of making a difference. > > > > -- > > Alex Harui > > Flex SDK Team > > Adobe Systems, Inc. > > http://blogs.adobe.com/aharui > > > > >
