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: domain of sebpatu.flex@gmail.com
 designates 209.85.212.177 as permitted sender)
Message-ID: <50A7AD33.1020500@gmail.com>
Date: Sat, 17 Nov 2012 16:28:51 +0100
From: =?ISO-8859-1?Q?s=E9bastien_Paturel?= <sebpatu.flex@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: flex-dev@incubator.apache.org
Subject: Re: Flex 5 in haxe
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>
 <CAMFKFRg0kejgCvOvwU2jzDgJ-EbA+QntnNNUHx5Fz4n+eCPUdQ@mail.gmail.com>
 <50A7A7D2.5020902@gmail.com>
 <CAJRGrVtbZy42Y=dEfLW8LX+kXcnRNQM09yUDMxqF75-R1yytMA@mail.gmail.com>
In-Reply-To: 
 <CAJRGrVtbZy42Y=dEfLW8LX+kXcnRNQM09yUDMxqF75-R1yytMA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

for 1 - check haxe and nme, its made for cross platform from the ground 
up, so yes. but im not expert/
for 2- if we would not be doomed to re write it, i would be the first to 
be happy. but when Alex is the first to call for a rewrite because a 
rearchitecturing is too difficult to get enough modularity, and to give 
the community the ability to make it evolve, then i think we have not 
much alternatives.

200 000 hours of work, but in that theres some hours about porting from 
AS2 to AS3, some hours to do MX components and spark, when a new re 
write could start only with spark, and theres a lot of time of API 
conception which we will use back. i even think that we can use back a 
lot of high level classes and all the api documentation, which is long 
to take care of, and that we can use as it is, because the goal is to 
get the same API at the end (at least a big part of it).


Le 17/11/2012 16:19, Nils Dupont a �crit :
> "I think that Haxe is such a "all use cases" solution when AS3 + Cordova is
> not (unless someone proves the contrary)."
> Of course not, it is what I said a few times in this discussion.
> I don't know Haxe, another time, and I have nothing against the perspective
> of using this technology.
> But just 2 questions :
> 1) Can you access to native features like Camera, Accelerometer, File
> system, etc. easily with Haxe, and is it cross-platform, I mean able to run
> the same on different OS?
> http://docs.phonegap.com/en/2.2.0/guide_getting-started_index.md.html
> 2) Don't you think that the effort of rewriting totally the Flex framework
> with Haxe is not too big for the community?
> I don't remember who said that in this discussion but Flex represents
> something like 200,000 hours of work...
> Nils
>
>
> 2012/11/17 s�bastien Paturel <sebpatu.flex@gmail.com>
>
>> Hi Carlos,
>> By the way thank you for the initiative :)
>> Yes i agree that theres a point about simple use cases against complex app
>> use cases.
>> But if we must consider different solution for every target, it will be
>> much more difficult to achieve and maintain, compared to a global solution
>> which can fit to all use cases.
>> I think that Haxe is such a "all use cases" solution when AS3 + Cordova is
>> not (unless someone proves the contrary).
>>
>> But one thought here, maybe mad one
>> if we really start a re write from scratch, why not maintain two language
>> versions of the new framework?
>> one in AS3 with Alex solution (whatever it is) for cross platform which
>> has the big advantage to keep using the already existing AS3 code around
>> and make the transition more easy.
>> And in parallel tranlate it to haxe which would be a beter solution for
>> very new projects (still has to be discussed of course).
>> I think that:
>> - its doable, as AS3 and haxe are very similar, and if we port any new
>> piece of code created in AS3 to haxe anytime time its checked in, it should
>> not be so much work to achieve and to keep in synch.
>> - it gives the best of the two worlds.
>> I agree that its a bit a contradiction with what i complained just above :p
>>
>>
>>
>> Le 17/11/2012 15:05, Carlos Rovira a �crit :
>>
>>   Hi Sebastien,
>>> I have use cases where I would need something tiny to be deployed to the
>>> browser. We have huge products based on Flex/JEE, and our interface can do
>>> lots of things. But our product could be in mobile browsers integrated in
>>> diferent webs. We cannot do this right now without targeting HTML/JS.
>>>
>>> So I'd be happy to be able to develop that components and tiny
>>> developments
>>> for "browser-mobile" with the same client technology. So this will be make
>>> to reuse librar�es and all kind of things (maven, IDE knowledge,
>>> deployment
>>> strategies....) I only need to select a diferent output...in this case
>>> HTML/JS.
>>>
>>> I'm with you that I would not plan to make any of our huge flex apps in
>>> HTML5, we are not mad! ;)
>>>
>>>
>>> 2012/11/17 s�bastien Paturel <sebpatu.flex@gmail.com>
>>>
>>>   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, 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.
>>>>>>>
>>>>>>>
>>>>>>> 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 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 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.
>>>>>>>>
>>>>>>>> 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 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 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 <
>>>>>>>> paul.hastings@gmail.com
>>>>>>>>
>>>>>>>>    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 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 this
>>>>>>>>> market
>>>>>>>>> somewhere, haven't actually seen any.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>