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 Sat, 17 Nov 2012 14:53:58 GMT
If we are all participating to this discussion on this mailing list, I
think it is because we all love Flex framework! :)
But we can't escape the pressure of customers coming to us with the
recurring question: Why Flex and not HTML5?
This question is easy to answer / to argument concerning desktop
applications (browser fragmentation, etc.), but concerning mobile
applications it is less obvious because there are other technologies that
can do almost the same, at least for "entreprise" oriented applications.
Concerning Adobe runtime dependency, if Adobe strategy was perfectly
aligned with Flex developpers strategy it would be OK, but unfortunately
Adobe took a different path lately, so we can't avoid asking ourself if
this dependency is not a threat for Apache Flex framework in a near /
mid-term future, at least for targeting mobile plateforms.
When I was speaking of Apache Flex to Apache Cordova bridge, I wasn't
thinking that it wouldn't be possible anymore to target Adobe Air runtime,
or to use Flash Builder debugging capabilities, I was thinking of the
possibility to "export" a Flex Mobile application to the HTML5/JS world via
Apache Cordova, for simple entreprise applications. You can still debug
with Air and just export your project when ready.


2012/11/17 Hordur Thordarson <hordur@lausn.is>

> > if all says that HTML5 is not ready yet for RIA and enterprise apps that
> flex can do very well, why the hell would we try to render flex on HTML5
> engine for
> My question exactly, why the heck, when we have the best cross-platform UI
> lib out there with allready pretty darn good deployment options (from a
> technical/ubiquity perspective), do we want to go and turn our AS3/MXML
> code into HTML and JavaScript for running in the browser?  If the only
> thing that is gained by that is to get rid of the Adobe VM dependency then
> I say we're giving up much more than we are getting.
> I'm using Flex and deploying to Flash player / AIR specifically so I don't
> have to deal with HTML/JS/CSS.  And someone please correct me if I'm wrong,
> but currently I have an excellent debugging experience for my Flex apps
> with FlashBuilder and Flash player, I can set breakpoints, step through my
> code etc, works like a charm.  If Flex is rewritten and the decision is
> made to compile to HTML/JS, as far as I can see, this experience has been
> downgraded significantly because now I have to debug generated HTML/JS
> code, not my own code.  This is the problem with cross-compilation.
> Also, what would the experience be on the dev tools side ?  Currently we
> have Flash builder with a pretty nice, WYSIWYG GUI builder and as I said, a
> pretty nice compile-run-debug experience.  If Flex is ported to Haxe or
> some other language, we are back to square one as far as this is concerned.
>  If Flex sticks to AS3/MXML but then gets cross-compiled into HTML/JS, then
> as I said above, the code you run/debug will not be the actual code you
> wrote.  All sorts of new problems will follow.
> I'm really hoping I'm wrong and way to pessimistic about all this, and
> will happily change my views on this if someone shows me some evidence that
> even though Flex is rewritten and the Adobe dependency ditched, we will not
> loose the nice dev experience that Flex has today.
> I'm a Apple/Mac guy and have been since the days of the Apple II.  I've
> been programming for about as long.  And as such, I've often had the
> problem that I wanted to develop on my Mac but be able to deploy to
> Windows, or both.  Out of the countless number of frameworks and tools and
> programming languages that I've tried through the years, nothing at all
> matches the Flex/Flash player/AIR combo.  Nothing, period.  And I think we
> owe it to Flex to not just cut out most of what makes it great just to get
> rid of the Adobe dependency.  At the very least, if a totally new Flex is
> started, possibly with another programming language and deployment runtime,
> I would hope that there would also be an ongoing lobbying effort concerned
> with showing Adobe what a great use of Flash player and AIR the Flex
> framework is, because there is nothing seriously wrong with the Flex
> platform as it is, and like the man said, if it ain't broke, don't fix it
> :-)
> On 17.11.2012, at 13:54, sébastien Paturel wrote:
> > i was in fact talking about enterprise app.
> > it is already quite rapidly heavy perf consuming.
> > if all says that HTML5 is not ready yet for RIA and enterprise apps that
> flex can do very well, why the hell would we try to render flex on HTML5
> engine for native apps.
> > I was talking about 3D rendering, in a starling sens, as a background
> rendering engine, not as application.
> >
> >
> > Le 17/11/2012 14:25, Nils Dupont a écrit :
> >> It really depends on which kind of application you want to deploy. I was
> >> more thinking of common "entreprise" oriented applications, e.g. a few
> >> views, with a few lists and a few forms. For 3D rendering I agree that
> it
> >> is not the best way to go.
> >>
> >>
> >> 2012/11/17 sébastien Paturel <sebpatu.flex@gmail.com>
> >>
> >>> Does not cordova only launch a web browser wrapped in an native app?
> >>> If so, its very bad result in terms of performances right?
> >>> in a native app environement, we can leverage from 3D rendering (the
> best
> >>> performances), but with cordova solution, we will use the lowest
> performant
> >>> renderer available, the HTML5 renderer.
> >>> it does not sound very promising to me, but maybe i'm wrong.
> >>>
> >>>
> >>> Le 17/11/2012 14:14, Nils Dupont a écrit :
> >>>
> >>>  Has anyone tried to make a bridge between Apache Flex and Apache
> Cordova?
> >>>> I mean generating an Apache Cordova HTML5/JS application from a Flex
> >>>> Mobile
> >>>> MXML/AS3 application (at least for a subset of Flex Mobile components
> e.g.
> >>>> views & transitions, lists, input controls, native APIs access,
> >>>> service
> >>>> access, etc.)
> >>>> Apache Cordova has the advantage to be able to target 7 different
> mobile
> >>>> OS
> >>>> and of course is open source.
> >>>> For the UI controls, it is possible to use different librairies
> (JQuery
> >>>> UI,
> >>>> Twitter Bootstrap, etc.)
> >>>> Maybe it is also an other way to consider in order to be able to
> deploy
> >>>> Flex Mobile applications to mobile devices without
> >>>> the use of Air runtime?
> >>>> Nils
> >>>> NB: Concerning desktop applications, Flash Player remains, in my
> opinion,
> >>>> the best way to deploy cross-browser applications.
> >>>>
> >>>>
> >>>> 2012/11/17 Maxime Cowez <maxime.cowez@gmail.com>
> >>>>
> >>>>    Are developers on this list still able to earn a living building
> new
> >>>>> Flex apps, or are you maintaining old ones?
> >>>>>
> >>>>> I was actually hired 9 months ago by my current company to set up
> new
> >>>>> Flex development branch, as they wanted a share of the market in
> >>>>> area.
> >>>>> As such I am mainly creating new "enterprise" apps for government
> clients
> >>>>> so I can take full advantage of Spark and don't have to worry about
> >>>>> legacy
> >>>>> too much. From my experience in that short amount of time I can
> you
> >>>>> this: we started by creating small(-ish), fairly risc-free projects,
> >>>>> which
> >>>>> we could deliver with very good quality and on time even though
on a
> >>>>> tight
> >>>>> deadline. Because of Flex's RAD (rapid application development)
> >>>>> possibilities we were able to use prototypes to discuss functionality
> >>>>> early
> >>>>> in the development process. All of which lead to very satisfied
> >>>>> customers,
> >>>>> of which some were known to be "clients from hell". Bigger orders
> >>>>> rolling in as we speak.
> >>>>>
> >>>>> I'd like to highlight one specific approach we took in selling Flex:
> a
> >>>>> customer wanted us specifically to use Dojo as a technology. We
> the
> >>>>> risk to develop a small prototype in Flex and presented it to them.
> They
> >>>>> saw immediately that the UX was far superior to what they were used
> to.
> >>>>> And
> >>>>> we told them we could *perhaps* deliver the same with Dojo, but
> would
> >>>>> cost them at least twice as much (which is a true estimate - not
> just for
> >>>>> selling purposes - and we had just proven by delivering the
> prototype in
> >>>>> no
> >>>>> time). They did not have to think very long about it...
> >>>>>
> >>>>> We've been trying out various enterprise-level HMTL5/JS frameworks
> and
> >>>>> the
> >>>>> truth is, none of them comes even close to what Flex can do in terms
> of
> >>>>> stability, possibilities, performance and most importantly (for
> >>>>> customer) development time. And yes I've included performance in
> >>>>> list:
> >>>>> none of those enterprise-level frameworks have decent performance
> >>>>> compared
> >>>>> to Flex when presenting lots of data; I'm only speaking of classic
> >>>>> web-applications here.
> >>>>>
> >>>>> @paul There's a team not far from my desk that's making a GIS
> application
> >>>>> with GWT: the project is a total mess and we're loosing money on
> >>>>>
> >>>>> To sum it up: from my experience Flex as it is now still can be
> in
> >>>>> markets that are not too sensitive to buzzwords.
> >>>>>
> >>>>>
> >>>>> On Sat, Nov 17, 2012 at 9:34 AM, Paul Hastings <
> paul.hastings@gmail.com
> >>>>>
> >>>>>> wrote:
> >>>>>> Are developers on this list still able to earn a living building
> >>>>>> Flex
> >>>>>>
> >>>>>>> apps, or are you maintaining old ones?
> >>>>>>>>  in our neck of the woods flex is still kind of king
for old
> school
> >>>>>> GIS
> >>>>>> applications (analytical/decision support/etc.) especially w/ESRI
> >>>>>>
> >>>>> backends.
> >>>>>
> >>>>>> mainly for desktops & some stripped down functionality for
> tablets--much
> >>>>>>
> >>>>> of
> >>>>>
> >>>>>> the processing is shared between client & backends.
> >>>>>>
> >>>>>> while i'm sure there are some big/complex JS/JTML5 apps for
> market
> >>>>>> somewhere, haven't actually seen any.
> >>>>>>
> >>>>>>
> >>>>>>
> >

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