We dont use ActionScript/MXML at all. ActionScript/MXML were not scaling for our customers(most of them use J2EE) so we exported the Flash/AIR/Flex API to Java using GWT giving their devs the ability to write Flex using the tools they are familiar with.
2012/11/16 Gordon Smith <gosm...@adobe.com> > > we have a different approach to Flex development > > Can you elaborate on that a little? > > -----Original Message----- > From: Alain Ekambi [mailto:jazzmatad...@gmail.com] > Sent: Friday, November 16, 2012 2:22 PM > To: flex-dev@incubator.apache.org > Subject: Re: Flex 5 in haxe > > @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 > > > > >
