Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (nike.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: <50A7A390.3000902@gmail.com>
Date: Sat, 17 Nov 2012 16:20:19 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <98E0A436-6581-468C-ACD7-747551001CDB@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>
 <50A7A390.3000902@gmail.com>
To: flex-dev@incubator.apache.org

> 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=E9bastien 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.
>=20
> "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.
>=20
> "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.
>=20
> "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.
>=20
> Le 17/11/2012 15:30, Hordur Thordarson a =E9crit :
>>> 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.
>>=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