incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nils Dupont <nilsfrompa...@gmail.com>
Subject Re: Flex 5 in haxe
Date Fri, 16 Nov 2012 23:29:09 GMT
@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 <jazzmatadazz@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 <aharui@adobe.com>
>
> >
> >
> >
> > On 11/16/12 1:52 PM, "Fr├ęderic Cox" <coxfrederic@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
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message