We could discuss for hours about the technical aspects of the Flash Player and how well Flex integrates with it, however there's one thing that is not going to change: - Customer Perception.
This very fact is key to decide the future of Flex because nobody wants to use a technology that no one wants to "buy". Statistics have spoken for a few years already: - Google trends: http://www.google.com/trends/explore#q=%22adobe%20flex%22%2C%20%22javafx%22%2C%20HTML5%2C%20RIA&cmpt=q - Indeed: http://www.indeed.com/jobtrends?q=%22adobe+flex%22%2C+javafx%2C+html5%2C+ria&l= I have been working with Flex since 1.5 and demand has lowered drastically within the last 3 years. The message is loud and clear: - FLASH PLAYER IS FOR GAMES. - ADOBE IS NOT COMMITED TO FLEX ANYMORE. - HTML5 DOES THE SAME AS FLEX. We know it. So, in order to make Flex a sucessful technology we have to decouple it from the Flash Player. It doesn't matter if we do that via Haxe, C# or AS3. We must prove to our customers that Flex is a technical solution that has embraced Flash Player, but is so good and so well known that we can port it to other runtimes without loosing any of its advantages. As I said in another thread Flex to me is: 1. cross browser/platform 2. MXML 3. Modularity 4. Spark architecture I see all those 4 dots satisfied with Flash player, HTML5 and even JavaFX. It happens that Haxe satisfies those 3 runtimes at once. So for me it's the 1st choice at this moment. Cheers On Sat, Nov 17, 2012 at 12:29 AM, Nils Dupont <nilsfrompa...@gmail.com>wrote: > @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 > > > > > > > > >
