incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joan Llenas Masó <j...@garnetworks.com>
Subject Re: Flex 5 in haxe
Date Sat, 17 Nov 2012 00:01:45 GMT
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 <nilsfromparis@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 <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