Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Apple Message framework v1085)
Subject: Re: Flex 5 in haxe
From: Hordur Thordarson <hordur@lausn.is>
In-Reply-To: 
 <CAJRGrVuuBucOz76Otug6qzSNu5=H+FqAKo8axzh7P9JYUM4bWg@mail.gmail.com>
Date: Sat, 17 Nov 2012 16:37:07 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <49452F79-1B10-4E1E-896D-9B6D4BC710B4@lausn.is>
References: 
 <149F8129B58B2D418508E63117D9C5419B5B35FF86@nambx05.corp.adobe.com>
 <CCCC7556.46DB2%coxfrederic@gmail.com>
 <149F8129B58B2D418508E63117D9C5419B5B35FF9C@nambx05.corp.adobe.com>
 <D84D2136-8297-4906-9A17-B58A173DCBB1@classsoftware.com>
 <50A74C1C.2060507@gmail.com>
 <CAOwcBfo0=FJ+E8=AXKvuaBv4_2X96VXzekEv=RsakCZy0aGL5A@mail.gmail.com>
 <CAJRGrVvrJjriHdjj1ccNVk+LjbogtSjUtj6mM0hCXCFpLoVGkw@mail.gmail.com>
 <50A78F40.6010202@gmail.com>
 <CAJRGrVvc_kAtan4EgSXvv2xuV13QnMeOr3TPXATu3rTOt9_+oA@mail.gmail.com>
 <50A79724.9090500@gmail.com> <191F0DA5-FAD3-461D-8E57-D686D2104560@lausn.is>
 <CAJRGrVuuBucOz76Otug6qzSNu5=H+FqAKo8axzh7P9JYUM4bWg@mail.gmail.com>
To: flex-dev@incubator.apache.org

On 17.11.2012, at 14:53, Nils Dupont wrote:

> @Hordur
> If we are all participating to this discussion on this mailing list, I
> think it is because we all love Flex framework! :)

Yep, you've got me there Nils, I'm totally a sucker for Flex :-)

> But we can't escape the pressure of customers coming to us with the
> recurring question: Why Flex and not HTML5?

Right again, and I'm not saying it shouldn't be discussed, if I gave =
that impression I apologize.
But to be 100% clear, I am totally pushing my own agenda here.  Some =
will agree with me, others will not, that's just all part of the =
package.  In the end the discussion is very much required and just great =
fun to participate in (albeit quite time consuming... ;-).

> 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.

Well, as I've tried to explain in other emails, I read Adobe's =
intentions differently.  They intend to make a business out of games on =
their VM.  On the desktop, that means Flash player.  In the mobile space =
that means AIR.

> 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.

I confess that I have to read up on Cordova a bit more to understand =
what it is, what it does and how.  Maybe it is possible to add Cordova =
to the mix without affecting the Flex development experience too much.

>=20
> Nils
>=20
>=20
>=20
> 2012/11/17 Hordur Thordarson <hordur@lausn.is>
>=20
>>> 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
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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
>> :-)
>>=20
>> On 17.11.2012, at 13:54, s=E9bastien Paturel wrote:
>>=20
>>> 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.
>>>=20
>>>=20
>>> Le 17/11/2012 14:25, Nils Dupont a =E9crit :
>>>> 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.
>>>>=20
>>>>=20
>>>> 2012/11/17 s=E9bastien Paturel <sebpatu.flex@gmail.com>
>>>>=20
>>>>> 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.
>>>>>=20
>>>>>=20
>>>>> Le 17/11/2012 14:14, Nils Dupont a =E9crit :
>>>>>=20
>>>>> 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, =
web
>>>>>> 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.
>>>>>>=20
>>>>>>=20
>>>>>> 2012/11/17 Maxime Cowez <maxime.cowez@gmail.com>
>>>>>>=20
>>>>>>   Are developers on this list still able to earn a living =
building
>> new
>>>>>>> Flex apps, or are you maintaining old ones?
>>>>>>>=20
>>>>>>> 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. =46rom my experience in that short amount of time I =
can tell
>> 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 are
>>>>>>> rolling in as we speak.
>>>>>>>=20
>>>>>>> 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...
>>>>>>>=20
>>>>>>> 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 =
performance
>>>>>>> compared
>>>>>>> to Flex when presenting lots of data; I'm only speaking of =
classic
>>>>>>> web-applications here.
>>>>>>>=20
>>>>>>> @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.
>>>>>>>=20
>>>>>>> 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.
>>>>>>>=20
>>>>>>>=20
>>>>>>> On Sat, Nov 17, 2012 at 9:34 AM, Paul Hastings <
>> paul.hastings@gmail.com
>>>>>>>=20
>>>>>>>> wrote:
>>>>>>>> Are developers on this list still able to earn a living =
building new
>>>>>>>> Flex
>>>>>>>>=20
>>>>>>>>> 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
>>>>>>>>=20
>>>>>>> backends.
>>>>>>>=20
>>>>>>>> mainly for desktops & some stripped down functionality for
>> tablets--much
>>>>>>>>=20
>>>>>>> of
>>>>>>>=20
>>>>>>>> the processing is shared between client & backends.
>>>>>>>>=20
>>>>>>>> while i'm sure there are some big/complex JS/JTML5 apps for =
this
>> market
>>>>>>>> somewhere, haven't actually seen any.
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>=20
>>=20
>>=20