Well I dont agree with this. If we narrow down the discussion a bit and just talk about Flex apps in the browser, then as far as I know there are only two usable ways of running apps there, via Flash player or as HTML/JS. One way depends on Adobe technology and the other on the implementation of HTML/JS by several browser vendors who arent always the best of buddies so to speak. One tech is tried and tested and just plain works pretty well, the other one is undergoing heavy development and has a long way to go before reaching the same maturity as the first one.
There has been talk of performance problems with Flex/AS3 and allthough I have not had such problems myself I'm sure there are some. But do people seriously think that these problems will get better by compiling to Javascript? Have you heard of Dart? It is the language that Google created as a JS replacement because JS sucks for anything other than small projects. Also, when Steve J started his crusade against Flash on the iPhone, part of the argument was HTML5 is so good you can do anything with that, that you can do in Flash. Fast forward a few years and the reality is almost all mobile apps are native apps, not web apps. Some think that will change eventually, I don't. So while the "HTML5 can do it all and Flash player is a bug ridden, insecure pos" rhetoric is annoying, I think most of us know better. I certainly have situations where a potential client will not put a Flash based app of mine into their website, just because it is Flash based rather than HTML. But I have many more situations where the client either doesn't care or stops caring after trying the app. Because Flex sells itself when given a chance, and in the end all the client cares about is how much it costs to write the app and how well it works and Flex in Flash player is a winner in both these categories compared with most everything else. So, while I agree that for Apache Flex to be dependant on Adobe VM tech is not ideal, I think it is better than being dependant on the browser makers' HTML/JS efforts. Finally just to answer Gordon's question about Flex work, I have plenty of Flex work and if anything it is increasing. Sent from my iPhone On 17.11.2012, at 00:01, Joan Llenas Masó <j...@garnetworks.com> wrote: > 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 >>>> >>>> >>> >>
