incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hordur Thordarson <>
Subject Re: Flex 5 in haxe
Date Sat, 17 Nov 2012 18:28:37 GMT
On 17.11.2012, at 16:39, sébastien Paturel wrote:

> Adobe's roadmap continue to believe in flash player and AIR. ok. but not at all for enterprise
> first consequence is that any new capability like workers will be only for the new VM
we cant access with AS3 flex. (which was quite a big surprise for me)

Not so according to this page:

> if tomorrow a great platform comes out, and is well suited for enterprise apps, but not
for gaming. flex is screwed for sure.

Great new platforms pop up in the dev community all the time, however very few of them make
it through childhood, puberty and on to mature adulthood.
Meanwhile, Flex will continue to work fine with the existing Flash player in all browsers
at least up to the current versions and probably longer.

> if tomorrow Adobe dont manage to make money on gaming, (don't forget that in that area,
theres already tools like Unity which are much more advanced and widely used) they could decide
to not continue to improve AIR on mobile etc.

Absolutely.  That however doesn't make HTML/JS any more attractive to me nor does it fix all
the problems there are with HTML/JS development.
And isn't it more likely than not that Adobe will at least give this new strategy a few years
to play out?

> even if Adobe continue to port AIR on new devices, flex will only use an old abandoned
VM. Again its like if you were still trying to maintain an AS2 framework in an AS3 world (its
even worse).

Isn't AIR support on devices more about porting the runtime to the particular OS running on
the device, rather than porting to the device itself ?  Or maybe it's a bit of both, I'm not
sure.  In any case, Adobe are adding Flash based services themselves even now, they just added
a big video management solution which uses the Flash runtime in Flash player / AIR for video
playback with support for commercials and other stuff.  Why would they release smth like that
and then turn around and kill the delivery platform ?  HTML5 video doesn't cut it for this
and won't anywhere in the near future because of disputes between the browser vendors and
the HTML standardization entities.

> And you pointed out the Adobe's roadmap for flash platform. But check also their active
work on HTML5 area. everyone is preapring itself for a less plugins world, before a non plugin
world. And the shift of Adobe was quite a very early and brutal one. (which was a bad decision
IMO, but flex has to deal with it)

Well, I understood Adobe's decision and reasoning quite well when they finally got around
to explaining it properly.  And if they are going be major players in the HTML business then
they have to take part in that work.  I never expected them not to and don't think this should
be a surprise to anyone.

> Do you really want flex to be totally dependant on Adobe's decisions? even if Their strategy
has nothing to do with apps?
> Did not the last year afraid you enough?

Last year definately did frighten me.  But I've been watching the development of HTML5/JS/CSS
for a long time as well, and there are lots of very big problems there that just aren't getting
resolved despite years of discussions/arguing/etc.  I don't want Flex to be dependent on Adobe
but it currently is and I don't see any better alternatives out there for the next few years

But we'll see what Alex proposes, I'm looking forward to detailed suggestions from him and
then we can go through this discussion all over again :D :D :D

> The flex future is out of Adobe depency, and it has to be prepared as soon as possible.
even if we still have a few years before the unevitable big shift happens.
> Le 17/11/2012 17:20, Hordur Thordarson a écrit :
>>> If we have a solution like Haxe, we can debug in a local native output, and use
the HTML/JS output only as a release.
>> That to me is a recipe for problems, test/debug on one runtime, deploy to another
one, you'll get situations where smth works in testing/debug but doesn't or works differently
in your release build.  Not good.
>>> but if you take the fact that the plugin word is getting to an end
>> I don't agree with that.  Here's Adobe's roadmap on this:
>> "Adobe believes that the Flash runtimes are particularly and uniquely suited for
two primary use cases: creating and deploying rich, expressive games with console-quality
graphics and deploying premium video.  This shift in focus for Flash does not mean that existing
content will no longer run, or that Flash cannot be used for content other than gaming and
premium video. However, it does mean that when prioritizing future development and bug fixes,
gaming and premium video use cases will take priority."
>> That to me says that Flash player/AIR aren't going away, quite the opposite in fact
as Flash player/AIR (for mobile) are core components of Adobe's new gaming strategy for building
a business on top of Flash.
>>> but you don't get it anymore in the next flash builder versions, because of the
Adobe's strategy shift.
>> Do we know this for sure ?  I've not read anything that tells me this.  And frankly,
I can't see how Adobe is going to monetize Flash without top-notch dev tools.  Indeed, their
roadmap says this:
>> "The Flash runtimes provide a number of key advantages and differentiators as a gaming
platform, including the following: .... World-class creative and developer tooling including
Adobe Flash Builder, Adobe Flash Professional, Adobe Photoshop, and Adobe Illustrator".
>> But maybe I'm reading all this wrong or maybe I'm believing too much what I think
I'm reading or maybe the people here advocating a HTML/JS strategy for Flex have been burned
more by Adobe than I have.
>> On 17.11.2012, at 14:47, sébastien Paturel wrote:
>>> Why? as we said it before, its only to get rid of Adobe's runtime for the long
term future of flex.
>>> The last year should have convinced you thats its too dangerous to be so dependant
to Adobes decisions.
>>> And no one wants to turn the AS3/MXML code to HTML/JS.  its only an alternative
as a runtime. You would still use the same AS3, the same Flash builder.
>>> If we have a solution like Haxe, we can debug in a local native output, and use
the HTML/JS output only as a release.
>>> "Flash builder with a pretty nice, WYSIWYG GUI builder"
>>> but you don't get it anymore in the next flash builder versions, because of the
Adobe's strategy shift.
>>> "the code you run/debug will not be the actual code you wrote"
>>> but if you take the fact that the plugin word is getting to an end, theres not
much choices left. and you have to rely on a new layer which will replace the plugin.
>>> "like the man said, if it ain't broke, don't fix it"
>>> Again, the flex future is broken, and we have to fix it.
>>> Le 17/11/2012 15:30, Hordur Thordarson a écrit :
>>>>> 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
>>>>> 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 <>
>>>>>>> Does not cordova only launch a web browser wrapped in an native
>>>>>>> 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
>>>>>>> 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
>>>>>>>> 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, web
>>>>>>>> service
>>>>>>>> access, etc.)
>>>>>>>> Apache Cordova has the advantage to be able to target 7 different
>>>>>>>> OS
>>>>>>>> and of course is open source.
>>>>>>>> For the UI controls, it is possible to use different librairies
>>>>>>>> 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 <>
>>>>>>>>    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 a new
>>>>>>>>> Flex development branch, as they wanted a share of the
market in that
>>>>>>>>> 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 tell you
>>>>>>>>> this: we started by creating small(-ish), fairly risc-free
>>>>>>>>> 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
>>>>>>>>> early
>>>>>>>>> in the development process. All of which lead to very
>>>>>>>>> customers,
>>>>>>>>> of which some were known to be "clients from hell". Bigger
orders are
>>>>>>>>> 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 took 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 it 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 the
>>>>>>>>> customer) development time. And yes I've included performance
in that
>>>>>>>>> list:
>>>>>>>>> none of those enterprise-level frameworks have decent
>>>>>>>>> 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 it.
>>>>>>>>> To sum it up: from my experience Flex as it is now still
can be sold in
>>>>>>>>> markets that are not too sensitive to buzzwords.
>>>>>>>>> On Sat, Nov 17, 2012 at 9:34 AM, Paul Hastings <
>>>>>>>>>> wrote:
>>>>>>>>>> Are developers on this list still able to earn a
living building new
>>>>>>>>>> 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
>>>>>>>>> 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 this market
>>>>>>>>>> somewhere, haven't actually seen any.

View raw message