Flex 5 in haxe

[Carlos Rovira <ca...@codeoscopic.com>]

Hi,

as we were discussing yesterday, there's room to a new Flex framework
written from scratch. As we don't want to rely in Adobe technologies
anymore we were talking about haxe. We can make it now that work would be
starting from zero.

Haxe is a platform developed by Nicolas Canesse that made it's own
community. Nicolas is a genius of compilers. People coming from Flash Open
Source will remember MTASC compiler back in 2004-5. If you search and
investigate you will found that haxe is very powerful and is "the great
unknown technology".

http://haxe.org/

haxeNME is like Adobe AIR and seems to be more performant in iOS, and
Android (see
http://esdot.ca/site/2012/performance-showdown-starling-vs-nd2d-vs-genome2d-vs-haxe-nme).
Supports as well Windows, Mac, Linux and BB.

http://www.haxenme.org/

There's an haxe plugin for IntelliJ. But in my test it seems that only
supports haxe and not NME yet.

(Disclaimer: I'm to new to haxe and haxeNME and maybe I wrong making some
statements here).

- Haxe is OOP and is "one language to rule them all" philoshopy.

- Haxe compiler is better that the set provided by Adobe (I'm referring to
AS3 legacy compiler. Falcon is new technology and maybe this is not true. I
does not have any info to make a comparision between falcon and haxe
compiler).

- Haxe language is more evolved (maybe even Adobe AS4 will copy things from
haxe...)

- Haxe support HTML5/JS out of the box (but it seems to be in beta status).

- There's a Starling port in haxe.

Regarding Flex: haxe compiler could bring to flex things like *metadata
evolution* or *AOP*. Adobe compiler will never get that evolution since
gamming is not focused in that kind of things...This is more likely to see
in haxe if Flex 5 works than expect it from Adobe.

Drawbacks:

IDE: IntelliJ+haxe plugin. IntelliJ is the best option for Flex, and
supports haxe, but I think haxeNME is not supported yet. But IntelliJ guys
are behind the plugin, so things could evolve ok in this point.

MXML: I think there's nothing like MXML in haxe today, and this is one of
the key points in Flex. We would need to put the efforts of MXML in making
it possible in haxe. We could talk with Nicolas Canesse about this
possibility. Since Falcon has little support of MXML, I see we don't loose
almost nothing.

So my proposal is:

* Start Flex 5 from scratch with haxe.

* Use the Flex 4 API to model Flex 5 over haxe (as the first draft).

* Start using Starling haxe library as the core displayobject API (to be
able to target Stage3D/Workers in  Flash).

* Make an UIComponent decoupled implementation based on composition over
inheritance (here experience of Alex Harui and other will be very wellcome
to start with a good foundation).

Optional:

* Take into account the SWF and HTML5 outputs in the first drafts.

This would start as an experiment based on fun of coding, and we could see
where it goes over time. If it gets momentum, people join the cause, and so
on...



-- 
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F:  +34 912 35 57 77
http://www.codeoscopic.com
http://www.directwriter.es
http://www.avant2.es

Re: Flex 5 in haxe

[Avinash Narayanan <av...@gmail.com>]

I think we need to move away from the negativity thats been surrounding
flex at least in the enterprise level. Haxe might be a great idea to get
some fresh blood in. Frankly, I've been running around like a headless
chicken in my org because everyone seems to have been scared off by Flex
not working optimally on mobile/tablets and I'm too low in the pecking
order to make them think otherwise.

Looking for some light in the end of a year long tunnel
Avinash

Thanks
Avinash Y


On Fri, Nov 16, 2012 at 4:48 PM, Joan Llenas Masó <jo...@garnetworks.com>wrote:

> It doesn't sound bad at all to me.
> Flex5 had to be rewritten after all, right?
> Also, Haxe is not that different from ActionScript. ActionScript developers
> will get familiar with Haxe in no time.
> The benefits of taking this approach:
> - We keep the SWF output target.
> - We add the HTML5 as first citizen.
> - Because everything would have to be rewritten, we could take the
> opportunity to unit test the whole framework.
> - We have the oportunity to modularize the framework as Alex Hauri has
> suggested in the past.
> - Nicolas Canesse and the Haxe team will mantain the bytecode generation,
> which means that Flex code won't have to change when a totally different
> Flash Player VM is out or when HTML6-7 is out.
> Also, taking into account Nicolas antecedents, the compiler will ensure we
> always get the best of each output target in terms of code execution
> performance.
> - People could see in this movement a good reason to trust in Flex again
> and even to get more involved.
>
> I'm sure I'm missing many other benefits...
>
> My 2 cents.
> Cheers
>
>
>
> On Fri, Nov 16, 2012 at 11:49 AM, Carlos Rovira <
> carlos.rovira@codeoscopic.com> wrote:
>
> > Hi,
> >
> > as we were discussing yesterday, there's room to a new Flex framework
> > written from scratch. As we don't want to rely in Adobe technologies
> > anymore we were talking about haxe. We can make it now that work would be
> > starting from zero.
> >
> > Haxe is a platform developed by Nicolas Canesse that made it's own
> > community. Nicolas is a genius of compilers. People coming from Flash
> Open
> > Source will remember MTASC compiler back in 2004-5. If you search and
> > investigate you will found that haxe is very powerful and is "the great
> > unknown technology".
> >
> > http://haxe.org/
> >
> > haxeNME is like Adobe AIR and seems to be more performant in iOS, and
> > Android (see
> >
> >
> http://esdot.ca/site/2012/performance-showdown-starling-vs-nd2d-vs-genome2d-vs-haxe-nme
> > ).
> > Supports as well Windows, Mac, Linux and BB.
> >
> > http://www.haxenme.org/
> >
> > There's an haxe plugin for IntelliJ. But in my test it seems that only
> > supports haxe and not NME yet.
> >
> > (Disclaimer: I'm to new to haxe and haxeNME and maybe I wrong making some
> > statements here).
> >
> > - Haxe is OOP and is "one language to rule them all" philoshopy.
> >
> > - Haxe compiler is better that the set provided by Adobe (I'm referring
> to
> > AS3 legacy compiler. Falcon is new technology and maybe this is not
> true. I
> > does not have any info to make a comparision between falcon and haxe
> > compiler).
> >
> > - Haxe language is more evolved (maybe even Adobe AS4 will copy things
> from
> > haxe...)
> >
> > - Haxe support HTML5/JS out of the box (but it seems to be in beta
> status).
> >
> > - There's a Starling port in haxe.
> >
> > Regarding Flex: haxe compiler could bring to flex things like *metadata
> > evolution* or *AOP*. Adobe compiler will never get that evolution since
> > gamming is not focused in that kind of things...This is more likely to
> see
> > in haxe if Flex 5 works than expect it from Adobe.
> >
> > Drawbacks:
> >
> > IDE: IntelliJ+haxe plugin. IntelliJ is the best option for Flex, and
> > supports haxe, but I think haxeNME is not supported yet. But IntelliJ
> guys
> > are behind the plugin, so things could evolve ok in this point.
> >
> > MXML: I think there's nothing like MXML in haxe today, and this is one of
> > the key points in Flex. We would need to put the efforts of MXML in
> making
> > it possible in haxe. We could talk with Nicolas Canesse about this
> > possibility. Since Falcon has little support of MXML, I see we don't
> loose
> > almost nothing.
> >
> > So my proposal is:
> >
> > * Start Flex 5 from scratch with haxe.
> >
> > * Use the Flex 4 API to model Flex 5 over haxe (as the first draft).
> >
> > * Start using Starling haxe library as the core displayobject API (to be
> > able to target Stage3D/Workers in  Flash).
> >
> > * Make an UIComponent decoupled implementation based on composition over
> > inheritance (here experience of Alex Harui and other will be very
> wellcome
> > to start with a good foundation).
> >
> > Optional:
> >
> > * Take into account the SWF and HTML5 outputs in the first drafts.
> >
> > This would start as an experiment based on fun of coding, and we could
> see
> > where it goes over time. If it gets momentum, people join the cause, and
> so
> > on...
> >
> >
> >
> > --
> > Carlos Rovira
> > Director de Tecnología
> > M: +34 607 22 60 05
> > F:  +34 912 35 57 77
> > http://www.codeoscopic.com
> > http://www.directwriter.es
> > http://www.avant2.es
> >
>

Re: Flex 5 in haxe

[Joan Llenas Masó <jo...@garnetworks.com>]

It doesn't sound bad at all to me.
Flex5 had to be rewritten after all, right?
Also, Haxe is not that different from ActionScript. ActionScript developers
will get familiar with Haxe in no time.
The benefits of taking this approach:
- We keep the SWF output target.
- We add the HTML5 as first citizen.
- Because everything would have to be rewritten, we could take the
opportunity to unit test the whole framework.
- We have the oportunity to modularize the framework as Alex Hauri has
suggested in the past.
- Nicolas Canesse and the Haxe team will mantain the bytecode generation,
which means that Flex code won't have to change when a totally different
Flash Player VM is out or when HTML6-7 is out.
Also, taking into account Nicolas antecedents, the compiler will ensure we
always get the best of each output target in terms of code execution
performance.
- People could see in this movement a good reason to trust in Flex again
and even to get more involved.

I'm sure I'm missing many other benefits...

My 2 cents.
Cheers



On Fri, Nov 16, 2012 at 11:49 AM, Carlos Rovira <
carlos.rovira@codeoscopic.com> wrote:

> Hi,
>
> as we were discussing yesterday, there's room to a new Flex framework
> written from scratch. As we don't want to rely in Adobe technologies
> anymore we were talking about haxe. We can make it now that work would be
> starting from zero.
>
> Haxe is a platform developed by Nicolas Canesse that made it's own
> community. Nicolas is a genius of compilers. People coming from Flash Open
> Source will remember MTASC compiler back in 2004-5. If you search and
> investigate you will found that haxe is very powerful and is "the great
> unknown technology".
>
> http://haxe.org/
>
> haxeNME is like Adobe AIR and seems to be more performant in iOS, and
> Android (see
>
> http://esdot.ca/site/2012/performance-showdown-starling-vs-nd2d-vs-genome2d-vs-haxe-nme
> ).
> Supports as well Windows, Mac, Linux and BB.
>
> http://www.haxenme.org/
>
> There's an haxe plugin for IntelliJ. But in my test it seems that only
> supports haxe and not NME yet.
>
> (Disclaimer: I'm to new to haxe and haxeNME and maybe I wrong making some
> statements here).
>
> - Haxe is OOP and is "one language to rule them all" philoshopy.
>
> - Haxe compiler is better that the set provided by Adobe (I'm referring to
> AS3 legacy compiler. Falcon is new technology and maybe this is not true. I
> does not have any info to make a comparision between falcon and haxe
> compiler).
>
> - Haxe language is more evolved (maybe even Adobe AS4 will copy things from
> haxe...)
>
> - Haxe support HTML5/JS out of the box (but it seems to be in beta status).
>
> - There's a Starling port in haxe.
>
> Regarding Flex: haxe compiler could bring to flex things like *metadata
> evolution* or *AOP*. Adobe compiler will never get that evolution since
> gamming is not focused in that kind of things...This is more likely to see
> in haxe if Flex 5 works than expect it from Adobe.
>
> Drawbacks:
>
> IDE: IntelliJ+haxe plugin. IntelliJ is the best option for Flex, and
> supports haxe, but I think haxeNME is not supported yet. But IntelliJ guys
> are behind the plugin, so things could evolve ok in this point.
>
> MXML: I think there's nothing like MXML in haxe today, and this is one of
> the key points in Flex. We would need to put the efforts of MXML in making
> it possible in haxe. We could talk with Nicolas Canesse about this
> possibility. Since Falcon has little support of MXML, I see we don't loose
> almost nothing.
>
> So my proposal is:
>
> * Start Flex 5 from scratch with haxe.
>
> * Use the Flex 4 API to model Flex 5 over haxe (as the first draft).
>
> * Start using Starling haxe library as the core displayobject API (to be
> able to target Stage3D/Workers in  Flash).
>
> * Make an UIComponent decoupled implementation based on composition over
> inheritance (here experience of Alex Harui and other will be very wellcome
> to start with a good foundation).
>
> Optional:
>
> * Take into account the SWF and HTML5 outputs in the first drafts.
>
> This would start as an experiment based on fun of coding, and we could see
> where it goes over time. If it gets momentum, people join the cause, and so
> on...
>
>
>
> --
> Carlos Rovira
> Director de Tecnología
> M: +34 607 22 60 05
> F:  +34 912 35 57 77
> http://www.codeoscopic.com
> http://www.directwriter.es
> http://www.avant2.es
>

Re: Flex 5 in haxe

[John Cunliffe <ma...@gmail.com>]

Hi Carlos,

I don't often post on this list, yet I consider myself a big supporter of
Flex. This discussion makes me change my silent policy because it targets
my growing main concern, which I assume is shared by many other developers:
Will I be able to make a living with Flex programming in future or should I
go for another technology? After Adobe stopped their support for Flex, I
found myself sceptical about its future
open-source-software/no-budget-support character.

To me, the success of continuing Flex into any direction depends on three
main factors:

   1. How many and which people will be able to contribute to its rapid,
   stable and rich internet application development.
   2. What platform does it target/support and how well perceived is this
   platform by our clients.
   3. How well will we be able to market Flex to our clients.

IMO 1 depends on 2. The more projects/platforms we target, the more
potential developers will be split up into different groups. This can be
good or bad: Good for finding out which of the group grows biggest and then
follow the most successful branch, Bad for focusing our energy into one
vital projects rather than multiple slowly dieing projects.

Personally, I'm a big believer in joining forces with already existing
projects, that support the right (most busy/profitable/used) platforms for
our clients. I'm fairly certain that flash won't be that - at least in the
eyes of most clients, which really is all that matters. Haxe could be, but
frankly I don't really care.

What I care about is that wherever Flex goes, its developer go
there united and join with whatever other party shares their goals. To me
this goal is simple: Keeping web programming fun (browser-independent,
graphical, interactive etc.), efficient (rapid, maybe on-rails?, components
etc.), robust (Strongly Typed) and maintainable (OOP, IOC etc.). In that
regard, *haxe seems like a really good choice*.

Wherever Flex goes - I'm happy to see so many bright people caring about a
framework I love working with. And once I know where Flex is going and that
you're going there decisively without constantly changing direction, I will
join in on its open-source development.

Thankful regards
John

@Gordon We started a Flex 4 project five months ago with a huge
international client, who himself doesn't believe in Flash/Flex. However we
do - and managed to convince him. All you need for that are good arguments
- and a little flexibility on the customers side, which I understand to be
rare.


On Fri, Nov 16, 2012 at 11:49 AM, Carlos Rovira <
carlos.rovira@codeoscopic.com> wrote:

> Hi,
>
> as we were discussing yesterday, there's room to a new Flex framework
> written from scratch. As we don't want to rely in Adobe technologies
> anymore we were talking about haxe. We can make it now that work would be
> starting from zero.
>
> Haxe is a platform developed by Nicolas Canesse that made it's own
> community. Nicolas is a genius of compilers. People coming from Flash Open
> Source will remember MTASC compiler back in 2004-5. If you search and
> investigate you will found that haxe is very powerful and is "the great
> unknown technology".
>
> http://haxe.org/
>
> haxeNME is like Adobe AIR and seems to be more performant in iOS, and
> Android (see
>
> http://esdot.ca/site/2012/performance-showdown-starling-vs-nd2d-vs-genome2d-vs-haxe-nme
> ).
> Supports as well Windows, Mac, Linux and BB.
>
> http://www.haxenme.org/
>
> There's an haxe plugin for IntelliJ. But in my test it seems that only
> supports haxe and not NME yet.
>
> (Disclaimer: I'm to new to haxe and haxeNME and maybe I wrong making some
> statements here).
>
> - Haxe is OOP and is "one language to rule them all" philoshopy.
>
> - Haxe compiler is better that the set provided by Adobe (I'm referring to
> AS3 legacy compiler. Falcon is new technology and maybe this is not true. I
> does not have any info to make a comparision between falcon and haxe
> compiler).
>
> - Haxe language is more evolved (maybe even Adobe AS4 will copy things from
> haxe...)
>
> - Haxe support HTML5/JS out of the box (but it seems to be in beta status).
>
> - There's a Starling port in haxe.
>
> Regarding Flex: haxe compiler could bring to flex things like *metadata
> evolution* or *AOP*. Adobe compiler will never get that evolution since
> gamming is not focused in that kind of things...This is more likely to see
> in haxe if Flex 5 works than expect it from Adobe.
>
> Drawbacks:
>
> IDE: IntelliJ+haxe plugin. IntelliJ is the best option for Flex, and
> supports haxe, but I think haxeNME is not supported yet. But IntelliJ guys
> are behind the plugin, so things could evolve ok in this point.
>
> MXML: I think there's nothing like MXML in haxe today, and this is one of
> the key points in Flex. We would need to put the efforts of MXML in making
> it possible in haxe. We could talk with Nicolas Canesse about this
> possibility. Since Falcon has little support of MXML, I see we don't loose
> almost nothing.
>
> So my proposal is:
>
> * Start Flex 5 from scratch with haxe.
>
> * Use the Flex 4 API to model Flex 5 over haxe (as the first draft).
>
> * Start using Starling haxe library as the core displayobject API (to be
> able to target Stage3D/Workers in  Flash).
>
> * Make an UIComponent decoupled implementation based on composition over
> inheritance (here experience of Alex Harui and other will be very wellcome
> to start with a good foundation).
>
> Optional:
>
> * Take into account the SWF and HTML5 outputs in the first drafts.
>
> This would start as an experiment based on fun of coding, and we could see
> where it goes over time. If it gets momentum, people join the cause, and so
> on...
>
>
>
> --
> Carlos Rovira
> Director de Tecnología
> M: +34 607 22 60 05
> F:  +34 912 35 57 77
> http://www.codeoscopic.com
> http://www.directwriter.es
> http://www.avant2.es
>

Re: Flex 5 in haxe

[Alex Harui <ah...@adobe.com>]

On 11/16/12 1:35 PM, "Gordon Smith" <go...@adobe.com> wrote:

> Note that I did not include AS3, because AS3 is no longer proprietary to
> Adobe. But I don't see how AS3 gets you onto every platform you want to run
> on. I'd like to hear more from Alex what his vision for iOS and Android is.
> For example, get to HTML/JS and then use Cordova?
> 
Cordova is one possible way, but consider this: the ability to deliver a RIA
in HTML/JS means it doesn't have to be installed on mobile devices.  It can
just be browsed to.  The notion of RIAs in the browser as a zero-install
always-updated application was one of the things that made them attractive.
Just like in PC's 20 years ago everything was a boxed app and was installed
and when the network became fast enough and cheap enough apps in the browser
become popular, I believe the pendulum will swing that way again for mobile
devices.

And for those who have to build apps, maybe Schmalle will create a FalconJ
and you'll go native from there.

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

RE: Flex 5 in haxe

[Gordon Smith <go...@adobe.com>]

Note that I did not include AS3, because AS3 is no longer proprietary to Adobe. But I don't see how AS3 gets you onto every platform you want to run on. I'd like to hear more from Alex what his vision for iOS and Android is. For example, get to HTML/JS and then use Cordova?

- Gordon

-----Original Message-----
From: Michael Schmalle [mailto:apache@teotigraphix.com] 
Sent: Friday, November 16, 2012 1:19 PM
To: flex-dev@incubator.apache.org
Subject: RE: Flex 5 in haxe

Folks,

I have sat out this whole day reading everything.

This statement of Gordon's is golden and should be taken seriously. I have no idea what the answer is to the 100's of posts today but one thing is clear, break the Adobe dependencies however possible and don't count on them.

I was also going to say this as well about the MXML compiler, it is really not "stuck" to any particular implementation in the and as far as language. That is why I brought up what I did about Android and the view layer the other day because the compiler in reality is abstract.

Mike

Quoting Gordon Smith <go...@adobe.com>:

> If Haxe really produces fast-running and good-looking apps on all 
> platforms of interest (does it?), I think it should be a top contender 
> since it is open-source. You could throw away the ActionScript part of 
> Falcon and make the MXML part of Falcon produce Haxe source code. MXML 
> script blocks, event handlers, and databindings in apps would have to 
> switch to using Haxe (as of course would the app's AS files and the 
> entire Flex framework).
>
> My advice is to avoid tying Flex to any proprietary Adobe technology 
> going forward -- whether AS4, V11, or V12  -- because Adobe's language 
> and platform strategy is no longer is alignment with what Flex needs.
>
> - Gordon
>
> -----Original Message-----
> From: Gordon Smith
> Sent: Friday, November 16, 2012 11:28 AM
> To: flex-dev@incubator.apache.org
> Subject: RE: Flex 5 in haxe
>
>> Since Falcon has little support of MXML, I see we don't loose almost 
>> nothing.
>
> Given that Falcon can compile MXML apps like Checkinapp, I don't think 
> it's accurate to characterize its level of MXML support as "little". 
> My own characterization would be "80% complete". But completing the 
> other 20% is a daunting task ( it's certainly many person-months of 
> work) and not enough people are stepping up to help. I'm guessing that 
> this is because the major companies who used to use Flex and swore 
> that they had plenty of compiler engineers who would help finish 
> Falcon have moved on to other technologies.
>
> So I agree that any and all compiler technologies, including Haxe, 
> should get serious consideration.
>
> However, I think before Apache Flex makes a compiler decision, it 
> needs to decide what runtimes it is targeting. Move to V12? Abandon 
> Flash? Produce HTML/JS? Produce native iOS code? Produce native Java 
> for Android?
>
> - Gordon
>
>
> -----Original Message-----
> From: carlos.rovira@gmail.com [mailto:carlos.rovira@gmail.com] On 
> Behalf Of Carlos Rovira
> Sent: Friday, November 16, 2012 2:49 AM
> To: flex-dev@incubator.apache.org
> Subject: Flex 5 in haxe
>
> Hi,
>
> as we were discussing yesterday, there's room to a new Flex framework 
> written from scratch. As we don't want to rely in Adobe technologies 
> anymore we were talking about haxe. We can make it now that work would 
> be starting from zero.
>
> Haxe is a platform developed by Nicolas Canesse that made it's own 
> community. Nicolas is a genius of compilers. People coming from Flash 
> Open Source will remember MTASC compiler back in 2004-5. If you search 
> and investigate you will found that haxe is very powerful and is "the 
> great unknown technology".
>
> http://haxe.org/
>
> haxeNME is like Adobe AIR and seems to be more performant in iOS, and 
> Android (see 
> http://esdot.ca/site/2012/performance-showdown-starling-vs-nd2d-vs-genome2d-vs-haxe-nme).
> Supports as well Windows, Mac, Linux and BB.
>
> http://www.haxenme.org/
>
> There's an haxe plugin for IntelliJ. But in my test it seems that only 
> supports haxe and not NME yet.
>
> (Disclaimer: I'm to new to haxe and haxeNME and maybe I wrong making 
> some statements here).
>
> - Haxe is OOP and is "one language to rule them all" philoshopy.
>
> - Haxe compiler is better that the set provided by Adobe (I'm 
> referring to
> AS3 legacy compiler. Falcon is new technology and maybe this is not 
> true. I does not have any info to make a comparision between falcon 
> and haxe compiler).
>
> - Haxe language is more evolved (maybe even Adobe AS4 will copy things 
> from
> haxe...)
>
> - Haxe support HTML5/JS out of the box (but it seems to be in beta status).
>
> - There's a Starling port in haxe.
>
> Regarding Flex: haxe compiler could bring to flex things like 
> *metadata
> evolution* or *AOP*. Adobe compiler will never get that evolution 
> since gamming is not focused in that kind of things...This is more 
> likely to see in haxe if Flex 5 works than expect it from Adobe.
>
> Drawbacks:
>
> IDE: IntelliJ+haxe plugin. IntelliJ is the best option for Flex, and 
> supports haxe, but I think haxeNME is not supported yet. But IntelliJ 
> guys are behind the plugin, so things could evolve ok in this point.
>
> MXML: I think there's nothing like MXML in haxe today, and this is one 
> of the key points in Flex. We would need to put the efforts of MXML in 
> making it possible in haxe. We could talk with Nicolas Canesse about 
> this possibility. Since Falcon has little support of MXML, I see we 
> don't loose almost nothing.
>
> So my proposal is:
>
> * Start Flex 5 from scratch with haxe.
>
> * Use the Flex 4 API to model Flex 5 over haxe (as the first draft).
>
> * Start using Starling haxe library as the core displayobject API (to 
> be able to target Stage3D/Workers in  Flash).
>
> * Make an UIComponent decoupled implementation based on composition 
> over inheritance (here experience of Alex Harui and other will be very 
> wellcome to start with a good foundation).
>
> Optional:
>
> * Take into account the SWF and HTML5 outputs in the first drafts.
>
> This would start as an experiment based on fun of coding, and we could 
> see where it goes over time. If it gets momentum, people join the 
> cause, and so on...
>
>
>
> --
> Carlos Rovira
> Director de Tecnología
> M: +34 607 22 60 05
> F:  +34 912 35 57 77
> http://www.codeoscopic.com
> http://www.directwriter.es
> http://www.avant2.es
>

-- 
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com

RE: Flex 5 in haxe

[Michael Schmalle <ap...@teotigraphix.com>]

Folks,

I have sat out this whole day reading everything.

This statement of Gordon's is golden and should be taken seriously. I  
have no idea what the answer is to the 100's of posts today but one  
thing is clear, break the Adobe dependencies however possible and  
don't count on them.

I was also going to say this as well about the MXML compiler, it is  
really not "stuck" to any particular implementation in the and as far  
as language. That is why I brought up what I did about Android and the  
view layer the other day because the compiler in reality is abstract.

Mike

Quoting Gordon Smith <go...@adobe.com>:

> If Haxe really produces fast-running and good-looking apps on all  
> platforms of interest (does it?), I think it should be a top  
> contender since it is open-source. You could throw away the  
> ActionScript part of Falcon and make the MXML part of Falcon produce  
> Haxe source code. MXML script blocks, event handlers, and  
> databindings in apps would have to switch to using Haxe (as of  
> course would the app's AS files and the entire Flex framework).
>
> My advice is to avoid tying Flex to any proprietary Adobe technology  
> going forward -- whether AS4, V11, or V12  -- because Adobe's  
> language and platform strategy is no longer is alignment with what  
> Flex needs.
>
> - Gordon
>
> -----Original Message-----
> From: Gordon Smith
> Sent: Friday, November 16, 2012 11:28 AM
> To: flex-dev@incubator.apache.org
> Subject: RE: Flex 5 in haxe
>
>> Since Falcon has little support of MXML, I see we don't loose  
>> almost nothing.
>
> Given that Falcon can compile MXML apps like Checkinapp, I don't  
> think it's accurate to characterize its level of MXML support as  
> "little". My own characterization would be "80% complete". But  
> completing the other 20% is a daunting task ( it's certainly many  
> person-months of work) and not enough people are stepping up to  
> help. I'm guessing that this is because the major companies who used  
> to use Flex and swore that they had plenty of compiler engineers who  
> would help finish Falcon have moved on to other technologies.
>
> So I agree that any and all compiler technologies, including Haxe,  
> should get serious consideration.
>
> However, I think before Apache Flex makes a compiler decision, it  
> needs to decide what runtimes it is targeting. Move to V12? Abandon  
> Flash? Produce HTML/JS? Produce native iOS code? Produce native Java  
> for Android?
>
> - Gordon
>
>
> -----Original Message-----
> From: carlos.rovira@gmail.com [mailto:carlos.rovira@gmail.com] On  
> Behalf Of Carlos Rovira
> Sent: Friday, November 16, 2012 2:49 AM
> To: flex-dev@incubator.apache.org
> Subject: Flex 5 in haxe
>
> Hi,
>
> as we were discussing yesterday, there's room to a new Flex  
> framework written from scratch. As we don't want to rely in Adobe  
> technologies anymore we were talking about haxe. We can make it now  
> that work would be starting from zero.
>
> Haxe is a platform developed by Nicolas Canesse that made it's own  
> community. Nicolas is a genius of compilers. People coming from  
> Flash Open Source will remember MTASC compiler back in 2004-5. If  
> you search and investigate you will found that haxe is very powerful  
> and is "the great unknown technology".
>
> http://haxe.org/
>
> haxeNME is like Adobe AIR and seems to be more performant in iOS,  
> and Android (see  
> http://esdot.ca/site/2012/performance-showdown-starling-vs-nd2d-vs-genome2d-vs-haxe-nme).
> Supports as well Windows, Mac, Linux and BB.
>
> http://www.haxenme.org/
>
> There's an haxe plugin for IntelliJ. But in my test it seems that  
> only supports haxe and not NME yet.
>
> (Disclaimer: I'm to new to haxe and haxeNME and maybe I wrong making  
> some statements here).
>
> - Haxe is OOP and is "one language to rule them all" philoshopy.
>
> - Haxe compiler is better that the set provided by Adobe (I'm referring to
> AS3 legacy compiler. Falcon is new technology and maybe this is not  
> true. I does not have any info to make a comparision between falcon  
> and haxe compiler).
>
> - Haxe language is more evolved (maybe even Adobe AS4 will copy things from
> haxe...)
>
> - Haxe support HTML5/JS out of the box (but it seems to be in beta status).
>
> - There's a Starling port in haxe.
>
> Regarding Flex: haxe compiler could bring to flex things like *metadata
> evolution* or *AOP*. Adobe compiler will never get that evolution  
> since gamming is not focused in that kind of things...This is more  
> likely to see in haxe if Flex 5 works than expect it from Adobe.
>
> Drawbacks:
>
> IDE: IntelliJ+haxe plugin. IntelliJ is the best option for Flex, and  
> supports haxe, but I think haxeNME is not supported yet. But  
> IntelliJ guys are behind the plugin, so things could evolve ok in  
> this point.
>
> MXML: I think there's nothing like MXML in haxe today, and this is  
> one of the key points in Flex. We would need to put the efforts of  
> MXML in making it possible in haxe. We could talk with Nicolas  
> Canesse about this possibility. Since Falcon has little support of  
> MXML, I see we don't loose almost nothing.
>
> So my proposal is:
>
> * Start Flex 5 from scratch with haxe.
>
> * Use the Flex 4 API to model Flex 5 over haxe (as the first draft).
>
> * Start using Starling haxe library as the core displayobject API  
> (to be able to target Stage3D/Workers in  Flash).
>
> * Make an UIComponent decoupled implementation based on composition  
> over inheritance (here experience of Alex Harui and other will be  
> very wellcome to start with a good foundation).
>
> Optional:
>
> * Take into account the SWF and HTML5 outputs in the first drafts.
>
> This would start as an experiment based on fun of coding, and we  
> could see where it goes over time. If it gets momentum, people join  
> the cause, and so on...
>
>
>
> --
> Carlos Rovira
> Director de Tecnología
> M: +34 607 22 60 05
> F:  +34 912 35 57 77
> http://www.codeoscopic.com
> http://www.directwriter.es
> http://www.avant2.es
>

-- 
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com

Re: Flex 5 in haxe

[Carlos Rovira <ca...@codeoscopic.com>]

Hi Gordon,

yes thats exactly my point of view regarding a new flex from scratch.
Regarding current Flex 4.x...evidently we are tied.

Coming from you, is very valuable comment, and should make think many of us
in this list.


2012/11/16 Gordon Smith <go...@adobe.com>

>
> My advice is to avoid tying Flex to any proprietary Adobe technology going
> forward -- whether AS4, V11, or V12  -- because Adobe's language and
> platform strategy is no longer is alignment with what Flex needs.
>
> - Gordon
>
>
-- 
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F:  +34 912 35 57 77
http://www.codeoscopic.com
http://www.directwriter.es
http://www.avant2.es

RE: Flex 5 in haxe

[Gordon Smith <go...@adobe.com>]

If Haxe really produces fast-running and good-looking apps on all platforms of interest (does it?), I think it should be a top contender since it is open-source. You could throw away the ActionScript part of Falcon and make the MXML part of Falcon produce Haxe source code. MXML script blocks, event handlers, and databindings in apps would have to switch to using Haxe (as of course would the app's AS files and the entire Flex framework).

My advice is to avoid tying Flex to any proprietary Adobe technology going forward -- whether AS4, V11, or V12  -- because Adobe's language and platform strategy is no longer is alignment with what Flex needs.

- Gordon

-----Original Message-----
From: Gordon Smith 
Sent: Friday, November 16, 2012 11:28 AM
To: flex-dev@incubator.apache.org
Subject: RE: Flex 5 in haxe

> Since Falcon has little support of MXML, I see we don't loose almost nothing.

Given that Falcon can compile MXML apps like Checkinapp, I don't think it's accurate to characterize its level of MXML support as "little". My own characterization would be "80% complete". But completing the other 20% is a daunting task ( it's certainly many person-months of work) and not enough people are stepping up to help. I'm guessing that this is because the major companies who used to use Flex and swore that they had plenty of compiler engineers who would help finish Falcon have moved on to other technologies.

So I agree that any and all compiler technologies, including Haxe, should get serious consideration.

However, I think before Apache Flex makes a compiler decision, it needs to decide what runtimes it is targeting. Move to V12? Abandon Flash? Produce HTML/JS? Produce native iOS code? Produce native Java for Android?

- Gordon


-----Original Message-----
From: carlos.rovira@gmail.com [mailto:carlos.rovira@gmail.com] On Behalf Of Carlos Rovira
Sent: Friday, November 16, 2012 2:49 AM
To: flex-dev@incubator.apache.org
Subject: Flex 5 in haxe

Hi,

as we were discussing yesterday, there's room to a new Flex framework written from scratch. As we don't want to rely in Adobe technologies anymore we were talking about haxe. We can make it now that work would be starting from zero.

Haxe is a platform developed by Nicolas Canesse that made it's own community. Nicolas is a genius of compilers. People coming from Flash Open Source will remember MTASC compiler back in 2004-5. If you search and investigate you will found that haxe is very powerful and is "the great unknown technology".

http://haxe.org/

haxeNME is like Adobe AIR and seems to be more performant in iOS, and Android (see http://esdot.ca/site/2012/performance-showdown-starling-vs-nd2d-vs-genome2d-vs-haxe-nme).
Supports as well Windows, Mac, Linux and BB.

http://www.haxenme.org/

There's an haxe plugin for IntelliJ. But in my test it seems that only supports haxe and not NME yet.

(Disclaimer: I'm to new to haxe and haxeNME and maybe I wrong making some statements here).

- Haxe is OOP and is "one language to rule them all" philoshopy.

- Haxe compiler is better that the set provided by Adobe (I'm referring to
AS3 legacy compiler. Falcon is new technology and maybe this is not true. I does not have any info to make a comparision between falcon and haxe compiler).

- Haxe language is more evolved (maybe even Adobe AS4 will copy things from
haxe...)

- Haxe support HTML5/JS out of the box (but it seems to be in beta status).

- There's a Starling port in haxe.

Regarding Flex: haxe compiler could bring to flex things like *metadata
evolution* or *AOP*. Adobe compiler will never get that evolution since gamming is not focused in that kind of things...This is more likely to see in haxe if Flex 5 works than expect it from Adobe.

Drawbacks:

IDE: IntelliJ+haxe plugin. IntelliJ is the best option for Flex, and supports haxe, but I think haxeNME is not supported yet. But IntelliJ guys are behind the plugin, so things could evolve ok in this point.

MXML: I think there's nothing like MXML in haxe today, and this is one of the key points in Flex. We would need to put the efforts of MXML in making it possible in haxe. We could talk with Nicolas Canesse about this possibility. Since Falcon has little support of MXML, I see we don't loose almost nothing.

So my proposal is:

* Start Flex 5 from scratch with haxe.

* Use the Flex 4 API to model Flex 5 over haxe (as the first draft).

* Start using Starling haxe library as the core displayobject API (to be able to target Stage3D/Workers in  Flash).

* Make an UIComponent decoupled implementation based on composition over inheritance (here experience of Alex Harui and other will be very wellcome to start with a good foundation).

Optional:

* Take into account the SWF and HTML5 outputs in the first drafts.

This would start as an experiment based on fun of coding, and we could see where it goes over time. If it gets momentum, people join the cause, and so on...



--
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F:  +34 912 35 57 77
http://www.codeoscopic.com
http://www.directwriter.es
http://www.avant2.es

Re: Flex 5 in haxe

[Nicholas Kwiatkowski <ni...@spoon.as>]

We have the compiler -- why can't we just adapt the output to another
platform instead of the input.  We are only limited to the input standards
we create outselves.  Nothing in the compiler is forcing us to output to
SWF.

-Nick

On Fri, Nov 16, 2012 at 10:51 AM, Carlos Rovira <
carlos.rovira@codeoscopic.com> wrote:

> > But bad news - in this situation i think guys from Adobe doesn't help us
> with new compiler.
>
> This should not be the motivation to go one way or another. Adobe's
> position is already shared and know: They want only gamming. They throw
> flex away. Tools, AVMs and languages are updated and designed only with
> gamming in mind...
>
> Alex, Carol and others are here payed by Adobe, but this project is made of
> individuals (although some of them are payed by a company). It's clear that
> Adobe could close the participation of their people, but this is a risk we
> could take if the main direction choosen is what Apache Flex need.
>
> We must think in what is the best for Apache Flex, and my position is that
> a rewrite make us free of technology or tool to choose. And we should not
> depend exclusively on Flash Platform and Adobe decisions. It's only a
> matter of choose a open source platform that's working and could give us
> support in the long term.
>
> Some months ago my thoughts was very different, but right now that a full
> rewrite is required, my opinion is clear about what to choose, and for
> something new, I choose Haxe.
>
>
>
>
> --
> Carlos Rovira
> Director de Tecnología
> M: +34 607 22 60 05
> F:  +34 912 35 57 77
> http://www.codeoscopic.com
> http://www.directwriter.es
> http://www.avant2.es
>

Re: Flex 5 in haxe

[sébastien Paturel <se...@gmail.com>]

if i get it well, we'r not talking about converting the framework to 
haxe, but to rewrite the framework from scratch on haxe. and using the 
same (or almost) flex API.
It seems so far that trying to port an existing flex to HTML5 whether it 
is with flex on haxe, or any other choice, will be quite a dream. Your 
best chance is on FalconJs which is only prototype and has low perfs
IMO we are more trying to find a way for future new projects to be fully 
cross platforms, but old ones will be stuck with current targets.



Le 16/11/2012 17:18, Justin Mclean a écrit :
> Hi,
>
>> Some months ago my thoughts was very different, but right now that a full
>> rewrite is required, my opinion is clear about what to choose, and for
>> something new, I choose Haxe.
> Can you outline what would be require to convert the existing Flex framework for use with Haxe? MXML (and binding) would be a stumbling block no?
>
> Assuming it was complete? How hard would it be for existing applications to be converted to use the new framework?
>
> I'm rather sceptical than even if the Flex framework was converted to Haxe (via conversion tools or otherwise) and we could target JS that way that it would be performant. unless someone tried I guess we don't know.
>
> Out of curiosity have you tried/taken a  look at the AS3 to Haxe converter?
> http://haxe.org/com/libs/as3hx
>
> Justin

Re: Flex 5 in haxe

[sébastien Paturel <se...@gmail.com>]

"it seems that moving Falcon to a direction where it can target other 
runtimes is going to take much less time than a complete rewrite of the 
framework"
Not sure at all. its hard to say, and maybe Gordon could try to answer.

Check my other thread: its not only a new target  / new language issue here!
If we want to get better performances, the framework has to be re 
architectured, and it seems (still has to be verified) that rewrite from 
scratch is more efficient than trying to use the current code base.


Le 16/11/2012 18:46, Nick Tsitlakidis a écrit :
> +1 to everything Nicholas Kwiatkowski stated.
>
> AS3 is a matured language and if your objective is to target other runtimes
> then you wouldn't convert to AS4 anyway.
>
> I'm not an expert on compilers but it seems that moving Falcon to a
> direction where it can target other runtimes is going to take much less
> time than a complete rewrite of the framework.
> In my opinion, at the moment the amount of commitment here is healthy but
> not large enough to have even a basic subset of Flex available soon if we
> rewrite the framework (whether it is haxe or AS4 or AS3 or whatever else)
>
> Planning for the future is key here but removing everything and starting
> again is not the right choice. We can plan for the future by looking more
> realistically on what targets we want for Flex. Then we can start spending
> time on creating a me lightweight architecture for the existing code and
> making sure that Falcon starts supporting the targets we want.
>
>
>
>
> On Fri, Nov 16, 2012 at 7:33 PM, Alain Ekambi <ja...@gmail.com>wrote:
>
>> Hello folks,
>>
>> I would like to add my 2 cents to this interesing discussion.
>>
>> First let me share my experience with the Flash platform.
>>
>> We  have been building Flash based solutions  for many years now.
>> We have  different set of products mostly based on GWT that cover all the
>> spectrum (Native mobile, HTML5 mobile, HTML5 Desktop, Flex, AIR ).
>> And i can tell you that our Flash based products are by faar the most
>> succesfull !
>> Hard to believe no ?
>>
>> A couple of weeks we had a beta release for the version 3 of our GWT
>> binding for Flash (http://emitrom.com/flash4j-beta).
>> Download numbers were just insane ! Breaking every records we ever had for
>> a products.
>> And that after all all the bad moves done by Adobe.
>>
>>
>> For what I can say 99% of our customers (And we have some big ones)  use
>> our Flash products  because it runs on the Flash player!
>> Not because it could compile down the JS.
>>
>> With all the respect there are simply way better JS based libraries.
>> If i want to target HTML5/JS/CSS today(and tomorrow) i def wont be thinking
>> about Flex/MXML/AS3.
>> The same apply for our customers.
>>
>> Some of you are talking about Flex/AIR on mobile and think that an HTML5
>>   output will make things better.
>> Let s keep it honest. Flex is simply a non factor on mobile and will never
>> be a major player.
>> No matter how we turn it.
>> And compiling to HTML5 wont change that. There are simply better
>> alternative on the market.
>>
>>
>> I ve said it many times on this forum.
>> All this talk about going  HTML5 with Flex is nice and surelly interesting
>> from a technical point.
>> But brings nothing to most customers.
>>
>>
>> Our focus should be on making Flex even better for Desktop RIA (I do have
>> some plans with FaBridge that i hope i will be able to commnunicate soon).
>>
>>
>> The rest is simply waste of energy and time.
>>
>> Cheers
>>
>>
>> 2012/11/16 Carlos Rovira <ca...@codeoscopic.com>
>>
>>> Hi Justin,
>>>
>>> as someone with lots of apps and products written in current Flex, I
>> would
>>> want to continue with my products migration to new versions. But the
>>> reality out there is that all ways points to a new rewrite. I'm sure
>> there
>>> are people here that wants maintain and evolutione the actual framework,
>>> great!
>>>
>>> I, as others prefer a new child, so I would spend my time in that kind of
>>> effort.
>>>
>>> btw, I see that mostly my apps and products will end if Flex 4.x, but
>> maybe
>>> some day could be migrated to the new Flex 5.x . All depends on how good
>>> that new framework came and if gets the necesary traction to mimic the
>>> actual Flex 4.x. Only time will tell, in the mean while, I'll try to
>>> upgrade to new Apache Flex official releases to stay up to the latest
>>> versions...
>>>
>>>
>>> 2012/11/16 Justin Mclean <ju...@classsoftware.com>
>>>
>>>> Hi,
>>>>
>>>>> a new flex 5 from scratch concept would not be trying to be
>> compatible
>>>> backwards.
>>>> So it's not Flex then but a new framework. I'm sure that would be fun,
>>> but
>>>> how would that serve the current users of the Flex framework? Would
>> there
>>>> be a clear migration path?
>>>>
>>>>> If the task of write a new Flex is huge...
>>>> So let don't and try and improved the one we do have, it's sounds a lot
>>>> easier to do and more useful to me.
>>>>
>>>> Just my opinion, and you're free to do what you want on an Apache
>>> project,
>>>> so don't let me stop you :-)
>>>>
>>>> Justin
>>>
>>>
>>>
>>> --
>>> Carlos Rovira
>>> Director de Tecnología
>>> M: +34 607 22 60 05
>>> F:  +34 912 35 57 77
>>> http://www.codeoscopic.com
>>> http://www.directwriter.es
>>> http://www.avant2.es
>>>
>
>

Re: Flex 5 in haxe

[Nick Tsitlakidis <ni...@perfectedz.com>]

+1 to everything Nicholas Kwiatkowski stated.

AS3 is a matured language and if your objective is to target other runtimes
then you wouldn't convert to AS4 anyway.

I'm not an expert on compilers but it seems that moving Falcon to a
direction where it can target other runtimes is going to take much less
time than a complete rewrite of the framework.
In my opinion, at the moment the amount of commitment here is healthy but
not large enough to have even a basic subset of Flex available soon if we
rewrite the framework (whether it is haxe or AS4 or AS3 or whatever else)

Planning for the future is key here but removing everything and starting
again is not the right choice. We can plan for the future by looking more
realistically on what targets we want for Flex. Then we can start spending
time on creating a me lightweight architecture for the existing code and
making sure that Falcon starts supporting the targets we want.




On Fri, Nov 16, 2012 at 7:33 PM, Alain Ekambi <ja...@gmail.com>wrote:

> Hello folks,
>
> I would like to add my 2 cents to this interesing discussion.
>
> First let me share my experience with the Flash platform.
>
> We  have been building Flash based solutions  for many years now.
> We have  different set of products mostly based on GWT that cover all the
> spectrum (Native mobile, HTML5 mobile, HTML5 Desktop, Flex, AIR ).
> And i can tell you that our Flash based products are by faar the most
> succesfull !
> Hard to believe no ?
>
> A couple of weeks we had a beta release for the version 3 of our GWT
> binding for Flash (http://emitrom.com/flash4j-beta).
> Download numbers were just insane ! Breaking every records we ever had for
> a products.
> And that after all all the bad moves done by Adobe.
>
>
> For what I can say 99% of our customers (And we have some big ones)  use
> our Flash products  because it runs on the Flash player!
> Not because it could compile down the JS.
>
> With all the respect there are simply way better JS based libraries.
> If i want to target HTML5/JS/CSS today(and tomorrow) i def wont be thinking
> about Flex/MXML/AS3.
> The same apply for our customers.
>
> Some of you are talking about Flex/AIR on mobile and think that an HTML5
>  output will make things better.
> Let s keep it honest. Flex is simply a non factor on mobile and will never
> be a major player.
> No matter how we turn it.
> And compiling to HTML5 wont change that. There are simply better
> alternative on the market.
>
>
> I ve said it many times on this forum.
> All this talk about going  HTML5 with Flex is nice and surelly interesting
> from a technical point.
> But brings nothing to most customers.
>
>
> Our focus should be on making Flex even better for Desktop RIA (I do have
> some plans with FaBridge that i hope i will be able to commnunicate soon).
>
>
> The rest is simply waste of energy and time.
>
> Cheers
>
>
> 2012/11/16 Carlos Rovira <ca...@codeoscopic.com>
>
> > Hi Justin,
> >
> > as someone with lots of apps and products written in current Flex, I
> would
> > want to continue with my products migration to new versions. But the
> > reality out there is that all ways points to a new rewrite. I'm sure
> there
> > are people here that wants maintain and evolutione the actual framework,
> > great!
> >
> > I, as others prefer a new child, so I would spend my time in that kind of
> > effort.
> >
> > btw, I see that mostly my apps and products will end if Flex 4.x, but
> maybe
> > some day could be migrated to the new Flex 5.x . All depends on how good
> > that new framework came and if gets the necesary traction to mimic the
> > actual Flex 4.x. Only time will tell, in the mean while, I'll try to
> > upgrade to new Apache Flex official releases to stay up to the latest
> > versions...
> >
> >
> > 2012/11/16 Justin Mclean <ju...@classsoftware.com>
> >
> > > Hi,
> > >
> > > > a new flex 5 from scratch concept would not be trying to be
> compatible
> > > backwards.
> > > So it's not Flex then but a new framework. I'm sure that would be fun,
> > but
> > > how would that serve the current users of the Flex framework? Would
> there
> > > be a clear migration path?
> > >
> > > > If the task of write a new Flex is huge...
> > > So let don't and try and improved the one we do have, it's sounds a lot
> > > easier to do and more useful to me.
> > >
> > > Just my opinion, and you're free to do what you want on an Apache
> > project,
> > > so don't let me stop you :-)
> > >
> > > Justin
> >
> >
> >
> >
> > --
> > Carlos Rovira
> > Director de Tecnología
> > M: +34 607 22 60 05
> > F:  +34 912 35 57 77
> > http://www.codeoscopic.com
> > http://www.directwriter.es
> > http://www.avant2.es
> >
>



-- 
Nick Tsitlakidis,

CEO and Software Architect at Perfect Edge LTD.
www.perfectedz.com

Re: Flex 5 in haxe

[sébastien Paturel <se...@gmail.com>]

Hi,
it sounds quite like a short term vision to me.
yes i agree that flex is still good solution for TODAY running on Adobes 
runtimes.
maybe for a few years also but its risky and totally Adobe dependant.

Of course theres better JS fraework for HTML5, because flex don't 
support HTML5. Flex is not an alternative, so how could there be better 
alternatives on the market?
Before flex was able to create native mobile apps, you or your customers 
would have never think of Flex for that.
Now it can do it then it becomes a viable alternative.
So if Flex support an HTML5 output, it will be the same result.

We all agree that in the short term flex would have little value to run 
on HTML5 has it is TODAY.
But when tomorrow, with better performances of HTML5, Flex could become 
the best RIA framework for HTML5 output. why not?

"Let s keep it honest. Flex is simply a non factor on mobile and will 
never be a major player. No matter how we turn it."
What makes you say that?
its not a big player because as soon as it was able to run efficiently 
with 4.6 Adobe dropped it with all the mess we know.
thats only pessimism.

"Our focus should be on making Flex even better for Desktop RIA"
But what you do when Desktops are only tablets OS and Adobe runtimes are 
not running on it?
And what you do when webApps get more popular than natives apps in 6 
years for example and theres still no flash player in mobile browsers?


Le 16/11/2012 18:33, Alain Ekambi a écrit :
> Hello folks,
>
> I would like to add my 2 cents to this interesing discussion.
>
> First let me share my experience with the Flash platform.
>
> We  have been building Flash based solutions  for many years now.
> We have  different set of products mostly based on GWT that cover all the
> spectrum (Native mobile, HTML5 mobile, HTML5 Desktop, Flex, AIR ).
> And i can tell you that our Flash based products are by faar the most
> succesfull !
> Hard to believe no ?
>
> A couple of weeks we had a beta release for the version 3 of our GWT
> binding for Flash (http://emitrom.com/flash4j-beta).
> Download numbers were just insane ! Breaking every records we ever had for
> a products.
> And that after all all the bad moves done by Adobe.
>
>
> For what I can say 99% of our customers (And we have some big ones)  use
> our Flash products  because it runs on the Flash player!
> Not because it could compile down the JS.
>
> With all the respect there are simply way better JS based libraries.
> If i want to target HTML5/JS/CSS today(and tomorrow) i def wont be thinking
> about Flex/MXML/AS3.
> The same apply for our customers.
>
> Some of you are talking about Flex/AIR on mobile and think that an HTML5
>   output will make things better.
> Let s keep it honest. Flex is simply a non factor on mobile and will never
> be a major player.
> No matter how we turn it.
> And compiling to HTML5 wont change that. There are simply better
> alternative on the market.
>
>
> I ve said it many times on this forum.
> All this talk about going  HTML5 with Flex is nice and surelly interesting
> from a technical point.
> But brings nothing to most customers.
>
>
> Our focus should be on making Flex even better for Desktop RIA (I do have
> some plans with FaBridge that i hope i will be able to commnunicate soon).
>
>
> The rest is simply waste of energy and time.
>
> Cheers
>
>
> 2012/11/16 Carlos Rovira <ca...@codeoscopic.com>
>
>> Hi Justin,
>>
>> as someone with lots of apps and products written in current Flex, I would
>> want to continue with my products migration to new versions. But the
>> reality out there is that all ways points to a new rewrite. I'm sure there
>> are people here that wants maintain and evolutione the actual framework,
>> great!
>>
>> I, as others prefer a new child, so I would spend my time in that kind of
>> effort.
>>
>> btw, I see that mostly my apps and products will end if Flex 4.x, but maybe
>> some day could be migrated to the new Flex 5.x . All depends on how good
>> that new framework came and if gets the necesary traction to mimic the
>> actual Flex 4.x. Only time will tell, in the mean while, I'll try to
>> upgrade to new Apache Flex official releases to stay up to the latest
>> versions...
>>
>>
>> 2012/11/16 Justin Mclean <ju...@classsoftware.com>
>>
>>> Hi,
>>>
>>>> a new flex 5 from scratch concept would not be trying to be compatible
>>> backwards.
>>> So it's not Flex then but a new framework. I'm sure that would be fun,
>> but
>>> how would that serve the current users of the Flex framework? Would there
>>> be a clear migration path?
>>>
>>>> If the task of write a new Flex is huge...
>>> So let don't and try and improved the one we do have, it's sounds a lot
>>> easier to do and more useful to me.
>>>
>>> Just my opinion, and you're free to do what you want on an Apache
>> project,
>>> so don't let me stop you :-)
>>>
>>> Justin
>>
>>
>>
>> --
>> Carlos Rovira
>> Director de Tecnología
>> M: +34 607 22 60 05
>> F:  +34 912 35 57 77
>> http://www.codeoscopic.com
>> http://www.directwriter.es
>> http://www.avant2.es
>>

Re: Flex 5 in haxe

[Alain Ekambi <ja...@gmail.com>]

Hello folks,

I would like to add my 2 cents to this interesing discussion.

First let me share my experience with the Flash platform.

We  have been building Flash based solutions  for many years now.
We have  different set of products mostly based on GWT that cover all the
spectrum (Native mobile, HTML5 mobile, HTML5 Desktop, Flex, AIR ).
And i can tell you that our Flash based products are by faar the most
succesfull !
Hard to believe no ?

A couple of weeks we had a beta release for the version 3 of our GWT
binding for Flash (http://emitrom.com/flash4j-beta).
Download numbers were just insane ! Breaking every records we ever had for
a products.
And that after all all the bad moves done by Adobe.


For what I can say 99% of our customers (And we have some big ones)  use
our Flash products  because it runs on the Flash player!
Not because it could compile down the JS.

With all the respect there are simply way better JS based libraries.
If i want to target HTML5/JS/CSS today(and tomorrow) i def wont be thinking
about Flex/MXML/AS3.
The same apply for our customers.

Some of you are talking about Flex/AIR on mobile and think that an HTML5
 output will make things better.
Let s keep it honest. Flex is simply a non factor on mobile and will never
be a major player.
No matter how we turn it.
And compiling to HTML5 wont change that. There are simply better
alternative on the market.


I ve said it many times on this forum.
All this talk about going  HTML5 with Flex is nice and surelly interesting
from a technical point.
But brings nothing to most customers.


Our focus should be on making Flex even better for Desktop RIA (I do have
some plans with FaBridge that i hope i will be able to commnunicate soon).


The rest is simply waste of energy and time.

Cheers


2012/11/16 Carlos Rovira <ca...@codeoscopic.com>

> Hi Justin,
>
> as someone with lots of apps and products written in current Flex, I would
> want to continue with my products migration to new versions. But the
> reality out there is that all ways points to a new rewrite. I'm sure there
> are people here that wants maintain and evolutione the actual framework,
> great!
>
> I, as others prefer a new child, so I would spend my time in that kind of
> effort.
>
> btw, I see that mostly my apps and products will end if Flex 4.x, but maybe
> some day could be migrated to the new Flex 5.x . All depends on how good
> that new framework came and if gets the necesary traction to mimic the
> actual Flex 4.x. Only time will tell, in the mean while, I'll try to
> upgrade to new Apache Flex official releases to stay up to the latest
> versions...
>
>
> 2012/11/16 Justin Mclean <ju...@classsoftware.com>
>
> > Hi,
> >
> > > a new flex 5 from scratch concept would not be trying to be compatible
> > backwards.
> > So it's not Flex then but a new framework. I'm sure that would be fun,
> but
> > how would that serve the current users of the Flex framework? Would there
> > be a clear migration path?
> >
> > > If the task of write a new Flex is huge...
> > So let don't and try and improved the one we do have, it's sounds a lot
> > easier to do and more useful to me.
> >
> > Just my opinion, and you're free to do what you want on an Apache
> project,
> > so don't let me stop you :-)
> >
> > Justin
>
>
>
>
> --
> Carlos Rovira
> Director de Tecnología
> M: +34 607 22 60 05
> F:  +34 912 35 57 77
> http://www.codeoscopic.com
> http://www.directwriter.es
> http://www.avant2.es
>

Re: Flex 5 in haxe

[Carlos Rovira <ca...@codeoscopic.com>]

Hi Justin,

as someone with lots of apps and products written in current Flex, I would
want to continue with my products migration to new versions. But the
reality out there is that all ways points to a new rewrite. I'm sure there
are people here that wants maintain and evolutione the actual framework,
great!

I, as others prefer a new child, so I would spend my time in that kind of
effort.

btw, I see that mostly my apps and products will end if Flex 4.x, but maybe
some day could be migrated to the new Flex 5.x . All depends on how good
that new framework came and if gets the necesary traction to mimic the
actual Flex 4.x. Only time will tell, in the mean while, I'll try to
upgrade to new Apache Flex official releases to stay up to the latest
versions...


2012/11/16 Justin Mclean <ju...@classsoftware.com>

> Hi,
>
> > a new flex 5 from scratch concept would not be trying to be compatible
> backwards.
> So it's not Flex then but a new framework. I'm sure that would be fun, but
> how would that serve the current users of the Flex framework? Would there
> be a clear migration path?
>
> > If the task of write a new Flex is huge...
> So let don't and try and improved the one we do have, it's sounds a lot
> easier to do and more useful to me.
>
> Just my opinion, and you're free to do what you want on an Apache project,
> so don't let me stop you :-)
>
> Justin




-- 
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F:  +34 912 35 57 77
http://www.codeoscopic.com
http://www.directwriter.es
http://www.avant2.es

Re: Flex 5 in haxe

[Omar Gonzalez <om...@gmail.com>]

On Fri, Nov 16, 2012 at 9:05 AM, Justin Mclean <ju...@classsoftware.com>wrote:

> Hi,
>
> > a new flex 5 from scratch concept would not be trying to be compatible
> backwards.
> So it's not Flex then but a new framework. I'm sure that would be fun, but
> how would that serve the current users of the Flex framework? Would there
> be a clear migration path?
>

Not ever major release of every framework provides a clear migration path.
Sometimes it is time to leave the old be and move on to a brighter, better
future.


>
> > If the task of write a new Flex is huge...
> So let don't and try and improved the one we do have, it's sounds a lot
> easier to do and more useful to me.
>
> Just my opinion, and you're free to do what you want on an Apache project,
> so don't let me stop you :-)
>
> Justin


It certainly could be more useful now, but there is an EOL on the current
path. Some of us want to think of and work on life after dependency on
Adobe technologies. Flash used to be the path for platform ubiquity, that
story is long dead.

-omar

Re: Flex 5 in haxe

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> a new flex 5 from scratch concept would not be trying to be compatible backwards.
So it's not Flex then but a new framework. I'm sure that would be fun, but how would that serve the current users of the Flex framework? Would there be a clear migration path? 

> If the task of write a new Flex is huge...
So let don't and try and improved the one we do have, it's sounds a lot easier to do and more useful to me.

Just my opinion, and you're free to do what you want on an Apache project, so don't let me stop you :-)

Justin

Re: Flex 5 in haxe

[Carlos Rovira <ca...@codeoscopic.com>]

Hi Justin,

a new flex 5 from scratch concept would not be trying to be compatible
backwards. If the task of write a new Flex is huge...make it backwards
compatible will be totaly utopic IMHO. So as my last line in my propossal
says...we should try to start with something like an experiment, to share
with the community and see if it gains traction. I'll go the "coding for
fun" way and not trying to go far beyond that line in the first steps. Then
things could get more serious...

If we use the same API in flex migration could be somewhat possible, but,
again I would not try to put that goal in that project. For that I'm sure
that other people in this project would want to maintain and continue the
Fx4.x branch. We could event reserve the 5.x number for it...and go Flex 6
with haxe...

Regarding haxe-js, I don't know too much since although I know haxe from
the very beginning I never did nothing in that technology, so again it
would be something to learn and experiment.





2012/11/16 Justin Mclean <ju...@classsoftware.com>

> Hi,
>
> > Some months ago my thoughts was very different, but right now that a full
> > rewrite is required, my opinion is clear about what to choose, and for
> > something new, I choose Haxe.
>
> Can you outline what would be require to convert the existing Flex
> framework for use with Haxe? MXML (and binding) would be a stumbling block
> no?
>
> Assuming it was complete? How hard would it be for existing applications
> to be converted to use the new framework?
>
> I'm rather sceptical than even if the Flex framework was converted to Haxe
> (via conversion tools or otherwise) and we could target JS that way that it
> would be performant. unless someone tried I guess we don't know.
>
> Out of curiosity have you tried/taken a  look at the AS3 to Haxe converter?
> http://haxe.org/com/libs/as3hx
>
> Justin




-- 
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F:  +34 912 35 57 77
http://www.codeoscopic.com
http://www.directwriter.es
http://www.avant2.es

Re: Flex 5 in haxe

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> Some months ago my thoughts was very different, but right now that a full
> rewrite is required, my opinion is clear about what to choose, and for
> something new, I choose Haxe.

Can you outline what would be require to convert the existing Flex framework for use with Haxe? MXML (and binding) would be a stumbling block no?

Assuming it was complete? How hard would it be for existing applications to be converted to use the new framework? 

I'm rather sceptical than even if the Flex framework was converted to Haxe (via conversion tools or otherwise) and we could target JS that way that it would be performant. unless someone tried I guess we don't know.

Out of curiosity have you tried/taken a  look at the AS3 to Haxe converter?
http://haxe.org/com/libs/as3hx

Justin

Re: Flex 5 in haxe

[Ben Dalton <be...@gmail.com>]

I am not entirely familiar either and I didn't mean to imply that I have
any strong complaints with the way Haxe does things. I did read some forum
posts about about others making a slew of suggestions regarding the way
it's implemented and the product of the compilation for JS. Since I haven't
investigated this topic in depth, I'm not "100% sold" as I mentioned in the
last email.

What I meant by relatively obscure is that the project hasn't reached the
level of popularity or developer commitment as something like PHP or Ruby.
While it certainly isn't an apples-to-apples comparison, there is certainly
a different between adding a dependency to an OSS project like PHP vs.
Haxe. I'm not saying that Haxe is going away, I'm just saying that it bears
consideration that there are not millions of developers contributing to and
using that platform.





On Fri, Nov 16, 2012 at 8:10 AM, Omar Gonzalez <om...@gmail.com>wrote:

> So I'm not that intimately familiar with how it compiles to JS, can you
> elaborate on your concern here?
>
> Also, why do you say haxe is obscure? It is entirely open source, what's
> obscure about that?
>
> -omar
>
> On Friday, November 16, 2012, Ben Dalton wrote:
>
> > Not to add fuel to the fire, but is choosing another platform like Haxe
> as
> > a core dependency of our project really a good idea?
> >
> > I like Haxe as a concept, but I'm not 100% sold on the way they implement
> > the multiple compile targets (especially JS/HTML) AND am certainly
> > concerned that the future of Flex would be so intertwined with this other
> > relatively obscure project.
> >
> > Though it would enable a shorter path in the near term, depending on
> > another translation/compilation layer looks risky to me both in terms of
> > Flex's capabilities and longevity.
> >
> > Thoughts?
> >
> > On Fri, Nov 16, 2012 at 7:51 AM, Carlos Rovira <
> > carlos.rovira@codeoscopic.com <javascript:;>> wrote:
> >
> > > > But bad news - in this situation i think guys from Adobe doesn't help
> > us
> > > with new compiler.
> > >
> > > This should not be the motivation to go one way or another. Adobe's
> > > position is already shared and know: They want only gamming. They throw
> > > flex away. Tools, AVMs and languages are updated and designed only with
> > > gamming in mind...
> > >
> > > Alex, Carol and others are here payed by Adobe, but this project is
> made
> > of
> > > individuals (although some of them are payed by a company). It's clear
> > that
> > > Adobe could close the participation of their people, but this is a risk
> > we
> > > could take if the main direction choosen is what Apache Flex need.
> > >
> > > We must think in what is the best for Apache Flex, and my position is
> > that
> > > a rewrite make us free of technology or tool to choose. And we should
> not
> > > depend exclusively on Flash Platform and Adobe decisions. It's only a
> > > matter of choose a open source platform that's working and could give
> us
> > > support in the long term.
> > >
> > > Some months ago my thoughts was very different, but right now that a
> full
> > > rewrite is required, my opinion is clear about what to choose, and for
> > > something new, I choose Haxe.
> > >
> > >
> > >
> > >
> > > --
> > > Carlos Rovira
> > > Director de Tecnología
> > > M: +34 607 22 60 05
> > > F:  +34 912 35 57 77
> > > http://www.codeoscopic.com
> > > http://www.directwriter.es
> > > http://www.avant2.es
> > >
> >
>

Re: Flex 5 in haxe

[Omar Gonzalez <om...@gmail.com>]

So I'm not that intimately familiar with how it compiles to JS, can you
elaborate on your concern here?

Also, why do you say haxe is obscure? It is entirely open source, what's
obscure about that?

-omar

On Friday, November 16, 2012, Ben Dalton wrote:

> Not to add fuel to the fire, but is choosing another platform like Haxe as
> a core dependency of our project really a good idea?
>
> I like Haxe as a concept, but I'm not 100% sold on the way they implement
> the multiple compile targets (especially JS/HTML) AND am certainly
> concerned that the future of Flex would be so intertwined with this other
> relatively obscure project.
>
> Though it would enable a shorter path in the near term, depending on
> another translation/compilation layer looks risky to me both in terms of
> Flex's capabilities and longevity.
>
> Thoughts?
>
> On Fri, Nov 16, 2012 at 7:51 AM, Carlos Rovira <
> carlos.rovira@codeoscopic.com <javascript:;>> wrote:
>
> > > But bad news - in this situation i think guys from Adobe doesn't help
> us
> > with new compiler.
> >
> > This should not be the motivation to go one way or another. Adobe's
> > position is already shared and know: They want only gamming. They throw
> > flex away. Tools, AVMs and languages are updated and designed only with
> > gamming in mind...
> >
> > Alex, Carol and others are here payed by Adobe, but this project is made
> of
> > individuals (although some of them are payed by a company). It's clear
> that
> > Adobe could close the participation of their people, but this is a risk
> we
> > could take if the main direction choosen is what Apache Flex need.
> >
> > We must think in what is the best for Apache Flex, and my position is
> that
> > a rewrite make us free of technology or tool to choose. And we should not
> > depend exclusively on Flash Platform and Adobe decisions. It's only a
> > matter of choose a open source platform that's working and could give us
> > support in the long term.
> >
> > Some months ago my thoughts was very different, but right now that a full
> > rewrite is required, my opinion is clear about what to choose, and for
> > something new, I choose Haxe.
> >
> >
> >
> >
> > --
> > Carlos Rovira
> > Director de Tecnología
> > M: +34 607 22 60 05
> > F:  +34 912 35 57 77
> > http://www.codeoscopic.com
> > http://www.directwriter.es
> > http://www.avant2.es
> >
>

Re: Flex 5 in haxe

[Ben Dalton <be...@gmail.com>]

Not to add fuel to the fire, but is choosing another platform like Haxe as
a core dependency of our project really a good idea?

I like Haxe as a concept, but I'm not 100% sold on the way they implement
the multiple compile targets (especially JS/HTML) AND am certainly
concerned that the future of Flex would be so intertwined with this other
relatively obscure project.

Though it would enable a shorter path in the near term, depending on
another translation/compilation layer looks risky to me both in terms of
Flex's capabilities and longevity.

Thoughts?

On Fri, Nov 16, 2012 at 7:51 AM, Carlos Rovira <
carlos.rovira@codeoscopic.com> wrote:

> > But bad news - in this situation i think guys from Adobe doesn't help us
> with new compiler.
>
> This should not be the motivation to go one way or another. Adobe's
> position is already shared and know: They want only gamming. They throw
> flex away. Tools, AVMs and languages are updated and designed only with
> gamming in mind...
>
> Alex, Carol and others are here payed by Adobe, but this project is made of
> individuals (although some of them are payed by a company). It's clear that
> Adobe could close the participation of their people, but this is a risk we
> could take if the main direction choosen is what Apache Flex need.
>
> We must think in what is the best for Apache Flex, and my position is that
> a rewrite make us free of technology or tool to choose. And we should not
> depend exclusively on Flash Platform and Adobe decisions. It's only a
> matter of choose a open source platform that's working and could give us
> support in the long term.
>
> Some months ago my thoughts was very different, but right now that a full
> rewrite is required, my opinion is clear about what to choose, and for
> something new, I choose Haxe.
>
>
>
>
> --
> Carlos Rovira
> Director de Tecnología
> M: +34 607 22 60 05
> F:  +34 912 35 57 77
> http://www.codeoscopic.com
> http://www.directwriter.es
> http://www.avant2.es
>

Re: Flex 5 in haxe

[Carlos Rovira <ca...@codeoscopic.com>]

> But bad news - in this situation i think guys from Adobe doesn't help us
with new compiler.

This should not be the motivation to go one way or another. Adobe's
position is already shared and know: They want only gamming. They throw
flex away. Tools, AVMs and languages are updated and designed only with
gamming in mind...

Alex, Carol and others are here payed by Adobe, but this project is made of
individuals (although some of them are payed by a company). It's clear that
Adobe could close the participation of their people, but this is a risk we
could take if the main direction choosen is what Apache Flex need.

We must think in what is the best for Apache Flex, and my position is that
a rewrite make us free of technology or tool to choose. And we should not
depend exclusively on Flash Platform and Adobe decisions. It's only a
matter of choose a open source platform that's working and could give us
support in the long term.

Some months ago my thoughts was very different, but right now that a full
rewrite is required, my opinion is clear about what to choose, and for
something new, I choose Haxe.




-- 
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F:  +34 912 35 57 77
http://www.codeoscopic.com
http://www.directwriter.es
http://www.avant2.es

Re: Flex 5 in haxe

[Jeffry Houser <je...@dot-com-it.com>]

  I'm still doing some new development; however the question of "Why not 
HTML5" is coming up more and more frequently

On 11/16/2012 5:09 PM, Gordon Smith wrote:
> I think that developers can continue to build good apps with AS3 and V11, but I'm assuming -- perhaps wrongly -- that the demand for them is going to decrease because companies see that Adobe is no longer investing many resources in them. Hasn't demand already fallen off over the last year? Are developers on this list still able to earn a living building new Flex apps, or are you maintaining old ones?
>
> - Gordon
>
> -----Original Message-----
> From: Fréderic Cox [mailto:coxfrederic@gmail.com]
> Sent: Friday, November 16, 2012 2:01 PM
> To: flex-dev@incubator.apache.org
> Subject: Re: Flex 5 in haxe
>
> I understand what you mean here but isn't that always going to be the case. AS4 will go into maintenance mode, then AS5 etc.. What I don't understand is why AS3 is not good enough for a Flex 5 version or even Flex
> 6 which will export to multiple targets. Can you elaborate on that?
>
> Output should be a invisible layer (JS, iOS, Android, SWF, .. Shouldn't matter for the developer). I think most developers like Flex because of the ease-of-use(binding,mxml), rapid development(OOP, components, ..) and multiplatform (mobile, desktop, ..) and I don't see the need for AS4 thereŠ but I'm not export on the subject (just eager to learn more about
> it)
>
> On 16/11/12 22:48, "Gordon Smith" <go...@adobe.com> wrote:
>
>> The continued support is that AS3 and V11 and AIR-for-V11 aren't going
>> away. But I think the idea is that they go into maintenance mode.
>> They're not the technology of the future. Do you want to develop for an
>> old, aging platform?
>


-- 
Jeffry Houser
Technical Entrepreneur
203-379-0773
--
http://www.flextras.com?c=104
UI Flex Components: Tested! Supported! Ready!
--
http://www.theflexshow.com
http://www.jeffryhouser.com
http://www.asktheflexpert.com
--
Part of the DotComIt Brain Trust

Re: Flex 5 in haxe

[Frederic Cox <co...@gmail.com>]

I expect more momentum in the coming months due to developers realizing, or marketeers realizing, what HTML5 in practice means...

Verstuurd vanaf mijn iPhone

Op 16-nov.-2012 om 23:23 heeft Om <bi...@gmail.com> het volgende geschreven:

> On Fri, Nov 16, 2012 at 2:09 PM, Gordon Smith <go...@adobe.com> wrote:
> 
>> I think that developers can continue to build good apps with AS3 and V11,
>> but I'm assuming -- perhaps wrongly -- that the demand for them is going to
>> decrease because companies see that Adobe is no longer investing many
>> resources in them. Hasn't demand already fallen off over the last year? Are
>> developers on this list still able to earn a living building new Flex apps,
>> or are you maintaining old ones?
> 
> Where I work, I am building new Flex apps targetting web and mobile
> platforms.  There are other teams here that are either maintaining or
> building brand new Flex apps.  There was some talk about HTML5/JS till a
> few months after the Adobe announcement, but that was settled very quickly
> because no other technology comes close to Flex in terms of richness,
> maintainability and ease of use.
> 
> Two points to note:
> 1.  More and more teams/developers are getting burnt by the promise of
> HTML5.
> 2.  Flex is still a very powerful brand.  It has taken some beating but is
> still standing strong.
> 
> Lets not conflate the term "mature, tried and tested" with the term "old
> and aging"
> 
> Thanks,
> Om
> 
> 
>> 
>> - Gordon
>> 
>> -----Original Message-----
>> From: Fréderic Cox [mailto:coxfrederic@gmail.com]
>> Sent: Friday, November 16, 2012 2:01 PM
>> To: flex-dev@incubator.apache.org
>> Subject: Re: Flex 5 in haxe
>> 
>> I understand what you mean here but isn't that always going to be the
>> case. AS4 will go into maintenance mode, then AS5 etc.. What I don't
>> understand is why AS3 is not good enough for a Flex 5 version or even Flex
>> 6 which will export to multiple targets. Can you elaborate on that?
>> 
>> Output should be a invisible layer (JS, iOS, Android, SWF, .. Shouldn't
>> matter for the developer). I think most developers like Flex because of the
>> ease-of-use(binding,mxml), rapid development(OOP, components, ..) and
>> multiplatform (mobile, desktop, ..) and I don't see the need for AS4 thereŠ
>> but I'm not export on the subject (just eager to learn more about
>> it)
>> 
>> On 16/11/12 22:48, "Gordon Smith" <go...@adobe.com> wrote:
>> 
>>> The continued support is that AS3 and V11 and AIR-for-V11 aren't going
>>> away. But I think the idea is that they go into maintenance mode.
>>> They're not the technology of the future. Do you want to develop for an
>>> old, aging platform?
>> 
>> 
>> 

RE: Flex 5 in haxe

[Kessler CTR Mark J <ma...@usmc.mil>]

I know I'm late in this thread, but wanted to throw out a few more points.

   Here where I work, we develop new web based flex apps and maintain/update old ones.  They have become key parts of some existing processes.  The reason why Flex/AS was easier to develop for RIA's was its how complete the environment was (yes it does have a few issues).  But more importantly, all the client machines always have the latest flash version installed.  So we never have to worry about going through an arduous process of getting a new application / update through a multi-month test phase which also costs money.  It's leveraging what's already there.

-Mark

-----Original Message-----
From: omuppi1@gmail.com [mailto:omuppi1@gmail.com] On Behalf Of Om
Sent: Friday, November 16, 2012 17:24
To: flex-dev@incubator.apache.org
Subject: Re: Flex 5 in haxe

On Fri, Nov 16, 2012 at 2:09 PM, Gordon Smith <go...@adobe.com> wrote:

> I think that developers can continue to build good apps with AS3 and V11,
> but I'm assuming -- perhaps wrongly -- that the demand for them is going to
> decrease because companies see that Adobe is no longer investing many
> resources in them. Hasn't demand already fallen off over the last year? Are
> developers on this list still able to earn a living building new Flex apps,
> or are you maintaining old ones?
>

Where I work, I am building new Flex apps targetting web and mobile
platforms.  There are other teams here that are either maintaining or
building brand new Flex apps.  There was some talk about HTML5/JS till a
few months after the Adobe announcement, but that was settled very quickly
because no other technology comes close to Flex in terms of richness,
maintainability and ease of use.

Two points to note:
1.  More and more teams/developers are getting burnt by the promise of
HTML5.
2.  Flex is still a very powerful brand.  It has taken some beating but is
still standing strong.

Lets not conflate the term "mature, tried and tested" with the term "old
and aging"

Thanks,
Om


>
> - Gordon
>
> -----Original Message-----
> From: Fréderic Cox [mailto:coxfrederic@gmail.com]
> Sent: Friday, November 16, 2012 2:01 PM
> To: flex-dev@incubator.apache.org
> Subject: Re: Flex 5 in haxe
>
> I understand what you mean here but isn't that always going to be the
> case. AS4 will go into maintenance mode, then AS5 etc.. What I don't
> understand is why AS3 is not good enough for a Flex 5 version or even Flex
> 6 which will export to multiple targets. Can you elaborate on that?
>
> Output should be a invisible layer (JS, iOS, Android, SWF, .. Shouldn't
> matter for the developer). I think most developers like Flex because of the
> ease-of-use(binding,mxml), rapid development(OOP, components, ..) and
> multiplatform (mobile, desktop, ..) and I don't see the need for AS4 thereŠ
> but I'm not export on the subject (just eager to learn more about
> it)
>
> On 16/11/12 22:48, "Gordon Smith" <go...@adobe.com> wrote:
>
> >The continued support is that AS3 and V11 and AIR-for-V11 aren't going
> >away. But I think the idea is that they go into maintenance mode.
> >They're not the technology of the future. Do you want to develop for an
> >old, aging platform?
>
>
>

Re: Flex 5 in haxe

[Om <bi...@gmail.com>]

On Fri, Nov 16, 2012 at 2:09 PM, Gordon Smith <go...@adobe.com> wrote:

> I think that developers can continue to build good apps with AS3 and V11,
> but I'm assuming -- perhaps wrongly -- that the demand for them is going to
> decrease because companies see that Adobe is no longer investing many
> resources in them. Hasn't demand already fallen off over the last year? Are
> developers on this list still able to earn a living building new Flex apps,
> or are you maintaining old ones?
>

Where I work, I am building new Flex apps targetting web and mobile
platforms.  There are other teams here that are either maintaining or
building brand new Flex apps.  There was some talk about HTML5/JS till a
few months after the Adobe announcement, but that was settled very quickly
because no other technology comes close to Flex in terms of richness,
maintainability and ease of use.

Two points to note:
1.  More and more teams/developers are getting burnt by the promise of
HTML5.
2.  Flex is still a very powerful brand.  It has taken some beating but is
still standing strong.

Lets not conflate the term "mature, tried and tested" with the term "old
and aging"

Thanks,
Om


>
> - Gordon
>
> -----Original Message-----
> From: Fréderic Cox [mailto:coxfrederic@gmail.com]
> Sent: Friday, November 16, 2012 2:01 PM
> To: flex-dev@incubator.apache.org
> Subject: Re: Flex 5 in haxe
>
> I understand what you mean here but isn't that always going to be the
> case. AS4 will go into maintenance mode, then AS5 etc.. What I don't
> understand is why AS3 is not good enough for a Flex 5 version or even Flex
> 6 which will export to multiple targets. Can you elaborate on that?
>
> Output should be a invisible layer (JS, iOS, Android, SWF, .. Shouldn't
> matter for the developer). I think most developers like Flex because of the
> ease-of-use(binding,mxml), rapid development(OOP, components, ..) and
> multiplatform (mobile, desktop, ..) and I don't see the need for AS4 thereŠ
> but I'm not export on the subject (just eager to learn more about
> it)
>
> On 16/11/12 22:48, "Gordon Smith" <go...@adobe.com> wrote:
>
> >The continued support is that AS3 and V11 and AIR-for-V11 aren't going
> >away. But I think the idea is that they go into maintenance mode.
> >They're not the technology of the future. Do you want to develop for an
> >old, aging platform?
>
>
>

Re: Flex 5 in haxe

[sébastien Paturel <se...@gmail.com>]

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 <se...@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 <se...@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 <se...@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 <ma...@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.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>

Re: Flex 5 in haxe

[Nils Dupont <ni...@gmail.com>]

"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 <se...@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 <se...@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 <se...@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 <ma...@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.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>
>

Re: Flex 5 in haxe

[sébastien Paturel <se...@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 <se...@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 <se...@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 <ma...@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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>

Re: Flex 5 in haxe

[Carlos Rovira <ca...@codeoscopic.com>]

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 <se...@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 <se...@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 <ma...@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.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>


-- 
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F:  +34 912 35 57 77
http://www.codeoscopic.com
http://www.directwriter.es
http://www.avant2.es

Re: Flex 5 in haxe

[sébastien Paturel <se...@gmail.com>]

Hi,
yes i totally agree.
thats why the haxe way seems better for now. And thats why i still don't 
see any satisfying way to keep flex in AS3 for its long term future.
Justin, you did not answer "what is the essence of flex" for you? :)



Le 17/11/2012 17:41, Justin Mclean a écrit :
> Hi,
>
>> can flex outputed to HTML/JS perform as good as flex outputed to flash runtimes?
> Well as we can't do that yet it's an unknown. However from what I've seen of the Falcon JS compiler the answer is that ActionScript running in flash runtime is much faster. However it's not just a mater of raw performance but more that Flex is optimised to work with the Flash Player (frame frames, elastic racetrack, drawing api, display list etc etc) and that's not how JS engines work.
>
>> Can the next flex (re written) outputed to HTML/JS perform as good as current flex outputed to flash runtimes?
> I doubt it (but see above) and I think it would take a large amount of time and effort to do so. We know a little more when we get our hands on Falcon JS.
>
>> If not, i would conclude that the use of Apache Cordova is not a good solution as a path to get rid of Adobes runtimes dependency.
> If you were making simple mobile app perhaps. I do know of several project that tried Cordova and found that performance wasn't what they required and decided to go native.
>
> Thanks,
> Justin

Re: Flex 5 in haxe

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> can flex outputed to HTML/JS perform as good as flex outputed to flash runtimes?
Well as we can't do that yet it's an unknown. However from what I've seen of the Falcon JS compiler the answer is that ActionScript running in flash runtime is much faster. However it's not just a mater of raw performance but more that Flex is optimised to work with the Flash Player (frame frames, elastic racetrack, drawing api, display list etc etc) and that's not how JS engines work.

> Can the next flex (re written) outputed to HTML/JS perform as good as current flex outputed to flash runtimes?
I doubt it (but see above) and I think it would take a large amount of time and effort to do so. We know a little more when we get our hands on Falcon JS.

> If not, i would conclude that the use of Apache Cordova is not a good solution as a path to get rid of Adobes runtimes dependency.
If you were making simple mobile app perhaps. I do know of several project that tried Cordova and found that performance wasn't what they required and decided to go native.

Thanks,
Justin

Re: Flex 5 in haxe

[sébastien Paturel <se...@gmail.com>]

maybe there was a misunderstanding here justin.
i was talking about HTML5 performances, not Flex.

so my question is:
can flex outputed to HTML/JS perform as good as flex outputed to flash 
runtimes?
maybe i could ask it another way: can the next flex (re written) 
outputed to HTML/JS perform as good as current flex outputed to flash 
runtimes?
If not, i would conclude that the use of Apache Cordova is not a good 
solution as a path to get rid of Adobes runtimes dependency.

Le 17/11/2012 15:54, Justin Mclean a écrit :
> Hi,
>
>> What i read here and there is that the performances are poor.
> Don't believe everything you read. Performance is good for most use cases. Can you write 60 fps full 3d games will millions of polygons on the screen at once in Flex? Probably not but then that's not what it's for. There were some  performance issue on mobile (scrolling big lists for instance) but that was greatly improved in Flex SDK 4.5 and 4.6 releases (and newer versions of AIR).
>
> I really can't see any JS/HTML performing any better in the same situations where Flex has issues.
>
> Thanks,
> Justin

Re: Flex 5 in haxe

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> What i read here and there is that the performances are poor.
Don't believe everything you read. Performance is good for most use cases. Can you write 60 fps full 3d games will millions of polygons on the screen at once in Flex? Probably not but then that's not what it's for. There were some  performance issue on mobile (scrolling big lists for instance) but that was greatly improved in Flex SDK 4.5 and 4.6 releases (and newer versions of AIR).

I really can't see any JS/HTML performing any better in the same situations where Flex has issues.

Thanks,
Justin

Re: Flex 5 in haxe

[sébastien Paturel <se...@gmail.com>]

What i read here and there is that the performances are poor.
if a proof of concept shows that Cordova can make intensive apps runing 
on HTML5, fine. but i just doubt it.

Le 17/11/2012 15:10, Nils Dupont a écrit :
> When you say HTML5 is not ready yet for entreprise RIA, I agree with you
> for desktop applications (it is what I added in nota bene) because of
> current browser fragmentation (there are still companies using IE7...), but
> in the mobile world, browsers are far in advance concerning HTML5/JS. And
> it appears to me that Apache Cordova can generate decent entreprise
> oriented RIA applications, that IMO is the main target of Flex framework
> nowadays. If you want to develop a CPU intensive application and you need
> to use GPU capabilities, it is maybe better to use Starling directly.
> I don't know Haxe, I am sure it is a great technology and it is fore sure a
> way to consider for the future of Apache Flex.
> But it would be also interesting to be able to write a Flex Mobile
> application with almost the same code as today, that can target 7 different
> mobile OS without the help of Air runtime. It could be a strong commercial
> arguments when selling Flex technology to customers (no more HTML5 vs
> Flash, but in contrast the possibilty to use the best of two worlds).
> Nils
>
>
>
> 2012/11/17 sébastien Paturel <se...@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 <se...@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 <ma...@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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>

Re: Flex 5 in haxe

[sébastien Paturel <se...@gmail.com>]

we are not talking about exploying to mobile browsers but about using 
HTML5 engine for native apps like Cordova does.
And again, thats not what the industry is doing TODAY. but tomorrow, we 
can except that the same shift that we observed on Desktop will happen 
on Mobiles, and see the apps going to be webapps.

"you are then better off writing a native HTML/JS UI"
for very simple apps maybe, but for fairly complex ones no.
And if you prefer going native and rewrite everything at any time you 
must target a new platform (even for simple apps), why you like flex in 
the first place?

Le 17/11/2012 15:47, Hordur Thordarson a écrit :
> While I understand the desire to deploy mobile apps to mobile browsers, I would just point out again that this is not what the industry is doing, and there are reasons for that.
>
> The reasons are that in the mobile browser you can't get the same performance, the same UI experience and the same access to native features as you can in a native app.  Also, you can't distribute your app in the same way (correct me if I'm wrong please).
>
> That being said, there are scenarios where it is actually desireable to be able to deploy to the browser, but I think you are then better off writing a native HTML/JS UI with best-of-breed tools for that toolstack, rather than going some cross-compilation roundabout way.
>
> On 17.11.2012, at 14:10, Nils Dupont wrote:
>
>> When you say HTML5 is not ready yet for entreprise RIA, I agree with you
>> for desktop applications (it is what I added in nota bene) because of
>> current browser fragmentation (there are still companies using IE7...), but
>> in the mobile world, browsers are far in advance concerning HTML5/JS. And
>> it appears to me that Apache Cordova can generate decent entreprise
>> oriented RIA applications, that IMO is the main target of Flex framework
>> nowadays. If you want to develop a CPU intensive application and you need
>> to use GPU capabilities, it is maybe better to use Starling directly.
>> I don't know Haxe, I am sure it is a great technology and it is fore sure a
>> way to consider for the future of Apache Flex.
>> But it would be also interesting to be able to write a Flex Mobile
>> application with almost the same code as today, that can target 7 different
>> mobile OS without the help of Air runtime. It could be a strong commercial
>> arguments when selling Flex technology to customers (no more HTML5 vs
>> Flash, but in contrast the possibilty to use the best of two worlds).
>> Nils
>>
>>
>>
>> 2012/11/17 sébastien Paturel <se...@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 <se...@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 <ma...@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.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>

Re: Flex 5 in haxe

[Hordur Thordarson <ho...@lausn.is>]

While I understand the desire to deploy mobile apps to mobile browsers, I would just point out again that this is not what the industry is doing, and there are reasons for that.  

The reasons are that in the mobile browser you can't get the same performance, the same UI experience and the same access to native features as you can in a native app.  Also, you can't distribute your app in the same way (correct me if I'm wrong please).  

That being said, there are scenarios where it is actually desireable to be able to deploy to the browser, but I think you are then better off writing a native HTML/JS UI with best-of-breed tools for that toolstack, rather than going some cross-compilation roundabout way.

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

> When you say HTML5 is not ready yet for entreprise RIA, I agree with you
> for desktop applications (it is what I added in nota bene) because of
> current browser fragmentation (there are still companies using IE7...), but
> in the mobile world, browsers are far in advance concerning HTML5/JS. And
> it appears to me that Apache Cordova can generate decent entreprise
> oriented RIA applications, that IMO is the main target of Flex framework
> nowadays. If you want to develop a CPU intensive application and you need
> to use GPU capabilities, it is maybe better to use Starling directly.
> I don't know Haxe, I am sure it is a great technology and it is fore sure a
> way to consider for the future of Apache Flex.
> But it would be also interesting to be able to write a Flex Mobile
> application with almost the same code as today, that can target 7 different
> mobile OS without the help of Air runtime. It could be a strong commercial
> arguments when selling Flex technology to customers (no more HTML5 vs
> Flash, but in contrast the possibilty to use the best of two worlds).
> Nils
> 
> 
> 
> 2012/11/17 sébastien Paturel <se...@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 <se...@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 <ma...@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.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>> 

Re: Flex 5 in haxe

[Nils Dupont <ni...@gmail.com>]

When you say HTML5 is not ready yet for entreprise RIA, I agree with you
for desktop applications (it is what I added in nota bene) because of
current browser fragmentation (there are still companies using IE7...), but
in the mobile world, browsers are far in advance concerning HTML5/JS. And
it appears to me that Apache Cordova can generate decent entreprise
oriented RIA applications, that IMO is the main target of Flex framework
nowadays. If you want to develop a CPU intensive application and you need
to use GPU capabilities, it is maybe better to use Starling directly.
I don't know Haxe, I am sure it is a great technology and it is fore sure a
way to consider for the future of Apache Flex.
But it would be also interesting to be able to write a Flex Mobile
application with almost the same code as today, that can target 7 different
mobile OS without the help of Air runtime. It could be a strong commercial
arguments when selling Flex technology to customers (no more HTML5 vs
Flash, but in contrast the possibilty to use the best of two worlds).
Nils



2012/11/17 sébastien Paturel <se...@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 <se...@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 <ma...@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.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>

Re: Flex 5 in haxe

[Hordur Thordarson <ho...@lausn.is>]

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.

> 
> Nils
> 
> 
> 
> 2012/11/17 Hordur Thordarson <ho...@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 <se...@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 <ma...@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.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>> 
>> 
>> 

Re: Flex 5 in haxe

[Nils Dupont <ni...@gmail.com>]

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

Nils



2012/11/17 Hordur Thordarson <ho...@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 <se...@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 <ma...@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.
> >>>>>>
> >>>>>>
> >>>>>>
> >
>
>

Re: Flex 5 in haxe

[Hordur Thordarson <ho...@lausn.is>]

Nope, haven't used Catalyst and have only done minor project maintainance in Flash Pro and that is not my thing, working with timelines and such.

Design view isn't gone yet and even if it does go away next year or smth it won't stop working all of a sudden in the then current Flash Builder.
And no, this doesn not affect my reading of their roadmap.  Flex as it is has no place in their roadmap.  But there is lots of other stuff there that has implications as to the future viability of Flex in it's current shape/form.

On 17.11.2012, at 16:49, sébastien Paturel wrote:

> and were you using Catalyst also?
> Knowing that Adobe will drop the design view, and flash catalyst don't make you think much less confident about their roadmap and the place of flex in it?
> 
> 
> Le 17/11/2012 17:44, Hordur Thordarson a écrit :
>> Well, this will always be different for everyone.  I personally don't like IntelliJ, do like FlashBuilder/Eclipse (use Eclipse for all my Java dev as well) and I use the design view in every single Flex app I've written so far and don't see that changing.  For instance, the design view allows me to have inexpensive non-programmers draw the views for apps I'm writing while I write the business logic.  Works like a charm.
>> 
>> On 17.11.2012, at 14:58, John Cunliffe wrote:
>> 
>>> On Sat, Nov 17, 2012 at 3:30 PM, Hordur Thordarson <ho...@lausn.is> wrote:
>>> 
>>>> 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.
>>> 
>>> Haxe can be debugged in IntelliJ, which most developers I know consider
>>> better than FlashBuilder/Eclipse. The design view might be missing, but
>>> I've not seen a single serious project using that. Besides, nobody stops
>>> you from generating AS3 code from 'Flex Haxe' and then debug that just like
>>> you did before. should Flash really be your chosen target platform. Others
>>> however might decide to compile it towards different platforms.
>> 
> 

Re: Flex 5 in haxe

[sébastien Paturel <se...@gmail.com>]

and were you using Catalyst also?
Knowing that Adobe will drop the design view, and flash catalyst don't 
make you think much less confident about their roadmap and the place of 
flex in it?


Le 17/11/2012 17:44, Hordur Thordarson a écrit :
> Well, this will always be different for everyone.  I personally don't like IntelliJ, do like FlashBuilder/Eclipse (use Eclipse for all my Java dev as well) and I use the design view in every single Flex app I've written so far and don't see that changing.  For instance, the design view allows me to have inexpensive non-programmers draw the views for apps I'm writing while I write the business logic.  Works like a charm.
>
> On 17.11.2012, at 14:58, John Cunliffe wrote:
>
>> On Sat, Nov 17, 2012 at 3:30 PM, Hordur Thordarson <ho...@lausn.is> wrote:
>>
>>> 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.
>>
>> Haxe can be debugged in IntelliJ, which most developers I know consider
>> better than FlashBuilder/Eclipse. The design view might be missing, but
>> I've not seen a single serious project using that. Besides, nobody stops
>> you from generating AS3 code from 'Flex Haxe' and then debug that just like
>> you did before. should Flash really be your chosen target platform. Others
>> however might decide to compile it towards different platforms.
>

Re: Flex 5 in haxe

[Hordur Thordarson <ho...@lausn.is>]

Well, this will always be different for everyone.  I personally don't like IntelliJ, do like FlashBuilder/Eclipse (use Eclipse for all my Java dev as well) and I use the design view in every single Flex app I've written so far and don't see that changing.  For instance, the design view allows me to have inexpensive non-programmers draw the views for apps I'm writing while I write the business logic.  Works like a charm.

On 17.11.2012, at 14:58, John Cunliffe wrote:

> On Sat, Nov 17, 2012 at 3:30 PM, Hordur Thordarson <ho...@lausn.is> wrote:
> 
>> 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.
> 
> 
> Haxe can be debugged in IntelliJ, which most developers I know consider
> better than FlashBuilder/Eclipse. The design view might be missing, but
> I've not seen a single serious project using that. Besides, nobody stops
> you from generating AS3 code from 'Flex Haxe' and then debug that just like
> you did before. should Flash really be your chosen target platform. Others
> however might decide to compile it towards different platforms.

Re: Flex 5 in haxe

[John Cunliffe <ma...@gmail.com>]

On Sat, Nov 17, 2012 at 3:30 PM, Hordur Thordarson <ho...@lausn.is> wrote:

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


Haxe can be debugged in IntelliJ, which most developers I know consider
better than FlashBuilder/Eclipse. The design view might be missing, but
I've not seen a single serious project using that. Besides, nobody stops
you from generating AS3 code from 'Flex Haxe' and then debug that just like
you did before. should Flash really be your chosen target platform. Others
however might decide to compile it towards different platforms.

Re: Flex 5 in haxe

[Justin Mclean <ju...@classsoftware.com>]

HI,

> but you don't get it anymore in the next flash builder versions, because of the Adobe's strategy shift.
Incorrect Adobe are Releasing Flash Build 4.8 (currently in beta) [1] and there are other IDEs eg IntelliJ that you can use. Both support Apche Flex.

Thanks,
Justin

1. http://labs.adobe.com/technologies/flashbuilder4-7/

RE: Flex 5

[Mark Fuqua <ma...@availdata.com>]

Well.  ADG.  I can honestly say, the only time I ever used it, was
indirectly, as the Ilog Gantt Chart was based on the Advanced Data Grid.  I
was just aware that there wasn't a Spark version of the ADG and that many
people have mentioned that the MX version was a little buggy.

I think maybe the Spark data grid would be fine...as long as it allows the
expandable tree in the first column.  I am a noob and am actually stuck with
MX only as I cannot afford IBM Ilog Elixir Enterprise (the version that runs
on flex 4...$3200 plus deployment costs as compared to the $800 I paid for
Ilog Elixir, pre IBM that works with the Flex 3 SDK).

It does seem Flex 3 is a good bit simpler than Flex 4 and I am curious, if
you don't mind offering your opinion, how much of the complexity of Flex 4
was simply to chase Adobe's dream of Flash Catalyst and how much was really
a necessary change to make Flex better?  

How different is Flex 4 from Flex 3?  I have done some mobile work in Flex
4.6 and it seems quite similar, but I have read that it is quite different
and I wonder if all I am learning working with Flex 3 and Ilog is wasted or
most will transfer over to Flex 4?

Thanks for all your hard work,

Mark Fuqua

 

-----Original Message-----
From: Carol Frampton [mailto:cframpto@adobe.com] 
Sent: Monday, November 19, 2012 10:19 AM
To: flex-dev@incubator.apache.org
Subject: Re: Flex 5



On 11/17/12 12 :58PM, "Mark Fuqua" <ma...@availdata.com> wrote:

>I love Flex.  And I don't see changing anytime soon.
>
>FWIW, I would be surprised if Adobe and/or others are not hard at work 
>creating the 'Next Flex' that targets JS HTML5 or multiple targets.  It 
>would certainly fit with Edge/Muse/Brackets...maybe Adobe Sencha?
>
>I say this gently, as one who has not submitted any code myself:
>
>In the short run, like the next year or so...Apache Flex 5 maybe, it 
>would be great to have the following worked on/created:
>
>Squiggley
>Additional Spark components

What would you like to see?

>ADG

We had planned to replace this with the Spark DataGrid but as you probably
know not all the features were finished.  Which features in particular would
you like to see implemented?  Locked rows and columns, and sorting multiple
columns was finished and the code is in my whiteboard but haven't been moved
to the sdk yet.

Carol

RE: Flex 5

[Mark Fuqua <ma...@availdata.com>]

Dude...I'm with you.  I bought Ilog the same day they announced the pending
sale.  IBM, if you're not a multi-national, sucks.  Ilog went from a very
expensive $800 to a crazy $3200 + deployment costs.

IBM and enterprise in the same sentence....as in IBM ILOG Elixir
Enterprise...gives me the willies.

Mark

-----Original Message-----
From: christofer.dutz@c-ware.de [mailto:christofer.dutz@c-ware.de] 
Sent: Saturday, November 17, 2012 2:09 PM
To: flex-dev@incubator.apache.org
Subject: AW: Flex 5

Well at least with Apache you're not threatened with a law-suite as thanks
for creating a patch to make ILog work with Flex4 ;-) (Was a few years ago).
Was definitely the last time I payed for anything from big old blue ... and
it's certainly allways my reason I give the guys for declining any offers to
work for them ;-)

Sorry ... just has to mention this ;-)

-----Ursprüngliche Nachricht-----
Von: Mark Fuqua [mailto:mark@availdata.com]
Gesendet: Samstag, 17. November 2012 18:58
An: flex-dev@incubator.apache.org
Betreff: Flex 5 

I love Flex.  And I don't see changing anytime soon.  

FWIW, I would be surprised if Adobe and/or others are not hard at work
creating the 'Next Flex' that targets JS HTML5 or multiple targets.  It
would certainly fit with Edge/Muse/Brackets...maybe Adobe Sencha?

I say this gently, as one who has not submitted any code myself:  

In the short run, like the next year or so...Apache Flex 5 maybe, it would
be great to have the following worked on/created:

Squiggley
Additional Spark components
ADG
Ilog like components (especially a Gantt Chart component)

I would gladly support those with money (I don't have much money, but I have
more money than coding/compiler experience).  I wouldn't even mind if the
above came with a price tag (I paid $800  for Ilog components).

As to the future of Flex, post Flash player, it would seem a more fruitful
discussion, if folks like me (who aren't committing code and therefore,
likely to be of little use on the next step...the big re-write), expressed
their opinions gently, and follow the lead of those likely to do the bulk of
the work (or not).

Mark


-----Original Message-----
From: Hordur Thordarson [mailto:hordur@lausn.is]
Sent: Saturday, November 17, 2012 12:23 PM
To: flex-dev@incubator.apache.org
Subject: Re: Flex 5 in haxe

And they may well do just that, I obviously have no control over that.  I am
just taking at face value what they say their current strategy is and adding
to that my reading of the browser/mobile landscape, the future of browser
plugins, etc, and adding all that up my conclusion is that the current Flex
deployment scenario is viable for many more years.

On 17.11.2012, at 16:30, Jeffry Houser wrote:

> On 11/17/2012 11:20 AM, Hordur Thordarson wrote:
>> 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, many are afraid that Adobe may change their roadmap / goals with 
> very
little warning.
> [Like a few weeks after a big Max Conference]

> 
> --
> Jeffry Houser
> Technical Entrepreneur
> 203-379-0773
> --
> http://www.flextras.com?c=104
> UI Flex Components: Tested! Supported! Ready!
> --
> http://www.theflexshow.com
> http://www.jeffryhouser.com
> http://www.asktheflexpert.com
> --
> Part of the DotComIt Brain Trust
> 

AW: Flex 5

["christofer.dutz@c-ware.de" <ch...@c-ware.de>]

Well at least with Apache you're not threatened with a law-suite as thanks for creating a patch to make ILog work with Flex4 ;-) (Was a few years ago).
Was definitely the last time I payed for anything from big old blue ... and it's certainly allways my reason I give the guys for declining any offers to work for them ;-)

Sorry ... just has to mention this ;-)

-----Ursprüngliche Nachricht-----
Von: Mark Fuqua [mailto:mark@availdata.com] 
Gesendet: Samstag, 17. November 2012 18:58
An: flex-dev@incubator.apache.org
Betreff: Flex 5 

I love Flex.  And I don't see changing anytime soon.  

FWIW, I would be surprised if Adobe and/or others are not hard at work creating the 'Next Flex' that targets JS HTML5 or multiple targets.  It would certainly fit with Edge/Muse/Brackets...maybe Adobe Sencha?

I say this gently, as one who has not submitted any code myself:  

In the short run, like the next year or so...Apache Flex 5 maybe, it would be great to have the following worked on/created:

Squiggley
Additional Spark components
ADG
Ilog like components (especially a Gantt Chart component)

I would gladly support those with money (I don't have much money, but I have more money than coding/compiler experience).  I wouldn't even mind if the above came with a price tag (I paid $800  for Ilog components).

As to the future of Flex, post Flash player, it would seem a more fruitful discussion, if folks like me (who aren't committing code and therefore, likely to be of little use on the next step...the big re-write), expressed their opinions gently, and follow the lead of those likely to do the bulk of the work (or not).

Mark


-----Original Message-----
From: Hordur Thordarson [mailto:hordur@lausn.is]
Sent: Saturday, November 17, 2012 12:23 PM
To: flex-dev@incubator.apache.org
Subject: Re: Flex 5 in haxe

And they may well do just that, I obviously have no control over that.  I am just taking at face value what they say their current strategy is and adding to that my reading of the browser/mobile landscape, the future of browser plugins, etc, and adding all that up my conclusion is that the current Flex deployment scenario is viable for many more years.

On 17.11.2012, at 16:30, Jeffry Houser wrote:

> On 11/17/2012 11:20 AM, Hordur Thordarson wrote:
>> 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, many are afraid that Adobe may change their roadmap / goals with 
> very
little warning.
> [Like a few weeks after a big Max Conference]

> 
> --
> Jeffry Houser
> Technical Entrepreneur
> 203-379-0773
> --
> http://www.flextras.com?c=104
> UI Flex Components: Tested! Supported! Ready!
> --
> http://www.theflexshow.com
> http://www.jeffryhouser.com
> http://www.asktheflexpert.com
> --
> Part of the DotComIt Brain Trust
> 

Re: Flex 5

[Hans | dotdotcommadot <ha...@dotdotcommadot.com>]

Hi Carol,

I've been waiting for these 2 features for a customer of mine.
I was thinking about implementing them myself, but then I heard they were going to be part of the SDK.
Do you have any idea of when we might be able to use them?

Kind regards,
Hans

On 19 Nov 2012, at 16:18, Carol Frampton <cf...@adobe.com> wrote:

> 
> 
> On 11/17/12 12 :58PM, "Mark Fuqua" <ma...@availdata.com> wrote:
> 
>> I love Flex.  And I don't see changing anytime soon.
>> 
>> FWIW, I would be surprised if Adobe and/or others are not hard at work
>> creating the 'Next Flex' that targets JS HTML5 or multiple targets.  It
>> would certainly fit with Edge/Muse/Brackets...maybe Adobe Sencha?
>> 
>> I say this gently, as one who has not submitted any code myself:
>> 
>> In the short run, like the next year or so...Apache Flex 5 maybe, it would
>> be great to have the following worked on/created:
>> 
>> Squiggley
>> Additional Spark components
> 
> What would you like to see?
> 
>> ADG
> 
> We had planned to replace this with the Spark DataGrid but as you probably
> know not all the features were finished.  Which features in particular
> would you like to see implemented?  Locked rows and columns, and sorting
> multiple columns was finished and the code is in my whiteboard but haven't
> been moved to the sdk yet.
> 
> Carol
> 

Re: Flex 5

[Carol Frampton <cf...@adobe.com>]

On 11/17/12 12 :58PM, "Mark Fuqua" <ma...@availdata.com> wrote:

>I love Flex.  And I don't see changing anytime soon.
>
>FWIW, I would be surprised if Adobe and/or others are not hard at work
>creating the 'Next Flex' that targets JS HTML5 or multiple targets.  It
>would certainly fit with Edge/Muse/Brackets...maybe Adobe Sencha?
>
>I say this gently, as one who has not submitted any code myself:
>
>In the short run, like the next year or so...Apache Flex 5 maybe, it would
>be great to have the following worked on/created:
>
>Squiggley
>Additional Spark components

What would you like to see?

>ADG

We had planned to replace this with the Spark DataGrid but as you probably
know not all the features were finished.  Which features in particular
would you like to see implemented?  Locked rows and columns, and sorting
multiple columns was finished and the code is in my whiteboard but haven't
been moved to the sdk yet.

Carol

Flex 5

[Mark Fuqua <ma...@availdata.com>]

I love Flex.  And I don't see changing anytime soon.  

FWIW, I would be surprised if Adobe and/or others are not hard at work
creating the 'Next Flex' that targets JS HTML5 or multiple targets.  It
would certainly fit with Edge/Muse/Brackets...maybe Adobe Sencha?

I say this gently, as one who has not submitted any code myself:  

In the short run, like the next year or so...Apache Flex 5 maybe, it would
be great to have the following worked on/created:

Squiggley
Additional Spark components
ADG
Ilog like components (especially a Gantt Chart component)

I would gladly support those with money (I don't have much money, but I have
more money than coding/compiler experience).  I wouldn't even mind if the
above came with a price tag (I paid $800  for Ilog components).

As to the future of Flex, post Flash player, it would seem a more fruitful
discussion, if folks like me (who aren't committing code and therefore,
likely to be of little use on the next step...the big re-write), expressed
their opinions gently, and follow the lead of those likely to do the bulk of
the work (or not).

Mark


-----Original Message-----
From: Hordur Thordarson [mailto:hordur@lausn.is] 
Sent: Saturday, November 17, 2012 12:23 PM
To: flex-dev@incubator.apache.org
Subject: Re: Flex 5 in haxe

And they may well do just that, I obviously have no control over that.  I am
just taking at face value what they say their current strategy is and adding
to that my reading of the browser/mobile landscape, the future of browser
plugins, etc, and adding all that up my conclusion is that the current Flex
deployment scenario is viable for many more years.

On 17.11.2012, at 16:30, Jeffry Houser wrote:

> On 11/17/2012 11:20 AM, Hordur Thordarson wrote:
>> 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, many are afraid that Adobe may change their roadmap / goals with very
little warning.
> [Like a few weeks after a big Max Conference]

> 
> -- 
> Jeffry Houser
> Technical Entrepreneur
> 203-379-0773
> --
> http://www.flextras.com?c=104
> UI Flex Components: Tested! Supported! Ready!
> --
> http://www.theflexshow.com
> http://www.jeffryhouser.com
> http://www.asktheflexpert.com
> --
> Part of the DotComIt Brain Trust
> 

Re: Flex 5 in haxe

[Hordur Thordarson <ho...@lausn.is>]

I'm not saying the future of Flex shouldn't be planned, it should.  I am however hoping that the current, very funcitional solution isn't just dismissed asap because it might not be future proof.  Most of the stuff we are discussing here isn't much more future proof than the Adobe route with the exception of HTML/JS which will for sure be with us for a long time just because of the industry push behind it.

I know perfectly well we will probably all end up in HTML/JS/CSS land one way or the other, like it or not.  But I also think that it will take years to make a Flex version that works as well in HTML/JS as the current AS3/MXML solution works in Flash player.  And there is also a possibility, however remote you might consider it to be, that a huge effort is spent on porting Flex to HTML/JS and then it becomes clear that because progress in browser land is slow, that HTML/JS just doesn't give us the same quality framework we have today.

But this is all speculation and of course the group here must eventually make a decision one way or the other of how to handle this.

On 17.11.2012, at 17:28, sébastien Paturel wrote:

> Thats dangerous bet...
> and even if " current Flex deployment scenario is viable for many more years" it may be true, but for how long? 5 years? and next? given the big task it is to change this dependency, it has to be prepared right now, and can't wait the end of that ultimatum...
> don't you think?
> 
> Le 17/11/2012 18:23, Hordur Thordarson a écrit :
>> And they may well do just that, I obviously have no control over that.  I am just taking at face value what they say their current strategy is and adding to that my reading of the browser/mobile landscape, the future of browser plugins, etc, and adding all that up my conclusion is that the current Flex deployment scenario is viable for many more years.
>> 
>> On 17.11.2012, at 16:30, Jeffry Houser wrote:
>> 
>>> On 11/17/2012 11:20 AM, Hordur Thordarson wrote:
>>>> 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, many are afraid that Adobe may change their roadmap / goals with very little warning.
>>> [Like a few weeks after a big Max Conference]
>>> -- 
>>> Jeffry Houser
>>> Technical Entrepreneur
>>> 203-379-0773
>>> --
>>> http://www.flextras.com?c=104
>>> UI Flex Components: Tested! Supported! Ready!
>>> --
>>> http://www.theflexshow.com
>>> http://www.jeffryhouser.com
>>> http://www.asktheflexpert.com
>>> --
>>> Part of the DotComIt Brain Trust
>>> 
> 

Re: Flex 5 in haxe

[sébastien Paturel <se...@gmail.com>]

Thats dangerous bet...
and even if " current Flex deployment scenario is viable for many more 
years" it may be true, but for how long? 5 years? and next? given the 
big task it is to change this dependency, it has to be prepared right 
now, and can't wait the end of that ultimatum...
don't you think?

  Le 17/11/2012 18:23, Hordur Thordarson a écrit :
> And they may well do just that, I obviously have no control over that.  I am just taking at face value what they say their current strategy is and adding to that my reading of the browser/mobile landscape, the future of browser plugins, etc, and adding all that up my conclusion is that the current Flex deployment scenario is viable for many more years.
>
> On 17.11.2012, at 16:30, Jeffry Houser wrote:
>
>> On 11/17/2012 11:20 AM, Hordur Thordarson wrote:
>>> 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, many are afraid that Adobe may change their roadmap / goals with very little warning.
>> [Like a few weeks after a big Max Conference]
>> -- 
>> Jeffry Houser
>> Technical Entrepreneur
>> 203-379-0773
>> --
>> http://www.flextras.com?c=104
>> UI Flex Components: Tested! Supported! Ready!
>> --
>> http://www.theflexshow.com
>> http://www.jeffryhouser.com
>> http://www.asktheflexpert.com
>> --
>> Part of the DotComIt Brain Trust
>>

Re: Flex 5 in haxe

[Hordur Thordarson <ho...@lausn.is>]

And they may well do just that, I obviously have no control over that.  I am just taking at face value what they say their current strategy is and adding to that my reading of the browser/mobile landscape, the future of browser plugins, etc, and adding all that up my conclusion is that the current Flex deployment scenario is viable for many more years.

On 17.11.2012, at 16:30, Jeffry Houser wrote:

> On 11/17/2012 11:20 AM, Hordur Thordarson wrote:
>> 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, many are afraid that Adobe may change their roadmap / goals with very little warning.
> [Like a few weeks after a big Max Conference]

> 
> -- 
> Jeffry Houser
> Technical Entrepreneur
> 203-379-0773
> --
> http://www.flextras.com?c=104
> UI Flex Components: Tested! Supported! Ready!
> --
> http://www.theflexshow.com
> http://www.jeffryhouser.com
> http://www.asktheflexpert.com
> --
> Part of the DotComIt Brain Trust
> 

Re: Flex 5 in haxe

[Jeffry Houser <je...@dot-com-it.com>]

On 11/17/2012 11:20 AM, Hordur Thordarson wrote:
> 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, many are afraid that Adobe may change their roadmap / goals with 
very little warning.
  [Like a few weeks after a big Max Conference]

-- 
Jeffry Houser
Technical Entrepreneur
203-379-0773
--
http://www.flextras.com?c=104
UI Flex Components: Tested! Supported! Ready!
--
http://www.theflexshow.com
http://www.jeffryhouser.com
http://www.asktheflexpert.com
--
Part of the DotComIt Brain Trust

Re: Flex 5 in haxe

[Frédéric THOMAS <we...@hotmail.com>]

I'd like to have some doubts on that but I haven't, let's wait for the 
anouncement.

-----Message d'origine----- 
From: Gordon Smith
Sent: Monday, November 19, 2012 1:55 AM
To: flex-dev@incubator.apache.org
Subject: RE: Flex 5 in haxe

My guess is that once V12 makes its debut, V11 feature addition will drop 
off dramatically.

- Gordon

-----Original Message-----
From: sébastien Paturel [mailto:sebpatu.flex@gmail.com]
Sent: Saturday, November 17, 2012 8:58 AM
To: flex-dev@incubator.apache.org
Subject: Re: Flex 5 in haxe

ok sorry for the bad assumption.
thats good news. but how long can we count on AS3 VM updates before any new 
feature will only be for VMNext?


Le 17/11/2012 17:52, Justin Mclean a écrit :
> Hi,
>
>> Adobe's roadmap continue to believe in flash player and AIR. ok. but not 
>> at all for enterprise Apps.
>> first consequence is that any new capability like workers will be only 
>> for the new VM we cant access with AS3 flex.
> Web workers are in Flash Player 11.4 (ie existing AS3 VM) which we can 
> target.
>
> See:
> http://blogs.adobe.com/flashplayer/2012/08/flash-player-11-4-and-air-3-4.html
> http://helpx.adobe.com/flash-player/release-note/fp_114_air_34_release_notes.html
>
> Justin

RE: Flex 5 in haxe

[Gordon Smith <go...@adobe.com>]

My guess is that once V12 makes its debut, V11 feature addition will drop off dramatically.

- Gordon

-----Original Message-----
From: sébastien Paturel [mailto:sebpatu.flex@gmail.com] 
Sent: Saturday, November 17, 2012 8:58 AM
To: flex-dev@incubator.apache.org
Subject: Re: Flex 5 in haxe

ok sorry for the bad assumption.
thats good news. but how long can we count on AS3 VM updates before any new feature will only be for VMNext?


Le 17/11/2012 17:52, Justin Mclean a écrit :
> Hi,
>
>> Adobe's roadmap continue to believe in flash player and AIR. ok. but not at all for enterprise Apps.
>> first consequence is that any new capability like workers will be only for the new VM we cant access with AS3 flex.
> Web workers are in Flash Player 11.4 (ie existing AS3 VM) which we can target.
>
> See:
> http://blogs.adobe.com/flashplayer/2012/08/flash-player-11-4-and-air-3-4.html
> http://helpx.adobe.com/flash-player/release-note/fp_114_air_34_release_notes.html
>
> Justin

Re: Flex 5 in haxe

[Justin Mclean <ju...@classsoftware.com>]

> thats good news. but how long can we count on AS3 VM updates before any
new feature will only be for VMNext?

Only Adobe can answer that. But do we need these yet unannounced features?

I agree it would be nice to decouple Flex framework from the Flash Player
long term, short term I'd rather focus on improving the existing SDK.

Thanks,
Justin

Re: Flex 5 in haxe

[sébastien Paturel <se...@gmail.com>]

ok sorry for the bad assumption.
thats good news. but how long can we count on AS3 VM updates before any 
new feature will only be for VMNext?


Le 17/11/2012 17:52, Justin Mclean a écrit :
> Hi,
>
>> Adobe's roadmap continue to believe in flash player and AIR. ok. but not at all for enterprise Apps.
>> first consequence is that any new capability like workers will be only for the new VM we cant access with AS3 flex.
> Web workers are in Flash Player 11.4 (ie existing AS3 VM) which we can target.
>
> See:
> http://blogs.adobe.com/flashplayer/2012/08/flash-player-11-4-and-air-3-4.html
> http://helpx.adobe.com/flash-player/release-note/fp_114_air_34_release_notes.html
>
> Justin

Re: Flex 5 in haxe

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> Adobe's roadmap continue to believe in flash player and AIR. ok. but not at all for enterprise Apps.
> first consequence is that any new capability like workers will be only for the new VM we cant access with AS3 flex.
Web workers are in Flash Player 11.4 (ie existing AS3 VM) which we can target.

See:
http://blogs.adobe.com/flashplayer/2012/08/flash-player-11-4-and-air-3-4.html
http://helpx.adobe.com/flash-player/release-note/fp_114_air_34_release_notes.html

Justin

Re: Flex 5 in haxe

[Hordur Thordarson <ho...@lausn.is>]

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 Apps.
> 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:
http://blogs.adobe.com/mallika/2012/08/flash-builder-4-7-beta-now-available.html

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

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 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 <se...@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 <ma...@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.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>> 
> 
> 

Re: Flex 5 in haxe

[Nick Tsitlakidis <ni...@perfectedz.com>]

Regarding the guys who wait for Alex to share his thoughts. I dont want to
speak for him but I think that he shared some of his vision in the thread
about FalconJS and the slide presentation. And I think that he stated that
he needs help from the community to create something that makes sense and
complete the vision.

Also about the ones who think that Flex is safe for the next 3-4 years.
That may be true but a complete rewrite or a complete refactoring or
targeting other platforms will take A LOT of time to be completed. Planning
something like this early is critical.


On Sat, Nov 17, 2012 at 8:47 PM, Jeffry Houser <je...@dot-com-it.com>wrote:

> On 11/17/2012 12:31 PM, sébastien Paturel wrote:
>
>> yes unity can output swf now.
>> but they had their own plugin before stage3D.
>> And unity will compete with Adobe on the tooling part which is where
>> Adobe wants to make money.
>>
>
>  I don't believe that is a complete understanding.
>
>  Not all of Adobe's Flash Platform money is coming from tooling. They have
> those premium features ( http://www.adobe.com/devnet/**
> flashplayer/articles/premium-**features.html<http://www.adobe.com/devnet/flashplayer/articles/premium-features.html>) which have a weird licensing model w/ a percentage of revenue.  I assume
> that be the way forward how Adobe makes money; with Tools and the open
> screen project being secondary.
>
>  Previously, I thought the bulk of the money Flash Player made--in the
> past--was via the ads in the installer.  [That stupid toolbar checkbox
> everyone forgets to unclick when installing or updating Flash Player] [I
> don't know numbers, but I've been told it was an obscene amount].  That
> revenue is going away as Flash Player moves to "silent updates".
>
> --
> Jeffry Houser
> Technical Entrepreneur
> 203-379-0773
> --
> http://www.flextras.com?c=104
> UI Flex Components: Tested! Supported! Ready!
> --
> http://www.theflexshow.com
> http://www.jeffryhouser.com
> http://www.asktheflexpert.com
> --
> Part of the DotComIt Brain Trust
>
>


-- 
Nick Tsitlakidis,

CEO and Software Architect at Perfect Edge LTD.
www.perfectedz.com

Re: Flex 5 in haxe

[Jeffry Houser <je...@dot-com-it.com>]

On 11/17/2012 12:31 PM, sébastien Paturel wrote:
> yes unity can output swf now.
> but they had their own plugin before stage3D.
> And unity will compete with Adobe on the tooling part which is where 
> Adobe wants to make money. 

  I don't believe that is a complete understanding.

  Not all of Adobe's Flash Platform money is coming from tooling. They 
have those premium features ( 
http://www.adobe.com/devnet/flashplayer/articles/premium-features.html ) 
which have a weird licensing model w/ a percentage of revenue.  I assume 
that be the way forward how Adobe makes money; with Tools and the open 
screen project being secondary.

  Previously, I thought the bulk of the money Flash Player made--in the 
past--was via the ads in the installer.  [That stupid toolbar checkbox 
everyone forgets to unclick when installing or updating Flash Player] [I 
don't know numbers, but I've been told it was an obscene amount].  That 
revenue is going away as Flash Player moves to "silent updates".

-- 
Jeffry Houser
Technical Entrepreneur
203-379-0773
--
http://www.flextras.com?c=104
UI Flex Components: Tested! Supported! Ready!
--
http://www.theflexshow.com
http://www.jeffryhouser.com
http://www.asktheflexpert.com
--
Part of the DotComIt Brain Trust

Re: Flex 5 in haxe

[sébastien Paturel <se...@gmail.com>]

yes unity can output swf now.
but they had their own plugin before stage3D.
And unity will compete with Adobe on the tooling part which is where 
Adobe wants to make money.

Le 17/11/2012 18:28, Jeffry Houser a écrit :
> On 11/17/2012 11:39 AM, sébastien Paturel wrote:
>> 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)
>
>  And can outputs a SWF....  [which at the moment is ideal for desktop 
> browser usage of Unity games]
>
>
>
>

Re: Flex 5 in haxe

[Jeffry Houser <je...@dot-com-it.com>]

On 11/17/2012 11:39 AM, sébastien Paturel wrote:
> 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)

  And can outputs a SWF....  [which at the moment is ideal for desktop 
browser usage of Unity games]




-- 
Jeffry Houser
Technical Entrepreneur
203-379-0773
--
http://www.flextras.com?c=104
UI Flex Components: Tested! Supported! Ready!
--
http://www.theflexshow.com
http://www.jeffryhouser.com
http://www.asktheflexpert.com
--
Part of the DotComIt Brain Trust

Re: Flex 5 in haxe

[sébastien Paturel <se...@gmail.com>]

Adobe's roadmap continue to believe in flash player and AIR. ok. but not 
at all for enterprise Apps.
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)
if tomorrow a great platform comes out, and is well suited for 
enterprise apps, but not for gaming. flex is screwed for sure.
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.
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).

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)

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?

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 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 <se...@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 <ma...@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.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>

Re: Flex 5 in haxe

[Kevin Newman <Ca...@unFocus.com>]

JavaScript is evolving with ECMAScript harmony 6, it's just incredibly 
slow to standardize on the new stuff, and even slower before you can 
really use most of it in practice.

But there are at least two attempts to build ES6 compilers that work 
today. There's TypeScript (Microsoft), which adds a lot of ES6 
proposals, including classes and the arrow operator, but also adds a lot 
more strictness and static typing (not part of ES6). There's also 
Traceur-compiler (Google?), which I haven't looked at as much, but which 
does similar things without the static type support (I think).

Kevin N.


On 11/17/12 12:53 PM, sébastien Paturel wrote:
> I was hoping that pushed by the developpers, JS could have evolved to 
> an OOP language quite close to what AS3 is today.

Re: Flex 5 in haxe

[sébastien Paturel <se...@gmail.com>]

again thats true only today and still for a little few years from now, 
just because HTML5 is not fully ready yet.
i really don't understand your optimism about flash runtimes, when even 
Adobe made a big shift to HTML5, and narrowed flash runtimes to a 
specific area.

i personnaly was still optimist, until Adobe shifted. Because i believed 
that the flash runtimes were still usefull and better choice against 
HTML5 for several years until JS evolved to something better and HTML5 
gain in performances.
i tought that Adobe could have managed a smooth transition from plugin 
world to HTML5 world by ouputing the previous swf, to the new runtime. 
And the flash platform, meaning tools and frameworks (including flex) 
would be very relevant in an HTML5 world with that output shift. I was 
hoping that pushed by the developpers, JS could have evolved to an OOP 
language quite close to what AS3 is today. (AS3 is by essence a 
proposition of a future of JS)

But Adobe did not chose this smooth path, so now im very pessimistic.


Le 17/11/2012 18:34, Hordur Thordarson a écrit :
> Yeah well Firefox is in a hole re the Flash plugin because they need it for video playback (H264) which btw is driving a lot of web usage these days.
>
> I haven't been following the dev of the Chrome pepper stuff so I can't comment on that.  I do use Flash in Chrome a lot though and haven't had any major problems.  But YMMV as always.
>
> As for the plugin architecture in the browser, it is allready mostly gone from mobile browsers, but I don't think it will dissappear from desktop browsers any time soon because there are still a lot of things the Flash plugin can do that the browsers can't and there is also an enormous amount of software out there that requres the Flash plugin and developers like are still adding more, just look at the activity in Flash based games running in the browser (Zynga, Rovio and a bunch of others are still happily churning out Flash based games).
>
> On 17.11.2012, at 16:34, Omar Gonzalez wrote:
>
>> On Saturday, November 17, 2012, Hordur Thordarson wrote:
>>
>>> 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.
>>>
>>>
>> Bingo!
>>
>> Also, Adobe can say whatever they want about their plans for Flash Player
>> plugins. The truth is Firefox has at one point stated, from one of their
>> VPs, that they would love to just not have a plugin architecture at all and
>> basically tell Flash to go F itself. Microsoft tried that with Metro and
>> they got some backlash so they put it back in 'desktop' mode. Then we have
>> the Chrome pepper API, wow, wht a mess. It gets buggier and buggier with
>> time. What does this all say to me?  Plugin architecture has its days
>> numbered. You can shove your head in the sand and choose to ignore the
>> writing on the wall or you can start to strategize for a life without Flash
>> Player plugin. I choose to be prepared. Whether HTML5 is ready or not and
>> whether its more efficient to develop in or not that is where the industry
>> is heading.
>>
>> -omar

Re: Flex 5 in haxe

[Omar Gonzalez <om...@gmail.com>]

I'm not willing to bet on plugin architecture or that Firefox won't solve
their video encoder issues sometime soon. And I am not willing to ride on
the coat tails o the gaming industry either. Have you seen the hits Zynga
is taking on their stock? Games are a dime a dozen and so are the platforms
to make them. I don't see a viable long term future for the Flash Player
plugin in such a competitive field.

-Omar
On Saturday, November 17, 2012, Hordur Thordarson wrote:

> Yeah well Firefox is in a hole re the Flash plugin because they need it
> for video playback (H264) which btw is driving a lot of web usage these
> days.
>
> I haven't been following the dev of the Chrome pepper stuff so I can't
> comment on that.  I do use Flash in Chrome a lot though and haven't had any
> major problems.  But YMMV as always.
>
> As for the plugin architecture in the browser, it is allready mostly gone
> from mobile browsers, but I don't think it will dissappear from desktop
> browsers any time soon because there are still a lot of things the Flash
> plugin can do that the browsers can't and there is also an enormous amount
> of software out there that requres the Flash plugin and developers like are
> still adding more, just look at the activity in Flash based games running
> in the browser (Zynga, Rovio and a bunch of others are still happily
> churning out Flash based games).
>
> On 17.11.2012, at 16:34, Omar Gonzalez wrote:
>
> > On Saturday, November 17, 2012, Hordur Thordarson wrote:
> >
> >>>
> >> 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.
> >>
> >>
> > Bingo!
> >
> > Also, Adobe can say whatever they want about their plans for Flash Player
> > plugins. The truth is Firefox has at one point stated, from one of their
> > VPs, that they would love to just not have a plugin architecture at all
> and
> > basically tell Flash to go F itself. Microsoft tried that with Metro and
> > they got some backlash so they put it back in 'desktop' mode. Then we
> have
> > the Chrome pepper API, wow, wht a mess. It gets buggier and buggier with
> > time. What does this all say to me?  Plugin architecture has its days
> > numbered. You can shove your head in the sand and choose to ignore the
> > writing on the wall or you can start to strategize for a life without
> Flash
> > Player plugin. I choose to be prepared. Whether HTML5 is ready or not and
> > whether its more efficient to develop in or not that is where the
> industry
> > is heading.
> >
> > -omar
>
>

Re: Flex 5 in haxe

[Hordur Thordarson <ho...@lausn.is>]

Yeah well Firefox is in a hole re the Flash plugin because they need it for video playback (H264) which btw is driving a lot of web usage these days.

I haven't been following the dev of the Chrome pepper stuff so I can't comment on that.  I do use Flash in Chrome a lot though and haven't had any major problems.  But YMMV as always.

As for the plugin architecture in the browser, it is allready mostly gone from mobile browsers, but I don't think it will dissappear from desktop browsers any time soon because there are still a lot of things the Flash plugin can do that the browsers can't and there is also an enormous amount of software out there that requres the Flash plugin and developers like are still adding more, just look at the activity in Flash based games running in the browser (Zynga, Rovio and a bunch of others are still happily churning out Flash based games).

On 17.11.2012, at 16:34, Omar Gonzalez wrote:

> On Saturday, November 17, 2012, Hordur Thordarson wrote:
> 
>>> 
>> 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.
>> 
>> 
> Bingo!
> 
> Also, Adobe can say whatever they want about their plans for Flash Player
> plugins. The truth is Firefox has at one point stated, from one of their
> VPs, that they would love to just not have a plugin architecture at all and
> basically tell Flash to go F itself. Microsoft tried that with Metro and
> they got some backlash so they put it back in 'desktop' mode. Then we have
> the Chrome pepper API, wow, wht a mess. It gets buggier and buggier with
> time. What does this all say to me?  Plugin architecture has its days
> numbered. You can shove your head in the sand and choose to ignore the
> writing on the wall or you can start to strategize for a life without Flash
> Player plugin. I choose to be prepared. Whether HTML5 is ready or not and
> whether its more efficient to develop in or not that is where the industry
> is heading.
> 
> -omar

Re: Flex 5 in haxe

[Omar Gonzalez <om...@gmail.com>]

On Saturday, November 17, 2012, Hordur Thordarson wrote:

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

Also, Adobe can say whatever they want about their plans for Flash Player
plugins. The truth is Firefox has at one point stated, from one of their
VPs, that they would love to just not have a plugin architecture at all and
basically tell Flash to go F itself. Microsoft tried that with Metro and
they got some backlash so they put it back in 'desktop' mode. Then we have
the Chrome pepper API, wow, wht a mess. It gets buggier and buggier with
time. What does this all say to me?  Plugin architecture has its days
numbered. You can shove your head in the sand and choose to ignore the
writing on the wall or you can start to strategize for a life without Flash
Player plugin. I choose to be prepared. Whether HTML5 is ready or not and
whether its more efficient to develop in or not that is where the industry
is heading.

-omar

Re: Flex 5 in haxe

[Hordur Thordarson <ho...@lausn.is>]

> 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 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 <se...@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 <ma...@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.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
> 
> 

Re: Flex 5 in haxe

[sébastien Paturel <se...@gmail.com>]

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 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 <se...@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 <ma...@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.
>>>>>>>
>>>>>>>
>>>>>>>

Re: Flex 5 in haxe

[Hordur Thordarson <ho...@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 <se...@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 <ma...@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.
>>>>>> 
>>>>>> 
>>>>>> 
> 

Re: Flex 5 in haxe

[sébastien Paturel <se...@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 <se...@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 <ma...@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.
>>>>>
>>>>>
>>>>>

Re: Flex 5 in haxe

[Nils Dupont <ni...@gmail.com>]

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 <se...@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 <ma...@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.
>>>>
>>>>
>>>>
>

Re: Flex 5 in haxe

[sébastien Paturel <se...@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 <ma...@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.
>>>
>>>

Re: Flex 5 in haxe

[Alex Harui <ah...@adobe.com>]

On 11/17/12 5:14 AM, "Nils Dupont" <ni...@gmail.com> wrote:

> Has anyone tried to make a bridge between Apache Flex and Apache Cordova?
I'm currently trying to see how well FalconJS output works with Cordova.

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

Re: Flex 5 in haxe

[Nils Dupont <ni...@gmail.com>]

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

Re: Flex 5 in haxe

[Maxime Cowez <ma...@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 <pa...@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.
>
>

Re: Flex 5 in haxe

[Paul Hastings <pa...@gmail.com>]

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

Re: Flex 5 in haxe

[Omar Gonzalez <om...@gmail.com>]

For those wondering about the state of the haxe community and level of
support; the haxe foundation has just gone live:
http://haxe-foundation.org/

-omar

Re: Flex 5 in haxe

[Frank Pepermans <fr...@hotmail.com>]

Still working on a huge desktop Flex app for a client for their worldwide 
subdivisions,
and getting a LOT of negative feedback, not because it is slow or bug ridden 
(plain users like it actually), but simply because the IT departments know 
it is using AIR, and the word got out about Flash...
Not a week goes by without having to answer for why it is using Flash based 
technology, which is demotivating honestly.

Aside from that, no new calls for anything Flex related.

Would love to keep doing Flex myself, but will probably have to switch to a 
different development environment after this project,
hopefully it will someday be Flex again however.


-----Original Message----- 
From: Justin Mclean
Sent: Saturday, November 17, 2012 8:35 AM
To: flex-dev@incubator.apache.org
Subject: Re: Flex 5 in haxe

Hii Gorgon,

> Are developers on this list still able to earn a living building new Flex 
> apps, or are you maintaining old ones?
Yes. Doing a bit of both.

Justin 

Re: Flex 5 in haxe

[Justin Mclean <ju...@classsoftware.com>]

Hii Gorgon,

> Are developers on this list still able to earn a living building new Flex apps, or are you maintaining old ones?
Yes. Doing a bit of both.

Justin

RE: Flex 5 in haxe

[Gordon Smith <go...@adobe.com>]

I think that developers can continue to build good apps with AS3 and V11, but I'm assuming -- perhaps wrongly -- that the demand for them is going to decrease because companies see that Adobe is no longer investing many resources in them. Hasn't demand already fallen off over the last year? Are developers on this list still able to earn a living building new Flex apps, or are you maintaining old ones?

- Gordon

-----Original Message-----
From: Fréderic Cox [mailto:coxfrederic@gmail.com] 
Sent: Friday, November 16, 2012 2:01 PM
To: flex-dev@incubator.apache.org
Subject: Re: Flex 5 in haxe

I understand what you mean here but isn't that always going to be the case. AS4 will go into maintenance mode, then AS5 etc.. What I don't understand is why AS3 is not good enough for a Flex 5 version or even Flex
6 which will export to multiple targets. Can you elaborate on that?

Output should be a invisible layer (JS, iOS, Android, SWF, .. Shouldn't matter for the developer). I think most developers like Flex because of the ease-of-use(binding,mxml), rapid development(OOP, components, ..) and multiplatform (mobile, desktop, ..) and I don't see the need for AS4 thereŠ but I'm not export on the subject (just eager to learn more about
it)

On 16/11/12 22:48, "Gordon Smith" <go...@adobe.com> wrote:

>The continued support is that AS3 and V11 and AIR-for-V11 aren't going 
>away. But I think the idea is that they go into maintenance mode. 
>They're not the technology of the future. Do you want to develop for an 
>old, aging platform?

Re: Flex 5 in haxe

[Fréderic Cox <co...@gmail.com>]

I understand what you mean here but isn't that always going to be the
case. AS4 will go into maintenance mode, then AS5 etc.. What I don't
understand is why AS3 is not good enough for a Flex 5 version or even Flex
6 which will export to multiple targets. Can you elaborate on that?

Output should be a invisible layer (JS, iOS, Android, SWF, .. Shouldn't
matter for the developer). I think most developers like Flex because of
the ease-of-use(binding,mxml), rapid development(OOP, components, ..) and
multiplatform (mobile, desktop, ..) and I don't see the need for AS4
thereŠ but I'm not export on the subject (just eager to learn more about
it)

On 16/11/12 22:48, "Gordon Smith" <go...@adobe.com> wrote:

>The continued support is that AS3 and V11 and AIR-for-V11 aren't going
>away. But I think the idea is that they go into maintenance mode. They're
>not the technology of the future. Do you want to develop for an old,
>aging platform?

RE: Flex 5 in haxe

[Gordon Smith <go...@adobe.com>]

> We need the Flash Player and AIR. Adobe needs to continue to support us.

The continued support is that AS3 and V11 and AIR-for-V11 aren't going away. But I think the idea is that they go into maintenance mode. They're not the technology of the future. Do you want to develop for an old, aging platform?

> Adobe cannot starve it's children anymore. This needs to change.

Adobe changed its strategic focus with regards to RIAs and Flex more than a year ago. (They probably weren't a sufficiently high-growth market to justify significant continued investment.) I don't believe that the Flex community can count on either being a focus again for Adobe in the future. Reality is difficult, but it's real.

> I think more effort should be put in to talking to Adobe about exactly what is going on.

What exactly do you want to know that hasn't been explained numerous times over the last year?

- Gordon


-----Original Message-----
From: jude [mailto:flexcapacitor@gmail.com] 
Sent: Friday, November 16, 2012 1:25 PM
To: flex-dev@incubator.apache.org
Subject: Re: Flex 5 in haxe

+1 to Nick's comments. Alex has stated that Adobe is looking at how the
Flex community responds to Apache Flex.

We need the Flash Player and AIR. Adobe needs to continue to support us.
Adobe cannot starve it's children anymore. This needs to change.

Flex is the greatest framework / toolchain I've ever used. It's not perfect but it was / is the best out there IMHO. Adobe needs to realize they have the best solution for targeting multiple platform out there and not to throw it all away. We can't go to JS. It's slow compared to Flash.

I attended a presentation on Starling and I think there is a future there.
Instead of writing to flash.display.DisplayObject you write to starling.display.DisplayObject. It is about 1000x faster. All GPU. I think we'd lose built in accessibility but you can still use the flash.display.* display list and text. We can look into providing an alternative to that.
Abstracting out the drawing engine would allow us to drop in different targets.

Bruce has mentioned writing an open source FP. That would free us from being tied to any one VM but I would imagine it's gotta be a lot of work.
Maybe having the compiler generating different output for other VM targets would be better. Maybe add Unity or Silverlight targets.

Adobe is investing heavily in Gaming. So we can rely on that target for the near future. In the meantime don't throw out the 6 yrs of work by excellent Flex engineers. I think it is way too soon to talk about a rewrite.

I think more effort should be put in to talking to Adobe about exactly what is going on.

On Fri, Nov 16, 2012 at 2:58 PM, Gordon Smith <go...@adobe.com> wrote:

> > From what I previously read, I don't think we were getting an 
> > updated
> Falcon compiler that will generate AVM3 code.
> > They were not planning on open-sourcing that (but correct me if I'm
> wrong in that aspect).
>
> That's correct. Adobe has no plans to open-source its new AS4-for-V12 
> compiler.
>
> - Gordon
>
> -----Original Message-----
> From: Nicholas Kwiatkowski [mailto:nicholas@spoon.as]
> Sent: Friday, November 16, 2012 12:27 PM
> To: flex-dev@incubator.apache.org
> Subject: Re: Flex 5 in haxe
>
> On Fri, Nov 16, 2012 at 3:08 PM, Stefan Horochovec < 
> stefan.horochovec@gmail.com> wrote:
>
> [snip]
>
>
> > The development of the new VM and AS4 specification is not reported 
> > or discussed with Apache Flex, knowing that we depend exclusively of 
> > Flash Player and AIR to execute applications. This in my opinion is
> terrible.
> >
> > Again we will have to wait for an update from Falcon to generate 
> > code for the V12, this delay the progress of the Flex when we are 
> > expecting more and more code from Adobe.
> >
> > I'm not saying that we should use haxe, or some other compiler, just 
> > think the time is an even broader discussion. The Flex should 
> > continue only with Flash Player / Adobe AIR runtime?
> >
>
> This is, and has been par for the course.  When Adobe doesn't want to hear
> us whine and moan, they close off development.   It happened before (and in
> many more products than just Flex/Flash), and I'm sure it will happen 
> often in the future.  They feel they can surround themselves with 
> "stakeholders"
> (a small, select subset of customers that their marketing team found them)
> to make major changes to platforms, products, etc.   At least this time,
> they were pretty clear in saying we wouldn't have a seat in the table 
> for the future.  Previous times they gave us the illusion that we did.
>
> From what I previously read, I don't think we were getting an updated 
> Falcon compiler that will generate AVM3 code.  They were not planning 
> on open-sourcing that (but correct me if I'm wrong in that aspect).
>
> I'm pretty sure the community as a whole over the last 11 months have 
> determined to break our dependency of the Flash Player.  We've had a 
> LOT of proposals on how to do it -- none of them executed yet.  The 
> silliest of the bunch in my opinion is porting to HaXe or starting 
> from scratch.  Our power is leveraged from Adobe's initial 200,000 
> hours of labor over the last many years.  We got an awesome code-base 
> that while, it needs some major tweaks, is is really good shape.  
> Dumping out the baby with the bath-water is not the way to go on a platform that is mature and used by
> MANY large enterprises.   That being said -- this is now in the Apache
> world and I can't stop anybody from doing that, but I won't also be 
> helping redo Flex from scratch.
>
> -Nick
>

Re: Flex 5 in haxe

[Alex Harui <ah...@adobe.com>]

On 11/16/12 6:23 PM, "jude" <fl...@gmail.com> wrote:

> That is my point in staying with what we have. The Flex SDK has had some
> constraints on it that made it what it is today. I'm not against starting a
> new or full rewrite but I would say let's get this project going on the
> current code base first. Let's make it easy for long term contributors to
> contribute and soon after support drive by contributors. When the dust has
> settled then we create a branch or two to test performance improvements
> out.
I have tried my best to get our committers to commit code on the current
code base, but so far, I have not seen nearly as much activity as I would
have expected or hoped, and the reasons I hear have to do with being too
busy just trying to survive and the interwoven nature of the code making it
scary to start making changes, even with mustella as a validation suite.

> What we don't know right now (maybe you do) is where the bottlenecks
> are in general (code or rendering) and more importantly where the
> bottlenecks are in our applications and then how and where to optimize. I
> wish there was a performance monitoring tool that would show us that
> information but none exist.
I have yet to see rendering be an issue on the desktop.  I have heard it is
an issue on mobile devices, but haven't profiled any myself, but basically,
if you are running a lot of unneeded code, you are putting even more
pressure on the renderer to be fast.
> 

> It'd be 1000x better for
> developers if Adobe would say Flex can run fine on Flash going into the
> next ten years instead of saying Flash is for gaming.
Where and how should Adobe present this message?  I'm not promising that
they will, but I want to understand who it is targeted to.

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

Re: Flex 5 in haxe

[jude <fl...@gmail.com>]

On Fri, Nov 16, 2012 at 4:13 PM, Alex Harui <ah...@adobe.com> wrote:

> Keep in mind that I'm the biggest proponent of the full re-write.  We may
> still find a few performance mistakes in the current code (like the Chart
> styles init that just got fixed), but really, some very smart people have
> spent a lot of time on the current code and haven't found any easy wins.
>

That is my point in staying with what we have. The Flex SDK has had some
constraints on it that made it what it is today. I'm not against starting a
new or full rewrite but I would say let's get this project going on the
current code base first. Let's make it easy for long term contributors to
contribute and soon after support drive by contributors. When the dust has
settled then we create a branch or two to test performance improvements
out.


> IMO, the framework is slow because lots of code is running just in case.
>

I wouldn't say it's slow. Maybe on phones in 2010 and on Flex 4 but not in
2013 on Flex 4.6+. There was a lot of optimization done in 4.6 and all the
great things in it were overshadowed by November. I'd say it's not finished
and that developers are still learning it. It's 2 years old. People are
just now migrating to Flex 4.5.  There are videos online on increasing Flex
4 performance for mobile and they went from default 12 and 15 FPS to 45 FPS
by making a few changes. Those same tests are steady at 60 FPS+ on Spark
Lists in newer versions of AIR.

I'd agree the framework is covering it's bases all the time. Which it
should do. But it should also allow developers developers to disable
certain layout code in certain situations and especially when the developer
knows what they're doing.

The thing with Flex is it's flexible enough that you can give it too much
to do. What we don't know right now (maybe you do) is where the bottlenecks
are in general (code or rendering) and more importantly where the
bottlenecks are in our applications and then how and where to optimize. I
wish there was a performance monitoring tool that would show us that
information but none exist.

You also have to remember that technology marches on. So think about 2
years from when phones are 4x as fast. Also, even the latest phones still
stutter and are slow at times in their own native environments (go to the
search screen in any Android or iOS device).

This is especially true for mobile apps where you have the most constrained
> runtime environment.  The issue that came in today on the users list about
> slow List performance I'm sure is in part due to TextLine being a bit
> slower, but probably more due to lots of other code running as well.
>

AIR 3.4 and 3.5 had major mobile performance improvements.


> Plus, as many have recently said, the intertwined code we currently have
> makes it hard for the volunteer to be successful in their spare time.
>

There are long time volunteers here too.

There are no alternatives for Flash at this time. HTML5 doesn't even come
close. It's missing so many features across the board (or I should say the
browsers are).

@Gordon - I'd say there's a lot of momentum and interest in mobile software
(software includes apps and that includes apps that are entertaining and
sometimes they have scores and support two or more users at once). Software
is huge... anything that makes Software is of interest. Enter Flex (or
mention it). Or describe it. Flex has had major development investment in
it all the way up to Nov last year. Few other companies put in the
resources this company did. The goal was to make the best platform for
deploying to multiple targets going into 2012. Flex 4.6 is relatively new
and fast and unknown. It's still the best choice for many developers and
companies for creating mobile, desktop and web applications. IF THEY KNOW
OF IT. It can be very successful in that market. It'd be 1000x better for
developers if Adobe would say Flex can run fine on Flash going into the
next ten years instead of saying Flash is for gaming. If someone wants to
do gaming, we the developers, will be the first to tell them Flash is ready
for them.

Jude

Re: Flex 5 in haxe

[Alain Ekambi <ja...@gmail.com>]

@Hordur

"Since I use JavaEE for the backend for my apps, this would be a killer
scenario for me"

This is exactly why we create Flash4j.
For beeing able to write our Flex apps in ONE language(Java)  instead of
 ActionScriot/MXML/JS/CSS/HTML/Java.




2012/11/21 Carlos Rovira <ca...@codeoscopic.com>

> JavaFx looks pretty good. For people like us it'll solve much of the
> problems since the platform gives you out-of-the-box, I'm referring to
> maven driven projects, AOP, Annotations on steroids, and so on...JavaFX 2
> revisions look so good and seems they copy lots of things from the Flex
> world (@FXSkin seems to be like [SkinPart] ;) )...but as you say the
> problem seems to be as always with java client technologies, with the
> deployment model. If they plan to target runtimes like Haxe did, it could
> be very cool, but right now I only see problems in the last node of its
> chain...
>
>
>
> 2012/11/21 Hordur Thordarson <ho...@lausn.is>
>
> > Exactly.  And talking about reality, reality is also that HTML will never
> > be everything to everybody, a one-size-fits-all solution, simply because
> > there are no such solutions, requirements are very different depending on
> > what you are building.  For myself, I'll check out JavaFX before being
> > stuck with deploying to HTML/JS.  If the JavaFX crowd gets it's
> deployment
> > experience sorted (it is currently very poor compared fex to AIR) and
> they
> > find a way of building captive-runtime apps for mobile (both problems are
> > being worked on btw), then they have a pretty cool platform on their
> hands
> > where you can write your frontend and backend in Java (like the JS crowd
> is
> > trying with Node.js).  Since I use JavaEE for the backend for my apps,
> this
> > would be a killer scenario for me.
> >
> > On 21.11.2012, at 11:08, Carlos Rovira wrote:
> >
> > >> HTML5 is not mature enough to compete with flash player right now, but
> > we
> > >> have to think about future, and it will improve quite quick with all
> the
> > >> hype around it.
> > >> And even if you prefer flash player, there is our dreams, and there is
> > >> reallity. And reallity is that Adobe is pushing HTML5 for web and
> > giving up
> > >> flash player for that. And we have to be prepared to a time where
> there
> > >> will not be flash player only HTML5 everywhere. (in several years
> maybe,
> > >> but will happen unless something drastically change)
> > >
> > > The problem with this HTML5 trend is that HTML5 does not fit all
> > > necessities. Big desktop/browser applications are a pain to develop and
> > > maintain in HTML5. I understand how facebook people suffer ;). So
> Apple,
> > > Adobe and others are pushing tools to solve little solutions, but not
> > > enterprise solutions, since they didn't get any money (since they never
> > > understand/improve their business model to target the enterprise world)
> > >
> > > I'd like to target HTML5/JS but to solve the problem of deploy for
> mobile
> > > browsers (or even desktop browsers if I need...) some solutions that
> use
> > to
> > > be not as huge as the ones we develop (ERPs and other big monsters only
> > > desktop apps...) and make all of this using the same development
> paradigm
> > > (IDEs, language, OOP,...)
> >
> >
>
>
> --
> Carlos Rovira
> Director de Tecnología
> M: +34 607 22 60 05
> F:  +34 912 35 57 77
> http://www.codeoscopic.com
> http://www.directwriter.es
> http://www.avant2.es
>

Re: Flex 5 in haxe

[Harbs <ha...@gmail.com>]

I'm probably not the standard Flex developer and my focus is very narrow at the moment.

I agree with most of what's been said, but I have not seen my biggest concern for the future addressed: TLF.

The lion share of my time is taken up right now by my w2p startup printui.com. Reliable rendering of text is critical to the application -- not just across browsers, but everything must match the rendering in InDesign which we use for both initial document creation and output rendering. For us TLF and FTE was a godsend, because we had:
a) reliable rendering across browsers
b) quality reproduction of advance typesetting including many OpenType features
c) Built in support for international languages
d) Rendering that was very close to InDesign's native text rendering that only required minor tweaks to get a 100% match.
e) a framework (TLF) that allowed for easy translation between InDesign markup and our web app

Right now, non-desktop support is not a major concern for us, and smart phones is not a concern at all because I really don't see editing documents on a smartphone. However, tablet support is something that keeps coming up and we've had countless discussions on which way to go. None of the options are really appealing. I'm leaning towards a port to AIR, but my two big concerns are performance and long term ubiquity. As Alex said, who knows how many devices Adobe can support before they just throw in the towel. I plan on doing some performance profiling to see if I can get the app performant enough for tablets. I'm not sure because there's a lot of TLF there…

If there was a good way to go to HTML, I'd definitely like to explore that avenue, but consistent rendering of text on browsers without Flash just doesn't seem to exist. I've seen some experiments of writing a composer in JS, but not much more than simple experiments. I'm really struggling with how to handle the text rendering on tablets, and if anyone has something useful, I'd love to hear!

Harbs

On Nov 21, 2012, at 8:22 PM, Alex Harui wrote:

> 
> 
> 
> On 11/21/12 8:53 AM, "Kevin Newman" <Ca...@unFocus.com> wrote:
> 
>> From what I see, the HTML5 everything push is ending - mostly because
>> of performance issues on the native app side.
> Here's my take: sometimes when you buy into the hype to early and the
> technology isn't ready, you get burned, and then there is a move away.  But
> if you don't keep watching you may miss when it does become ready.  I don't
> know HTML5, but for sure, there is a lot of smart people working on it.  It
> may not be ready today, or even 3 years from now, but will get faster as the
> hardware gets faster, and folks will eventually settle on Dart or some other
> OO language to migrate to from JS.  Could be 10 years from now, but I'm
> pretty sure it will happen.
> 
> Meanwhile, all of you on this list are in different circumstances, but I can
> think of a three buckets: 1) You are employed by an enterprise that is going
> to need desktops with keyboards for quite some time (although watch out for
> keyboards to go away as natural language input gets better).  The
> availability of fast networks and the lower maintenance of zero-install,
> browser-delivered apps is attractive, and you can control whether Flash is
> used or not.
> 2) You are an independent consultant that builds apps for companies.  You
> can't control whether Flash is used or not.
> 3) You are building an app that just plain needs Flash (maybe premium video)
> or requires a lot of input so you can assume folks will have keyboards.
> 
> Flash on a desktop with a keyboard will be around for a very long time.
> There are too many desktops with keyboards in companies who will complain
> loudly if any of the companies involved (OS, browser, Adobe) screws that up.
> 
> But some projections say that laptop sales in the home/consumer market is
> doomed by tablets just like pocket cameras were doomed by smartphones.  If
> your target customer is not a business worker with a need for a keyboard,
> you can assume they will soon be using a device that doesn't run Flash in
> the browser.  And, what isn't clear is how well AIR will run on that device,
> if at all.  There are so many devices it will be hard for AIR to keep
> running well (in captive runtime of course) on all of them.
> 
> This is why, even though Flash will be running in browsers on desktops with
> keyboards "forever", more and more of the folks most of you are targeting
> won't be using a browser/keyboard combination that is Flash capable.
> 
> And, eventually, the network speeds and prices and device speeds will reach
> the point where zero-install browser-delivered apps on those devices become
> the predominant paradigm again.
> 
> For sure, there are plenty of reasons to keep maintaining the current code
> base, and I will invest time there.  But I see it as my mandate to try to
> shape a next generation of Flex that is designed to be ported to other
> platforms.  By going to JS, we get the most coverage for the least amount of
> work, but we have to give up fidelity and performance.  Over time, with
> enough resources, we may be able to target other platforms natively, but
> that will take a lot of time and effort.
> 
> I am starting a re-write that prioritizes different things than the current
> code base.  It won't use things that are hard to port like weak references
> and Dictionary so you may have to do more work managing memory.  It will
> have other deficiencies and trade-offs and will never match exactly what you
> have today.  But it should still feel a lot like current Flex.  By starting
> now and trying to get to critical mass over the next year or two, the goal
> is to have a softer landing for those who have a lot invested in AS3 and the
> current code.
> 
> Those of you who are Haxe fans should definitely start your own rewrite.  We
> can't just keep talking about it in email.  We won't know how it will truly
> be to move to Haxe until there is something to actually play with.  We don't
> have to decide as a community which language to use for a re-write without
> actually trying a couple of different angles.  For me, I will stay on AS3
> unless I get strong signals that there is no value to any of our current
> Flex developers by staying on it.
> 
> -- 
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
> 

Re: Flex 5 in haxe

[Kevin Newman <Ca...@unFocus.com>]

For that matter, Adobe Flash is not Apache either.

Just to add one more bullet point - existing AS3 code bases can still be 
used if Flex is done in Haxe, as long as you target AVM2.

Kevin N.


On 11/21/12 4:59 PM, Carlos Rovira wrote:
> Your point of "Haxe is not in Apache" is not a point for me.

Re: Flex 5 in haxe

[Carlos Rovira <ca...@codeoscopic.com>]

This has lots of sense. In fact talking with Nicolas Canesse, he point me
to that solution when talking about the main haxe problem that I see:
There's nothing like MXML in haxe.

2012/11/22 Alex Harui <ah...@adobe.com>

>
> I hope to eliminate virtually all MXML codegen in Falcon.  There is no
> reason for MXML to result in generated code, in fact, quite the opposite,
> there are many advantages to having MXML generate data structures of simple
> values, and allow the app framework to interpret it at runtime, especially
> if the compiler has done its work so the interpreter doesn't need as much
> error checking.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>


-- 
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F:  +34 912 35 57 77
http://www.codeoscopic.com
http://www.directwriter.es
http://www.avant2.es

Re: Flex 5 in haxe

[Alex Harui <ah...@adobe.com>]

On 11/21/12 4:45 PM, "sébastien Paturel" <se...@gmail.com> wrote:

> I'd like to be wrong, but i have serious doubts about the Cordova web
> view rendering performances
I will pass that on to the Cordova team.
> 
> "multiple targets wouldn't have extra overhead in its abstractions"
> of course, but flex apps can have heavy UI work
> 
> "I'm not planning on transcompilation of MXML"
> How you plan to use MXML?
I hope to eliminate virtually all MXML codegen in Falcon.  There is no
reason for MXML to result in generated code, in fact, quite the opposite,
there are many advantages to having MXML generate data structures of simple
values, and allow the app framework to interpret it at runtime, especially
if the compiler has done its work so the interpreter doesn't need as much
error checking.

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

Re: Flex 5 in haxe

[sébastien Paturel <se...@gmail.com>]

I'd like to be wrong, but i have serious doubts about the Cordova web 
view rendering performances

"multiple targets wouldn't have extra overhead in its abstractions"
of course, but flex apps can have heavy UI work

"I'm not planning on transcompilation of MXML"
How you plan to use MXML?


  Le 22/11/2012 01:18, Alex Harui a écrit :
>
>
> On 11/21/12 3:49 PM, "sébastien Paturel" <se...@gmail.com> wrote:
>
>> If you consider Cordova only as short term answer, for POC achievement,
>> thats ok for me.
> Cordova will be around long-term if it proves viable for enough people.
>> But its not viable as a final solution, because it would be giving up on
>> great performances for native apps compared to native code usage directly.
> It isn't guaranteed that any solution we do that has multiple targets
> wouldn't have extra overhead in its abstractions.
>> We have to find out how much work it really is to create something like
>> FalconJava. If its not much time of work, its ok, if not, its a big
>> weakness against Haxe which has already a great background and decent
>> community around it!!
>> But moreover, you'r talking about FalconJS, FalconJava etc but if i
>> understand your strategy it will be needed only for Logic code right?
>> But the big performances killer on mobile is more on the UI side if i'm
>> not wrong. especially when you compare HTML5/JS with Flash.
>> And targetting a new device, does not mean only to get FalconNewLanguage
>> but also the MXML transcompilation to the new native UI runtime. And i
>> believe that its the biggest amount of work for each new target.
> I'm not planning on transcompilation of MXML.
>> If AS3/Cordova POC and Haxe POC are two satisfying results.
>> What do you thing of keeping both?
> We can certainly keep both.
>> As we are starting from scratch, its not so hard to keep synch of two
>> code base with two different languages (but very similar. using
>> automatic tools to do at least half of the translation).
>> With such a dual solution, we can use the best of the two solutions for
>> our needs.
>>
>> I still don't understand why you say that if we don't use AS3, current
>> flex users would have wider choice.
> Because if I offer a solution that doesn't require porting your existing
> code you might be willing to accept other tradeoffs.  But if you have to
> port, you will then look at all frameworks.
>> We are all pushing flex future, especially because there is no mature
>> alternative that can really compete with flex.
>>
>

RE: Flex 5 in haxe

[Mark Fuqua <ma...@availdata.com>]

Kevin,

I am not sure that's true...personally (and I would place myself in the
minority), I won't look at other languages/platforms if Flex goes the
direction I want to go (pretty much right where it is now, only future
proof).  I like actionScript and I like Flex.  I am on my way to being
proficient. I am not eager to jump ship. 

I watched Mike Labriola's 360Min presentation on how he is developing apps
for HTML.  Even something like that, using ActionScript instead of C# would
be better than a complete switch for me.  

It is similar to the same risk Microsoft took with Windows 8...if I have to
learn a new OS, maybe I should just take the plunge and get an Apple.

Mark

-----Original Message-----
From: Kevin Newman [mailto:CaptainN@unFocus.com] 
Sent: Thursday, November 22, 2012 2:46 PM
To: flex-dev@incubator.apache.org
Subject: Re: Flex 5 in haxe

To be blunt, if Flex doesn't measure up against those other frameworks, it
has no future - regardless of the language it's built on.

Kevin N.


On 11/21/2012 7:18 PM, Alex Harui wrote:
> Because if I offer a solution that doesn't require porting your 
> existing code you might be willing to accept other tradeoffs.  But if 
> you have to port, you will then look at all frameworks.

Re: Flex 5 in haxe

[Kevin Newman <Ca...@unFocus.com>]

To be blunt, if Flex doesn't measure up against those other frameworks, 
it has no future - regardless of the language it's built on.

Kevin N.


On 11/21/2012 7:18 PM, Alex Harui wrote:
> Because if I offer a solution that doesn't require porting your existing
> code you might be willing to accept other tradeoffs.  But if you have to
> port, you will then look at all frameworks.

Re: Flex 5 in haxe

[Alex Harui <ah...@adobe.com>]

On 11/21/12 3:49 PM, "sébastien Paturel" <se...@gmail.com> wrote:

> If you consider Cordova only as short term answer, for POC achievement,
> thats ok for me.
Cordova will be around long-term if it proves viable for enough people.
> But its not viable as a final solution, because it would be giving up on
> great performances for native apps compared to native code usage directly.
It isn't guaranteed that any solution we do that has multiple targets
wouldn't have extra overhead in its abstractions.
> 
> We have to find out how much work it really is to create something like
> FalconJava. If its not much time of work, its ok, if not, its a big
> weakness against Haxe which has already a great background and decent
> community around it!!
> But moreover, you'r talking about FalconJS, FalconJava etc but if i
> understand your strategy it will be needed only for Logic code right?
> But the big performances killer on mobile is more on the UI side if i'm
> not wrong. especially when you compare HTML5/JS with Flash.
> And targetting a new device, does not mean only to get FalconNewLanguage
> but also the MXML transcompilation to the new native UI runtime. And i
> believe that its the biggest amount of work for each new target.
I'm not planning on transcompilation of MXML.
> 
> If AS3/Cordova POC and Haxe POC are two satisfying results.
> What do you thing of keeping both?
We can certainly keep both.
> As we are starting from scratch, its not so hard to keep synch of two
> code base with two different languages (but very similar. using
> automatic tools to do at least half of the translation).
> With such a dual solution, we can use the best of the two solutions for
> our needs.
> 
> I still don't understand why you say that if we don't use AS3, current
> flex users would have wider choice.
Because if I offer a solution that doesn't require porting your existing
code you might be willing to accept other tradeoffs.  But if you have to
port, you will then look at all frameworks.
> We are all pushing flex future, especially because there is no mature
> alternative that can really compete with flex.
> 


-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

Re: Flex 5 in haxe

[sébastien Paturel <se...@gmail.com>]

If you consider Cordova only as short term answer, for POC achievement, 
thats ok for me.
But its not viable as a final solution, because it would be giving up on 
great performances for native apps compared to native code usage directly.

We have to find out how much work it really is to create something like 
FalconJava. If its not much time of work, its ok, if not, its a big 
weakness against Haxe which has already a great background and decent 
community around it!!
But moreover, you'r talking about FalconJS, FalconJava etc but if i 
understand your strategy it will be needed only for Logic code right?
But the big performances killer on mobile is more on the UI side if i'm 
not wrong. especially when you compare HTML5/JS with Flash.
And targetting a new device, does not mean only to get FalconNewLanguage 
but also the MXML transcompilation to the new native UI runtime. And i 
believe that its the biggest amount of work for each new target.

If AS3/Cordova POC and Haxe POC are two satisfying results.
What do you thing of keeping both?
As we are starting from scratch, its not so hard to keep synch of two 
code base with two different languages (but very similar. using 
automatic tools to do at least half of the translation).
With such a dual solution, we can use the best of the two solutions for 
our needs.

I still don't understand why you say that if we don't use AS3, current 
flex users would have wider choice.
We are all pushing flex future, especially because there is no mature 
alternative that can really compete with flex.

Le 21/11/2012 23:52, Alex Harui a écrit :
>
>
> On 11/21/12 2:42 PM, "Daniel Wasilewski" <de...@gmail.com> wrote:
>> I am looking forward to it then, only one question remains,  what about
>> Java for Android and IOS targets?
>> Do you have FalconAndroid and FalconIOS in mind?
> It is not obvious to me why a FalconJava and FalconObjectiveC is not
> possible, so yes.
>> Having those 4 crucial targets covered these days is the very thing
>> Adobe promised to us a while ago. Write once deploy everywhere.
> Cordova may be the short term answer, however.
>> I still have hopes Flex can do it, but if not, I will try to make it happen.
>>
>> P.S.
>> Why I can't see my own response on the list?
>>
>> Best
>> Dan

Re: Flex 5 in haxe

[Alex Harui <ah...@adobe.com>]

On 11/21/12 2:42 PM, "Daniel Wasilewski" <de...@gmail.com> wrote:
>> 
> I am looking forward to it then, only one question remains,  what about
> Java for Android and IOS targets?
> Do you have FalconAndroid and FalconIOS in mind?
It is not obvious to me why a FalconJava and FalconObjectiveC is not
possible, so yes.
> 
> Having those 4 crucial targets covered these days is the very thing
> Adobe promised to us a while ago. Write once deploy everywhere.
Cordova may be the short term answer, however.
> I still have hopes Flex can do it, but if not, I will try to make it happen.
> 
> P.S.
> Why I can't see my own response on the list?
> 
> Best
> Dan

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

Re: Flex 5 in haxe

[Daniel Wasilewski <de...@gmail.com>]

> For me, AS3 is the key factor.  If you make folks learn a new language, it
> makes their set of choices much wider.

My goal is not to get rid of AS3, but preserve it as the one that you 
can target multiple platforms natively.
by my analogy, I don't need an Esperanto, but room of Native tongue 
interpreters.

But Esperanto 'can' be developed on top of that. Not as a substitute.

> I didn't, but I have my plan and hope to show to folks next week.
>
I am looking forward to it then, only one question remains,  what about 
Java for Android and IOS targets?
Do you have FalconAndroid and FalconIOS in mind?

Having those 4 crucial targets covered these days is the very thing 
Adobe promised to us a while ago. Write once deploy everywhere.
I still have hopes Flex can do it, but if not, I will try to make it happen.

P.S.
Why I can't see my own response on the list?

Best
Dan

Re: Flex 5 in haxe

[Daniel Wasilewski <de...@gmail.com>]

> A component is an encapsulation of code, and its API is its contract.  To
> the extend that you can hide aspects of the target inside components and
> fulfill those contracts, and to the extent that an application is an
> assembly of components with some glue code, then yes.
>
> For sure, you can't do everything you can do in Flash on other targets (or
> it might be very hard or very slow), but the question is, for any Flex app
> you built, how much Flash-specific stuff was truly required?  We may not
> apply a blur to the background when an Alert goes up in the new framework,
> but does that really matter?
Not much, output behaviour could vary and still be a platform dependant 
but having one consistent environment that you can write your code in 
familiar language would save us from many obstacles. Those sort of 
things could be sorted out by having Flex IDE, while you choosing a 
target platform not available features could just grey-out or give you 
less options to choose from.

Re: Flex 5 in haxe

[Alex Harui <ah...@adobe.com>]

On 11/21/12 2:51 PM, "Daniel Wasilewski" <de...@gmail.com> wrote:

> Apology for feel instead of fill a gap ;)
> 
> So once again, this is it, room of interpreters instead force people to
> learn Esperanto.
> the phrase 'For disposal of native speakers' could only attract more people.
> But the Flex itself as a framework should fill that gap imho. Make it
> more abstract, platform independent and preserve already accepted
> methodology.
> Is it possible to make it happen by implementing Flex in native
> platforms directly as a bare-bones?
A component is an encapsulation of code, and its API is its contract.  To
the extend that you can hide aspects of the target inside components and
fulfill those contracts, and to the extent that an application is an
assembly of components with some glue code, then yes.

For sure, you can't do everything you can do in Flash on other targets (or
it might be very hard or very slow), but the question is, for any Flex app
you built, how much Flash-specific stuff was truly required?  We may not
apply a blur to the background when an Alert goes up in the new framework,
but does that really matter?
> 
> Dan
> 
> On 11/21/2012 10:40 PM, Fréderic Cox wrote:
>> On 21/11/12 23:29, "Alex Harui" <ah...@adobe.com> wrote:
>>>> I took a different approach. Instead of relying on generic compiler, my
>>>> goal is to implement a framework with a consistent set of rules, in
>>>> native languages and platforms.
>>>> Feel a gap in missing feature territory and encapsulate it in one place.
>>>> On top of that very abstract scripting language can be developed as
>>>> well.
>>> For me, AS3 is the key factor.  If you make folks learn a new language, it
>>> makes their set of choices much wider.
>>> 
>> I Agree, I also think AS3 => JS is the only real option we should pursue
>> if we want to maintain momentum on Flex for the wider audience of Flex
>> developers. They don't want to write in a new language because the chance
>> is higher that they will not choose Flex in that case. AS3 + MXML is key,
>> the output can vary (JS, SWF, ..)
>> 
>> 
> 

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

Re: Flex 5 in haxe

[Daniel Wasilewski <de...@gmail.com>]

Apology for feel instead of fill a gap ;)

So once again, this is it, room of interpreters instead force people to 
learn Esperanto.
the phrase 'For disposal of native speakers' could only attract more people.
But the Flex itself as a framework should fill that gap imho. Make it 
more abstract, platform independent and preserve already accepted 
methodology.
Is it possible to make it happen by implementing Flex in native 
platforms directly as a bare-bones?

Dan

On 11/21/2012 10:40 PM, Fréderic Cox wrote:
> On 21/11/12 23:29, "Alex Harui" <ah...@adobe.com> wrote:
>>> I took a different approach. Instead of relying on generic compiler, my
>>> goal is to implement a framework with a consistent set of rules, in
>>> native languages and platforms.
>>> Feel a gap in missing feature territory and encapsulate it in one place.
>>> On top of that very abstract scripting language can be developed as
>>> well.
>> For me, AS3 is the key factor.  If you make folks learn a new language, it
>> makes their set of choices much wider.
>>
> I Agree, I also think AS3 => JS is the only real option we should pursue
> if we want to maintain momentum on Flex for the wider audience of Flex
> developers. They don't want to write in a new language because the chance
> is higher that they will not choose Flex in that case. AS3 + MXML is key,
> the output can vary (JS, SWF, ..)
>
>

Re: Flex 5 in haxe

[Fréderic Cox <co...@gmail.com>]

On 21/11/12 23:29, "Alex Harui" <ah...@adobe.com> wrote:
>> 
>> I took a different approach. Instead of relying on generic compiler, my
>> goal is to implement a framework with a consistent set of rules, in
>> native languages and platforms.
>> Feel a gap in missing feature territory and encapsulate it in one place.
>> On top of that very abstract scripting language can be developed as
>>well.
>For me, AS3 is the key factor.  If you make folks learn a new language, it
>makes their set of choices much wider.
>

I Agree, I also think AS3 => JS is the only real option we should pursue
if we want to maintain momentum on Flex for the wider audience of Flex
developers. They don't want to write in a new language because the chance
is higher that they will not choose Flex in that case. AS3 + MXML is key,
the output can vary (JS, SWF, ..)

>

Re: Flex 5 in haxe

[Alex Harui <ah...@adobe.com>]

On 11/21/12 2:19 PM, "Daniel Wasilewski" <de...@gmail.com> wrote:
> There was a lot of talks here about approach to be taken to bring Flex
> to the next level.
> One of them was the fact that in order to target multiple platforms you
> need to have a descent compiler to convert AST into native language.
> That requires a lot of work and effort.
We will be seeing the FalconJS code in Apache shortly.  I don't know how
much work it was, but it only 40 files or so.
> Nobody here familiar with a
> scale of effort that needs to be put into such project have confidence
> it can be done in reasonable amount of time and resources due to lots of
> platform inconsistencies and the fact, that some of the platform
> specific languages and features just missing.
My goal is to avoid using things that are hard to implement in other
platforms, at least in the early versions.
> 
> I took a different approach. Instead of relying on generic compiler, my
> goal is to implement a framework with a consistent set of rules, in
> native languages and platforms.
> Feel a gap in missing feature territory and encapsulate it in one place.
> On top of that very abstract scripting language can be developed as well.
For me, AS3 is the key factor.  If you make folks learn a new language, it
makes their set of choices much wider.

> If I will see Flex going in that direction, leverage the best practices
> of the target platforms instead to try to be a Swiss knife, I would be
> happy to share my vision in details and contribute to the project. But
> most of all, did you consider or discussed that very option well enough?
I didn't, but I have my plan and hope to show to folks next week.

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

Re: Flex 5 in haxe

[Daniel Wasilewski <de...@gmail.com>]

I am following this this discussion carefully as well as all what is 
going on on Apache Flex from the very beginning.

Clearly if the future of Flex attached to Flash Player would be bright 
this thread should not exist at all.
But is here, and there is a lot of concerns surrounding it. I have 
recognised that long time ago and started my own project called BixBite.

If you are not familiar with it yet here is a little presentation I am 
just getting ready for public.
http://bixbite.org/BixBitePresentation.swf (hope everyone can play swf 
directly from the browser ;) )

There was a lot of talks here about approach to be taken to bring Flex 
to the next level.
One of them was the fact that in order to target multiple platforms you 
need to have a descent compiler to convert AST into native language.
That requires a lot of work and effort. Nobody here familiar with a 
scale of effort that needs to be put into such project have confidence 
it can be done in reasonable amount of time and resources due to lots of 
platform inconsistencies and the fact, that some of the platform 
specific languages and features just missing.

I took a different approach. Instead of relying on generic compiler, my 
goal is to implement a framework with a consistent set of rules, in 
native languages and platforms.
Feel a gap in missing feature territory and encapsulate it in one place. 
On top of that very abstract scripting language can be developed as well.
But my approach is a bit different from what HaXe can offer. I am not 
trying to create Esperanto language and force people to learn it.
I propose to hire native interpreters that sitting in one room, for 
dispose of all people who can speak their native languages.

This room is my framework, so and Flex can also be that kind of room.

If I will see Flex going in that direction, leverage the best practices 
of the target platforms instead to try to be a Swiss knife, I would be 
happy to share my vision in details and contribute to the project. But 
most of all, did you consider or discussed that very option well enough?

Best
Dan


On 11/21/2012 9:59 PM, Carlos Rovira wrote:
> Hi Alex,
>
> I'm strong advocate to make POCs in different directions so we could end
> getting more knowledge that could end turning all efforts in a real next
> generation framework. For that reason I think we'll end over the next year
> with various groups targeting different points of views: AS3, Haxe and so
> on, as well maintaining actual codebase
>
> For me, in a full rewrite, the reason not to go AS3 is:
>
> * AS3 will be killed by its own evolution AS4
> * AVM2 will be killed by its own evolution AVMNext
> * If we could get rid off Adobe's technologies, the better. It's not only
> because we, as an open source project, should not depend heavily on
> propietary technologies (if we can), it's because we have the experience on
> how Adobe throw the towel, and that makes a precedent, so they could make
> it again. Confidence in a future depending on Adobe is something that I
> would try to avoid if possible.
> * Haxe has the key points we are asking for: One language (OOP) - multiple
> targets.
> * Haxe will serve us next AS4/AVMNext without the need of change the
> language.
> * They already has the HTML5/JS output, the actual Flash AVM output, and
> all the mobile platforms output.
>
> ...of course all this have sense since the proposal is "a new Flex from
> scratch".
>
> Your point of "Haxe is not in Apache" is not a point for me. Take into
> account that we already use other open source projects that are not in
> apache. More over, Apache is an instrument right now and even for such new
> project, we could event think in go directly to Github, if after a few more
> trys we don't get git-github support or Apache bureaucracy is not as agile
> as we need.
>
> I'm with you that we should start coding and making more POC and not only
> talking, but In my case my next efforts as you saw will be in Git support,
> and need to learn more about Haxe to be able to start playing with all this
> ideas.
>
>
>
>
>
> 2012/11/21 Alex Harui <ah...@adobe.com>
>
>>
>>
>> On 11/21/12 12:53 PM, "Kevin Newman" <Ca...@unFocus.com> wrote:
>>
>>> But if we are to change languages, why not go with a language that,
>>> looks a lot like AS3 (and ports easy), addresses the language
>>> scalability issues of JavaScript (lack of classes, typing, a compiler,
>>> etc.), and can compile to JS as well as other languages? Haxe can be
>>> compiled into JS, ABC/SWF, C++, C#, etc.
>> My angle for now is not to change languages.  We can write in AS3 and
>> cross-compile to JS and maybe other languages.  Apache Flex effectively
>> owns
>> AS3 because it owns a compiler for it.
>>
>>> Why NOT use Haxe?
>> -Haxe is not in Apache.
>> -There are lots of existing AS3 code libraries I think we should try to
>> leverage.
>> -I know how AS3 behaves on Flash.
>>
>> But again, none of these, even in aggregate, are strong enough reasons to
>> a-priori say that some other group of folks shouldn't pursue a rewrite on
>> Haxe.
>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
>>
>

Re: Flex 5 in haxe

[Alex Harui <ah...@adobe.com>]

On 11/21/12 1:59 PM, "Carlos Rovira" <ca...@codeoscopic.com> wrote:

> For me, in a full rewrite, the reason not to go AS3 is:
> 
> * AS3 will be killed by its own evolution AS4
Not true.  Apache Flex effectively owns it.  The language doesn't have to
result in AVM2 ABC code.  FalconJS will prove that.
> * AVM2 will be killed by its own evolution AVMNext
Doesn't matter since we are aiming for JS.  But AVM2 will be around on
desktops with keyboards for a long time.
> * If we could get rid off Adobe's technologies, the better. It's not only
> because we, as an open source project, should not depend heavily on
> propietary technologies (if we can), it's because we have the experience on
> how Adobe throw the towel, and that makes a precedent, so they could make
> it again. Confidence in a future depending on Adobe is something that I
> would try to avoid if possible.
With FalconJS that becomes possible
> * Haxe has the key points we are asking for: One language (OOP) - multiple
> tar
And Falcon may make this possible with AS3 as well.

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

Re: Flex 5 in haxe

[Carlos Rovira <ca...@codeoscopic.com>]

Hi Alex,

I'm strong advocate to make POCs in different directions so we could end
getting more knowledge that could end turning all efforts in a real next
generation framework. For that reason I think we'll end over the next year
with various groups targeting different points of views: AS3, Haxe and so
on, as well maintaining actual codebase

For me, in a full rewrite, the reason not to go AS3 is:

* AS3 will be killed by its own evolution AS4
* AVM2 will be killed by its own evolution AVMNext
* If we could get rid off Adobe's technologies, the better. It's not only
because we, as an open source project, should not depend heavily on
propietary technologies (if we can), it's because we have the experience on
how Adobe throw the towel, and that makes a precedent, so they could make
it again. Confidence in a future depending on Adobe is something that I
would try to avoid if possible.
* Haxe has the key points we are asking for: One language (OOP) - multiple
targets.
* Haxe will serve us next AS4/AVMNext without the need of change the
language.
* They already has the HTML5/JS output, the actual Flash AVM output, and
all the mobile platforms output.

...of course all this have sense since the proposal is "a new Flex from
scratch".

Your point of "Haxe is not in Apache" is not a point for me. Take into
account that we already use other open source projects that are not in
apache. More over, Apache is an instrument right now and even for such new
project, we could event think in go directly to Github, if after a few more
trys we don't get git-github support or Apache bureaucracy is not as agile
as we need.

I'm with you that we should start coding and making more POC and not only
talking, but In my case my next efforts as you saw will be in Git support,
and need to learn more about Haxe to be able to start playing with all this
ideas.





2012/11/21 Alex Harui <ah...@adobe.com>

>
>
>
> On 11/21/12 12:53 PM, "Kevin Newman" <Ca...@unFocus.com> wrote:
>
> > But if we are to change languages, why not go with a language that,
> > looks a lot like AS3 (and ports easy), addresses the language
> > scalability issues of JavaScript (lack of classes, typing, a compiler,
> > etc.), and can compile to JS as well as other languages? Haxe can be
> > compiled into JS, ABC/SWF, C++, C#, etc.
> My angle for now is not to change languages.  We can write in AS3 and
> cross-compile to JS and maybe other languages.  Apache Flex effectively
> owns
> AS3 because it owns a compiler for it.
>
> > Why NOT use Haxe?
> -Haxe is not in Apache.
> -There are lots of existing AS3 code libraries I think we should try to
> leverage.
> -I know how AS3 behaves on Flash.
>
> But again, none of these, even in aggregate, are strong enough reasons to
> a-priori say that some other group of folks shouldn't pursue a rewrite on
> Haxe.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>


-- 
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F:  +34 912 35 57 77
http://www.codeoscopic.com
http://www.directwriter.es
http://www.avant2.es

Re: Flex 5 in haxe

[Kevin Newman <Ca...@unFocus.com>]

So in that case it'd either be using (or completing then using) 
FalconJS, or Jangaroo (pulling it into Apache maybe - it's already under 
Apache 2.0 license).

That doesn't sound terrible. That could even allow Apache to move AS3 
(ApacheScript!) in a different direction over time from what Adobe ends 
up doing with ASNext if divergence is desired.

Kevin N.


On 11/21/12 4:04 PM, Alex Harui wrote:
> My angle for now is not to change languages.  We can write in AS3 and
> cross-compile to JS and maybe other languages.  Apache Flex effectively owns
> AS3 because it owns a compiler for it.

Re: Flex 5 in haxe

[Hordur Thordarson <ho...@lausn.is>]

Oh darn, hit Send too soon...

... re-architect the framework, was the intended ending.

On 21.11.2012, at 22:10, Hordur Thordarson wrote:

> This sounds like a very reasonable strategy to me, ie. continue supporting (as long as makes sense) the current AS3/Flash VM solution and concurrently work towards a AS3 --> JS solution to remove the Adobe dependency and possibly re-architect the.
> 
> On 21.11.2012, at 21:04, Alex Harui wrote:
> 
>> On 11/21/12 12:53 PM, "Kevin Newman" <Ca...@unFocus.com> wrote:
>> 
>>> But if we are to change languages, why not go with a language that,
>>> looks a lot like AS3 (and ports easy), addresses the language
>>> scalability issues of JavaScript (lack of classes, typing, a compiler,
>>> etc.), and can compile to JS as well as other languages? Haxe can be
>>> compiled into JS, ABC/SWF, C++, C#, etc.
>> My angle for now is not to change languages.  We can write in AS3 and
>> cross-compile to JS and maybe other languages.  Apache Flex effectively owns
>> AS3 because it owns a compiler for it.
>> 
>>> Why NOT use Haxe?
>> -Haxe is not in Apache.
>> -There are lots of existing AS3 code libraries I think we should try to
>> leverage.
>> -I know how AS3 behaves on Flash.
>> 
>> But again, none of these, even in aggregate, are strong enough reasons to
>> a-priori say that some other group of folks shouldn't pursue a rewrite on
>> Haxe.
>> 
>> -- 
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>> 
> 

Re: Flex 5 in haxe

[Hordur Thordarson <ho...@lausn.is>]

This sounds like a very reasonable strategy to me, ie. continue supporting (as long as makes sense) the current AS3/Flash VM solution and concurrently work towards a AS3 --> JS solution to remove the Adobe dependency and possibly re-architect the.

On 21.11.2012, at 21:04, Alex Harui wrote:

> On 11/21/12 12:53 PM, "Kevin Newman" <Ca...@unFocus.com> wrote:
> 
>> But if we are to change languages, why not go with a language that,
>> looks a lot like AS3 (and ports easy), addresses the language
>> scalability issues of JavaScript (lack of classes, typing, a compiler,
>> etc.), and can compile to JS as well as other languages? Haxe can be
>> compiled into JS, ABC/SWF, C++, C#, etc.
> My angle for now is not to change languages.  We can write in AS3 and
> cross-compile to JS and maybe other languages.  Apache Flex effectively owns
> AS3 because it owns a compiler for it.
> 
>> Why NOT use Haxe?
> -Haxe is not in Apache.
> -There are lots of existing AS3 code libraries I think we should try to
> leverage.
> -I know how AS3 behaves on Flash.
> 
> But again, none of these, even in aggregate, are strong enough reasons to
> a-priori say that some other group of folks shouldn't pursue a rewrite on
> Haxe.
> 
> -- 
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
> 

Re: Flex 5 in haxe

[Alex Harui <ah...@adobe.com>]

On 11/21/12 12:53 PM, "Kevin Newman" <Ca...@unFocus.com> wrote:

> But if we are to change languages, why not go with a language that,
> looks a lot like AS3 (and ports easy), addresses the language
> scalability issues of JavaScript (lack of classes, typing, a compiler,
> etc.), and can compile to JS as well as other languages? Haxe can be
> compiled into JS, ABC/SWF, C++, C#, etc.
My angle for now is not to change languages.  We can write in AS3 and
cross-compile to JS and maybe other languages.  Apache Flex effectively owns
AS3 because it owns a compiler for it.

> Why NOT use Haxe?
-Haxe is not in Apache.
-There are lots of existing AS3 code libraries I think we should try to
leverage.
-I know how AS3 behaves on Flash.

But again, none of these, even in aggregate, are strong enough reasons to
a-priori say that some other group of folks shouldn't pursue a rewrite on
Haxe.

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

Re: Flex 5 in haxe

[Kevin Newman <Ca...@unFocus.com>]

On 11/21/12 1:22 PM, Alex Harui wrote:
> And, what isn't clear is how well AIR will run on that device,
> if at all.  There are so many devices it will be hard for AIR to keep
> running well (in captive runtime of course) on all of them.
The exact same thing was true for desktop/laptops with Flash. I offer as 
proof - every single Flex, ever, especially on any of the "Pentium" or 
"Celeron" powered budget wintels (or even some older higher level 
equipment). There are also plenty of other middleware platforms that are 
in a worse position than AIR (stage3d is magic - there should be a 
Cocoa-like API on top of that), who are doing just fine supporting all 
these divergent hardware platforms. And, ARM is doing a fantastic job 
holding things in some semblance of order on the hardware side. Intel 
may be crying in their beer, but they aren't not the captain of the 
mobile ship, which is already miles out to sea without them.

Besides, I haven't been advocating for AIR anyway (Adobe should, but 
they aren't) - I've been advocating for AIR like APIs, but a compile 
system that routes through a native build system. That's how Haxe works, 
and I think that's actually easier to deal with over time, as hardware 
and OS platforms evolve. Adobe could do that with AS4 (and proprietary 
AIR libs like Stage3D, DRM, video, etc.), but they don't seem 
interested. Instead, they just want to add a highway tax for rich 
industries like "Console Quality Games" to gain access to their their 
huge (but diminishing) install base. I mean that'll work, for a year or 
two. Until Native Client or something else eats Adobe's lunch (maybe 
that's why Google is destabilizing Flash in Chrome, heh).

> This is why, even though Flash will be running in browsers on desktops with
> keyboards "forever", more and more of the folks most of you are targeting
> won't be using a browser/keyboard combination that is Flash capable.
>
> And, eventually, the network speeds and prices and device speeds will reach
> the point where zero-install browser-delivered apps on those devices become
> the predominant paradigm again.
You are talking year and years out for device speeds, and I doubt it the 
market will go back anyway. I wrote a while back that the problem of 
native apps in the web browser era was app delivery and discoverability. 
With new battery life constraints on mobile systems, and the relatively 
hampered experience you get from browsers measured against native apps - 
and most importantly the easy access to app store content in modern 
operating systems - I don't know know if browser apps will ever come 
back into dominance in quite the same way. Maybe with the right tooling, 
and adjustments to the actual mobile browsers, even then I'm skeptical. 
Apple has already shown unwillingness to make things easier to bypass 
their app store - hampering "webapps" in various ways for example.

I actually think both sides will resist movement back to browser as the 
primary app distribution model - those that run app stores, and those 
that sell apps through them. App stores are just too easy to sell 
through and monetize. In an important way they fill a gap the ads only, 
search and discovery web based e-commerce system couldn't fill. It's so 
lucrative, BTW, that no one seems bothered by the 30% tax they lose on 
each app sale. That speaks volumes about the acceptance, and is perhaps 
a sign of the entrenchment of app stores.

I suppose maybe HTML5 app store apps could still work, but I'm skeptical 
they'll ever deliver the better speed and battery life they'd need to to 
make it in there. And, developing in JS is the pits. Many of us have 
been forced to try it over the last year, and it's just not great. The 
tooling sucks, probably always will, and the language itself has 
scalability issues, and that's before you even get into the DOM and all 
the platform inconsistencies. Adobe jumped way too early off the stable 
steal Flash ship, onto the rickety hobbled together by twine raft of HTML5.

> For sure, there are plenty of reasons to keep maintaining the current code
> base, and I will invest time there.  But I see it as my mandate to try to
> shape a next generation of Flex that is designed to be ported to other
> platforms.  By going to JS, we get the most coverage for the least amount of
> work, but we have to give up fidelity and performance.  Over time, with
> enough resources, we may be able to target other platforms natively, but
> that will take a lot of time and effort.
But if we are to change languages, why not go with a language that, 
looks a lot like AS3 (and ports easy), addresses the language 
scalability issues of JavaScript (lack of classes, typing, a compiler, 
etc.), and can compile to JS as well as other languages? Haxe can be 
compiled into JS, ABC/SWF, C++, C#, etc. Why NOT use Haxe?

Of course, the decision hasn't been made to switch off of AS3 just yet, 
but AS3 just seems to be a dead end, both in the wild, and at Adobe. AS4 
would be the most obvious way forward, but that's not possible without 
first class support from Adobe, and they've sent clear signals will not 
happen.

> Those of you who are Haxe fans should definitely start your own rewrite.  We
> can't just keep talking about it in email.  We won't know how it will truly
> be to move to Haxe until there is something to actually play with.  We don't
> have to decide as a community which language to use for a re-write without
> actually trying a couple of different angles.  For me, I will stay on AS3
> unless I get strong signals that there is no value to any of our current
> Flex developers by staying on it.
That's not a bad idea. Someone should just throw some stuff into github 
and get started. :-)

Kevin N.

Re: Flex 5 in haxe

[Alex Harui <ah...@adobe.com>]

On 11/21/12 8:53 AM, "Kevin Newman" <Ca...@unFocus.com> wrote:

>  From what I see, the HTML5 everything push is ending - mostly because
> of performance issues on the native app side.
Here's my take: sometimes when you buy into the hype to early and the
technology isn't ready, you get burned, and then there is a move away.  But
if you don't keep watching you may miss when it does become ready.  I don't
know HTML5, but for sure, there is a lot of smart people working on it.  It
may not be ready today, or even 3 years from now, but will get faster as the
hardware gets faster, and folks will eventually settle on Dart or some other
OO language to migrate to from JS.  Could be 10 years from now, but I'm
pretty sure it will happen.

Meanwhile, all of you on this list are in different circumstances, but I can
think of a three buckets: 1) You are employed by an enterprise that is going
to need desktops with keyboards for quite some time (although watch out for
keyboards to go away as natural language input gets better).  The
availability of fast networks and the lower maintenance of zero-install,
browser-delivered apps is attractive, and you can control whether Flash is
used or not.
2) You are an independent consultant that builds apps for companies.  You
can't control whether Flash is used or not.
3) You are building an app that just plain needs Flash (maybe premium video)
or requires a lot of input so you can assume folks will have keyboards.

Flash on a desktop with a keyboard will be around for a very long time.
There are too many desktops with keyboards in companies who will complain
loudly if any of the companies involved (OS, browser, Adobe) screws that up.

But some projections say that laptop sales in the home/consumer market is
doomed by tablets just like pocket cameras were doomed by smartphones.  If
your target customer is not a business worker with a need for a keyboard,
you can assume they will soon be using a device that doesn't run Flash in
the browser.  And, what isn't clear is how well AIR will run on that device,
if at all.  There are so many devices it will be hard for AIR to keep
running well (in captive runtime of course) on all of them.

This is why, even though Flash will be running in browsers on desktops with
keyboards "forever", more and more of the folks most of you are targeting
won't be using a browser/keyboard combination that is Flash capable.

And, eventually, the network speeds and prices and device speeds will reach
the point where zero-install browser-delivered apps on those devices become
the predominant paradigm again.

For sure, there are plenty of reasons to keep maintaining the current code
base, and I will invest time there.  But I see it as my mandate to try to
shape a next generation of Flex that is designed to be ported to other
platforms.  By going to JS, we get the most coverage for the least amount of
work, but we have to give up fidelity and performance.  Over time, with
enough resources, we may be able to target other platforms natively, but
that will take a lot of time and effort.

I am starting a re-write that prioritizes different things than the current
code base.  It won't use things that are hard to port like weak references
and Dictionary so you may have to do more work managing memory.  It will
have other deficiencies and trade-offs and will never match exactly what you
have today.  But it should still feel a lot like current Flex.  By starting
now and trying to get to critical mass over the next year or two, the goal
is to have a softer landing for those who have a lot invested in AS3 and the
current code.

Those of you who are Haxe fans should definitely start your own rewrite.  We
can't just keep talking about it in email.  We won't know how it will truly
be to move to Haxe until there is something to actually play with.  We don't
have to decide as a community which language to use for a re-write without
actually trying a couple of different angles.  For me, I will stay on AS3
unless I get strong signals that there is no value to any of our current
Flex developers by staying on it.

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

Re: Flex 5 in haxe

[Kevin Newman <Ca...@unFocus.com>]

 From what I see, the HTML5 everything push is ending - mostly because 
of performance issues on the native app side. HTML5 is still taking over 
for flash in the desktop/laptop web space for most things, though even 
there, folks are starting to loudly express dissatisfaction with 
platform fragmentation, and other problems. This transition has been 
ongoing for many years now. Mr. Zuckerberg also pointed out that they 
get more traffic through the mobile website than they get through their 
native apps, so even on mobile HTML5 still matters (it's just usually 
less of an app experience, and more of a webpage experience).

Today, for native apps we need to either go all in with native toolkits, 
or target good middleware like Unity3D or AIR. I think we can still 
target both worlds (browsers and apps) from one author environment, but 
in native apps the name of the game is performance (even on desktops). 
Flex/Actionscript/HaXe needs to rival Cocoa/Obj-C and Android/Java to be 
compelling. That's the starting point for Flex, then if we can have a 
high performing HTML5 target as well, that's a strong multi-platform 
story. (This is area where Adobe leans too much on legacy in their 
narratives, rather than deferring to the future. Even their gaming 
narrative they only fumble into "expanding gaming markets" as an 
aspirational note - their narratives are mostly about leveraging their 
ubiquitous and sizable Flash install base - coasting on the legacy. 
Boring! Technology is about the future and possibility.)

What I imagine is that Flex could be used to create something cool like 
Trello.com (as just a random example) but then target both platforms 
with much of the same code base, rather than they way they do it now 
with, HTML5 (and Coffeescript) for the web (which frankly doesn't run 
well - or often at all in my experience - on mobile browsers) and native 
apps for each platform (they only have iOS for now, I'd guess due to the 
resources it would take to target everything).

Just as another random thought, it might be cool to be able to more 
easily utilize native APIs than you can through AIR's ANE mechanism. 
Since HaXe compiles into other languages first, it has access to the 
libraries of those languages directly (like compiling to C++ for iOS), 
externs can be added for all kind of access to native APIs. Using that 
part of HaXe, the idea that's been floated about doing an MVC system in 
Flex, where the View part is done in the native language (JavaScript, 
Java, C#, Obj-C/C/C++, etc.) might actually be easier through haXe than 
other language platforms. There are a bunch of externs out there already 
for various platforms (don't know how stable or complete they all are 
though).

Kevin N.

(You could technically do that externs trick with ANEs and some tweaks 
to AIR from Adobe - but they aren't interested.)

On 11/21/12 7:07 AM, Hordur Thordarson wrote:
> this HTML5 for everything push.

Re: Flex 5 in haxe

[Hordur Thordarson <ho...@lausn.is>]

No, they want the Adobe AIR scenario, embeddable VM (JRE).  And rumor has it this allready exists for iOS and Android in an Oracle lab but was frozen because of ... <insert your favorite conspiracy theory/business reason here> :-)  But since Adobe did this with AIR there is nothing technically that prevents others from doing it.

But this is a Flex thread so we should stick with discussing Flex, allthough I think there is some value in discussing how other platforms/technologies are handling this HTML5 for everything push.

On 21.11.2012, at 11:51, Carlos Rovira wrote:

> JavaFx looks pretty good. For people like us it'll solve much of the
> problems since the platform gives you out-of-the-box, I'm referring to
> maven driven projects, AOP, Annotations on steroids, and so on...JavaFX 2
> revisions look so good and seems they copy lots of things from the Flex
> world (@FXSkin seems to be like [SkinPart] ;) )...but as you say the
> problem seems to be as always with java client technologies, with the
> deployment model. If they plan to target runtimes like Haxe did, it could
> be very cool, but right now I only see problems in the last node of its
> chain...
> 
> 
> 
> 2012/11/21 Hordur Thordarson <ho...@lausn.is>
> 
>> Exactly.  And talking about reality, reality is also that HTML will never
>> be everything to everybody, a one-size-fits-all solution, simply because
>> there are no such solutions, requirements are very different depending on
>> what you are building.  For myself, I'll check out JavaFX before being
>> stuck with deploying to HTML/JS.  If the JavaFX crowd gets it's deployment
>> experience sorted (it is currently very poor compared fex to AIR) and they
>> find a way of building captive-runtime apps for mobile (both problems are
>> being worked on btw), then they have a pretty cool platform on their hands
>> where you can write your frontend and backend in Java (like the JS crowd is
>> trying with Node.js).  Since I use JavaEE for the backend for my apps, this
>> would be a killer scenario for me.
>> 
>> On 21.11.2012, at 11:08, Carlos Rovira wrote:
>> 
>>>> HTML5 is not mature enough to compete with flash player right now, but
>> we
>>>> have to think about future, and it will improve quite quick with all the
>>>> hype around it.
>>>> And even if you prefer flash player, there is our dreams, and there is
>>>> reallity. And reallity is that Adobe is pushing HTML5 for web and
>> giving up
>>>> flash player for that. And we have to be prepared to a time where there
>>>> will not be flash player only HTML5 everywhere. (in several years maybe,
>>>> but will happen unless something drastically change)
>>> 
>>> The problem with this HTML5 trend is that HTML5 does not fit all
>>> necessities. Big desktop/browser applications are a pain to develop and
>>> maintain in HTML5. I understand how facebook people suffer ;). So Apple,
>>> Adobe and others are pushing tools to solve little solutions, but not
>>> enterprise solutions, since they didn't get any money (since they never
>>> understand/improve their business model to target the enterprise world)
>>> 
>>> I'd like to target HTML5/JS but to solve the problem of deploy for mobile
>>> browsers (or even desktop browsers if I need...) some solutions that use
>> to
>>> be not as huge as the ones we develop (ERPs and other big monsters only
>>> desktop apps...) and make all of this using the same development paradigm
>>> (IDEs, language, OOP,...)
>> 
>> 
> 
> 
> -- 
> Carlos Rovira
> Director de Tecnología
> M: +34 607 22 60 05
> F:  +34 912 35 57 77
> http://www.codeoscopic.com
> http://www.directwriter.es
> http://www.avant2.es

Re: Flex 5 in haxe

[Carlos Rovira <ca...@codeoscopic.com>]

JavaFx looks pretty good. For people like us it'll solve much of the
problems since the platform gives you out-of-the-box, I'm referring to
maven driven projects, AOP, Annotations on steroids, and so on...JavaFX 2
revisions look so good and seems they copy lots of things from the Flex
world (@FXSkin seems to be like [SkinPart] ;) )...but as you say the
problem seems to be as always with java client technologies, with the
deployment model. If they plan to target runtimes like Haxe did, it could
be very cool, but right now I only see problems in the last node of its
chain...



2012/11/21 Hordur Thordarson <ho...@lausn.is>

> Exactly.  And talking about reality, reality is also that HTML will never
> be everything to everybody, a one-size-fits-all solution, simply because
> there are no such solutions, requirements are very different depending on
> what you are building.  For myself, I'll check out JavaFX before being
> stuck with deploying to HTML/JS.  If the JavaFX crowd gets it's deployment
> experience sorted (it is currently very poor compared fex to AIR) and they
> find a way of building captive-runtime apps for mobile (both problems are
> being worked on btw), then they have a pretty cool platform on their hands
> where you can write your frontend and backend in Java (like the JS crowd is
> trying with Node.js).  Since I use JavaEE for the backend for my apps, this
> would be a killer scenario for me.
>
> On 21.11.2012, at 11:08, Carlos Rovira wrote:
>
> >> HTML5 is not mature enough to compete with flash player right now, but
> we
> >> have to think about future, and it will improve quite quick with all the
> >> hype around it.
> >> And even if you prefer flash player, there is our dreams, and there is
> >> reallity. And reallity is that Adobe is pushing HTML5 for web and
> giving up
> >> flash player for that. And we have to be prepared to a time where there
> >> will not be flash player only HTML5 everywhere. (in several years maybe,
> >> but will happen unless something drastically change)
> >
> > The problem with this HTML5 trend is that HTML5 does not fit all
> > necessities. Big desktop/browser applications are a pain to develop and
> > maintain in HTML5. I understand how facebook people suffer ;). So Apple,
> > Adobe and others are pushing tools to solve little solutions, but not
> > enterprise solutions, since they didn't get any money (since they never
> > understand/improve their business model to target the enterprise world)
> >
> > I'd like to target HTML5/JS but to solve the problem of deploy for mobile
> > browsers (or even desktop browsers if I need...) some solutions that use
> to
> > be not as huge as the ones we develop (ERPs and other big monsters only
> > desktop apps...) and make all of this using the same development paradigm
> > (IDEs, language, OOP,...)
>
>


-- 
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F:  +34 912 35 57 77
http://www.codeoscopic.com
http://www.directwriter.es
http://www.avant2.es

Re: Flex 5 in haxe

[Hordur Thordarson <ho...@lausn.is>]

Exactly.  And talking about reality, reality is also that HTML will never be everything to everybody, a one-size-fits-all solution, simply because there are no such solutions, requirements are very different depending on what you are building.  For myself, I'll check out JavaFX before being stuck with deploying to HTML/JS.  If the JavaFX crowd gets it's deployment experience sorted (it is currently very poor compared fex to AIR) and they find a way of building captive-runtime apps for mobile (both problems are being worked on btw), then they have a pretty cool platform on their hands where you can write your frontend and backend in Java (like the JS crowd is trying with Node.js).  Since I use JavaEE for the backend for my apps, this would be a killer scenario for me.

On 21.11.2012, at 11:08, Carlos Rovira wrote:

>> HTML5 is not mature enough to compete with flash player right now, but we
>> have to think about future, and it will improve quite quick with all the
>> hype around it.
>> And even if you prefer flash player, there is our dreams, and there is
>> reallity. And reallity is that Adobe is pushing HTML5 for web and giving up
>> flash player for that. And we have to be prepared to a time where there
>> will not be flash player only HTML5 everywhere. (in several years maybe,
>> but will happen unless something drastically change)
> 
> The problem with this HTML5 trend is that HTML5 does not fit all
> necessities. Big desktop/browser applications are a pain to develop and
> maintain in HTML5. I understand how facebook people suffer ;). So Apple,
> Adobe and others are pushing tools to solve little solutions, but not
> enterprise solutions, since they didn't get any money (since they never
> understand/improve their business model to target the enterprise world)
> 
> I'd like to target HTML5/JS but to solve the problem of deploy for mobile
> browsers (or even desktop browsers if I need...) some solutions that use to
> be not as huge as the ones we develop (ERPs and other big monsters only
> desktop apps...) and make all of this using the same development paradigm
> (IDEs, language, OOP,...)

Re: Flex 5 in haxe

[Carlos Rovira <ca...@codeoscopic.com>]

>HTML5 is not mature enough to compete with flash player right now, but we
have to think about future, and it will improve quite quick with all the
hype around it.
And even if you prefer flash player, there is our dreams, and there is
reallity. And reallity is that Adobe is pushing HTML5 for web and giving up
flash player for that. And we have to be prepared to a time where there
will not be flash player only HTML5 everywhere. (in several years maybe,
but will happen unless something drastically change)

The problem with this HTML5 trend is that HTML5 does not fit all
necessities. Big desktop/browser applications are a pain to develop and
maintain in HTML5. I understand how facebook people suffer ;). So Apple,
Adobe and others are pushing tools to solve little solutions, but not
enterprise solutions, since they didn't get any money (since they never
understand/improve their business model to target the enterprise world)

I'd like to target HTML5/JS but to solve the problem of deploy for mobile
browsers (or even desktop browsers if I need...) some solutions that use to
be not as huge as the ones we develop (ERPs and other big monsters only
desktop apps...) and make all of this using the same development paradigm
(IDEs, language, OOP,...)

Re: Flex 5 in haxe

[Hordur Thordarson <ho...@lausn.is>]

PhoneGap is for sure a good solution for some developers allthough some of the apps they feature on their website are really just shells around existing web sites.  I have the Wikipedia app on my phone and it is written with PhoneGap.  It works, but is quite slow for what is really a very simple app on top of a website.

But PhoneGap is mobile only, I need cross-platform desktop support as well and I am not interested in a solution that deploys to one runtime on mobile and a totally different runtime on the desktop because that to me is a recipe for increased testing/QA/support/bug workarounds etc and I'll avoid that above all else.

Really, what I want is desktop quality apps seamlessly deployed via the web.  AIR does this pretty darn well, Flash player even better if you are willing to sacrifice a few desktop related features.  But those are my needs/priorities, others have different ones.

On 21.11.2012, at 09:39, Alain Ekambi wrote:

> Now not every company build apps at the scale of FaceBook.
> For most of the case HTML5 mobile apps + PhoneGap(Cordova) are  pretty good.
> 
> 
> 2012/11/21 Hordur Thordarson <ho...@lausn.is>
> 
>> On 20.11.2012, at 22:14, Kevin Newman wrote:
>> 
>>> Mark Zuckerberg also said very publicly that Facebook "burned" (his
>> word) 2 years of development with HTML5, "We burned two years. That's
>> really painful. Probably we will look back saying that is one of the
>> *biggest mistakes* if not *the biggest strategic mistake* that we made." It
>> was less of a "cave" and more of a fundamental shift in understanding (and
>> a correct one).
>> 
>> Agreed and that's really what I ment by "caved in", they just realized it
>> was never going to be as good as a native app.  The problem with HTML5/JS
>> as an app mechanism is that it just wasn't designed for that.  Some changes
>> have been made to it in order to make it easier to write applications (as
>> opposed to web sites which is a totally different thing) but it really
>> isn't very good for that at all except maybe for small apps.  The JavaFX
>> crowd is having the exact same discussion the Flex crowd is, except pretty
>> much no one in the JavaFX crowd wants to deploy to HTML/JS.  They want
>> JavaFX runtimes for mobile so that they can have one set of code and the
>> same or very similar runtime everywhere (sound familiar ?).  And the
>> community is actually working towards a solution that gives them that.  But
>> Oracle, like Adobe, seems to have given into the "HTML5 for everything"
>> rhetoric so they are at least currently not backing this.
>> 
>>> 
>>> This is where Adobe has an opportunity with AIR, that they seem intent
>> on failing to capitalize on (at least in their marketing narratives, and
>> the signals the decision makers are sending out into the market place - the
>> Flash engineers are doing pretty cool stuff with stage3D and whatnot).
>> 
>> Yep, very frustrating that Adobe gave up on this vision because they had
>> by far the strongest dev/deployment story out there with almost the best of
>> everything. with Flash player or AIR for the desktop and AIR for mobile and
>> almost single source for all the platforms (UI tweaks/diffs for
>> phones/tablets obviously).  This is of course still possible, we just don't
>> know how long it is going to last :-(  But while it works, I hope Apache
>> Flex will continue to be maintained/improved in it's current shape.
>> 
>>> 
>>> Anyway, Apache Flex doesn't need to wait for Adobe's higher-ups to
>> figure it out - Flex can go HaXe, and have a multi-platform ubiquity story
>> and an open source story to boot.
>> 
>> Sure.  I have to say though that my clients don't really care if the tools
>> I use are open source or not or whether the language I write in is
>> ActionScript or Haxe or smth else.  They care about functionality,
>> usability, cross-platformness and ease of deployment/updating of the
>> resulting product, and they also want development to cost as little as
>> possible, hence the less problems I have during dev and the less testing I
>> have to do in multiple browsers or with multiple runtimes, the better.
>> 
>>> 
>>> Kevin N.
>>> 
>>> 
>>> On 11/17/12 5:25 AM, Hordur Thordarson wrote:
>>>> Eventually FB caved in and created a fully native app.
>>> 
>> 
>> 

Re: Flex 5 in haxe

[Alain Ekambi <ja...@gmail.com>]

Now not every company build apps at the scale of FaceBook.
For most of the case HTML5 mobile apps + PhoneGap(Cordova) are  pretty good.


2012/11/21 Hordur Thordarson <ho...@lausn.is>

> On 20.11.2012, at 22:14, Kevin Newman wrote:
>
> > Mark Zuckerberg also said very publicly that Facebook "burned" (his
> word) 2 years of development with HTML5, "We burned two years. That's
> really painful. Probably we will look back saying that is one of the
> *biggest mistakes* if not *the biggest strategic mistake* that we made." It
> was less of a "cave" and more of a fundamental shift in understanding (and
> a correct one).
>
> Agreed and that's really what I ment by "caved in", they just realized it
> was never going to be as good as a native app.  The problem with HTML5/JS
> as an app mechanism is that it just wasn't designed for that.  Some changes
> have been made to it in order to make it easier to write applications (as
> opposed to web sites which is a totally different thing) but it really
> isn't very good for that at all except maybe for small apps.  The JavaFX
> crowd is having the exact same discussion the Flex crowd is, except pretty
> much no one in the JavaFX crowd wants to deploy to HTML/JS.  They want
> JavaFX runtimes for mobile so that they can have one set of code and the
> same or very similar runtime everywhere (sound familiar ?).  And the
> community is actually working towards a solution that gives them that.  But
> Oracle, like Adobe, seems to have given into the "HTML5 for everything"
> rhetoric so they are at least currently not backing this.
>
> >
> > This is where Adobe has an opportunity with AIR, that they seem intent
> on failing to capitalize on (at least in their marketing narratives, and
> the signals the decision makers are sending out into the market place - the
> Flash engineers are doing pretty cool stuff with stage3D and whatnot).
>
> Yep, very frustrating that Adobe gave up on this vision because they had
> by far the strongest dev/deployment story out there with almost the best of
> everything. with Flash player or AIR for the desktop and AIR for mobile and
> almost single source for all the platforms (UI tweaks/diffs for
> phones/tablets obviously).  This is of course still possible, we just don't
> know how long it is going to last :-(  But while it works, I hope Apache
> Flex will continue to be maintained/improved in it's current shape.
>
> >
> > Anyway, Apache Flex doesn't need to wait for Adobe's higher-ups to
> figure it out - Flex can go HaXe, and have a multi-platform ubiquity story
> and an open source story to boot.
>
> Sure.  I have to say though that my clients don't really care if the tools
> I use are open source or not or whether the language I write in is
> ActionScript or Haxe or smth else.  They care about functionality,
> usability, cross-platformness and ease of deployment/updating of the
> resulting product, and they also want development to cost as little as
> possible, hence the less problems I have during dev and the less testing I
> have to do in multiple browsers or with multiple runtimes, the better.
>
> >
> > Kevin N.
> >
> >
> > On 11/17/12 5:25 AM, Hordur Thordarson wrote:
> >> Eventually FB caved in and created a fully native app.
> >
>
>

Re: Flex 5 in haxe

[Hordur Thordarson <ho...@lausn.is>]

On 21.11.2012, at 10:35, sébastien Paturel wrote:

> its more JS that need some improvements than HTML5. The dream solution i'd love to see happen would be to see JS evolve to something very close to what AS3 is. (AS3 is ECMAScript and is supposed to be the future of JS)

All the effort on JS currently is about making it faster, not so much about improving the language.  Which is why Google created Dart.  Also, even if an effort to modernize JS started now, it would take 5-10 years for it to go through development, standardization and browser implementation in such a way that it was available in a decent percentage of used browsers.  This is just an enormously slow process.

> 
> HTML5 is not mature enough to compete with flash player right now, but we have to think about future, and it will improve quite quick with all the hype around it.

Hmm, quick isn't the first word that comes to my mind...

> And even if you prefer flash player, there is our dreams, and there is reallity. And reallity is that Adobe is pushing HTML5 for web and giving up flash player for that. And we have to be prepared to a time where there will not be flash player only HTML5 everywhere. (in several years maybe, but will happen unless something drastically change)

Adobe has absolutely not given up Flash player for web allthough their focus has narrows.  They may give up on FP eventually but as far as I know they are currently pouring resources into a AS4, a new VM and Flash player updats.

I do agree that the possible eventuality of no Flash player needs to be considered, I'm just advocating that the current excellent platform we have isn't scrapped just because this and that could happen at some point in the future.

> 
> You talk about JavaFX and the discussion among them for the need of a plugin for what they want. But to achieve that they need Oracle. And they will conclude the same than Flex community: its only dream and we don't have the power to make it change. You can create a perfect VM in a plugin, but if you can't install it on devices because of political issues, then it worse nothing.

No, they don't want a plugin, they want smth like AIR, easy deployment of desktop and mobile apps on top of a single runtime.

I think we can all agree that there will never be another plugin like Flash player, that is with both the functionality and enormous reach.

> 
> "This is of course still possible, we just don't know how long it is going to last :-( But while it works, I hope Apache Flex will continue to be maintained/improved in it's current shape."
> It seems that we all say that as well. Theres no contradiction to maintain/improve the sdk in its current shape, AND start to prepare its future (in another shape if we don't have the choice to do differently)
> We need to figure out RIGHT NOW a path for the future of the SDK because :
> 1- it will take time to realise it and get back the same level of features we have today. especially if the only available solution is to rewrite it.
> 2- we need to give visibility for the future so that IT decision makers can choose Flex for long term projects. If we don't give this visibility, only short term projects will be able to use Flex. And it will be seens as "no future" technology in IT world.

Agreed.

> 
> 
> Le 21/11/2012 10:33, Hordur Thordarson a écrit :
>> On 20.11.2012, at 22:14, Kevin Newman wrote:
>> 
>>> Mark Zuckerberg also said very publicly that Facebook "burned" (his word) 2 years of development with HTML5, "We burned two years. That's really painful. Probably we will look back saying that is one of the *biggest mistakes* if not *the biggest strategic mistake* that we made." It was less of a "cave" and more of a fundamental shift in understanding (and a correct one).
>> Agreed and that's really what I ment by "caved in", they just realized it was never going to be as good as a native app.  The problem with HTML5/JS as an app mechanism is that it just wasn't designed for that.  Some changes have been made to it in order to make it easier to write applications (as opposed to web sites which is a totally different thing) but it really isn't very good for that at all except maybe for small apps.  The JavaFX crowd is having the exact same discussion the Flex crowd is, except pretty much no one in the JavaFX crowd wants to deploy to HTML/JS.  They want JavaFX runtimes for mobile so that they can have one set of code and the same or very similar runtime everywhere (sound familiar ?).  And the community is actually working towards a solution that gives them that.  But Oracle, like Adobe, seems to have given into the "HTML5 for everything" rhetoric so they are at least currently not backing this.
>> 
>>> This is where Adobe has an opportunity with AIR, that they seem intent on failing to capitalize on (at least in their marketing narratives, and the signals the decision makers are sending out into the market place - the Flash engineers are doing pretty cool stuff with stage3D and whatnot).
>> Yep, very frustrating that Adobe gave up on this vision because they had by far the strongest dev/deployment story out there with almost the best of everything. with Flash player or AIR for the desktop and AIR for mobile and almost single source for all the platforms (UI tweaks/diffs for phones/tablets obviously).  This is of course still possible, we just don't know how long it is going to last :-(  But while it works, I hope Apache Flex will continue to be maintained/improved in it's current shape.
>> 
>>> Anyway, Apache Flex doesn't need to wait for Adobe's higher-ups to figure it out - Flex can go HaXe, and have a multi-platform ubiquity story and an open source story to boot.
>> Sure.  I have to say though that my clients don't really care if the tools I use are open source or not or whether the language I write in is ActionScript or Haxe or smth else.  They care about functionality, usability, cross-platformness and ease of deployment/updating of the resulting product, and they also want development to cost as little as possible, hence the less problems I have during dev and the less testing I have to do in multiple browsers or with multiple runtimes, the better.
>> 
>>> Kevin N.
>>> 
>>> 
>>> On 11/17/12 5:25 AM, Hordur Thordarson wrote:
>>>> Eventually FB caved in and created a fully native app.
> 
> 

Re: Flex 5 in haxe

[sébastien Paturel <se...@gmail.com>]

its more JS that need some improvements than HTML5. The dream solution 
i'd love to see happen would be to see JS evolve to something very close 
to what AS3 is. (AS3 is ECMAScript and is supposed to be the future of JS)

HTML5 is not mature enough to compete with flash player right now, but 
we have to think about future, and it will improve quite quick with all 
the hype around it.
And even if you prefer flash player, there is our dreams, and there is 
reallity. And reallity is that Adobe is pushing HTML5 for web and giving 
up flash player for that. And we have to be prepared to a time where 
there will not be flash player only HTML5 everywhere. (in several years 
maybe, but will happen unless something drastically change)

You talk about JavaFX and the discussion among them for the need of a 
plugin for what they want. But to achieve that they need Oracle. And 
they will conclude the same than Flex community: its only dream and we 
don't have the power to make it change. You can create a perfect VM in a 
plugin, but if you can't install it on devices because of political 
issues, then it worse nothing.

"This is of course still possible, we just don't know how long it is 
going to last :-( But while it works, I hope Apache Flex will continue 
to be maintained/improved in it's current shape."
It seems that we all say that as well. Theres no contradiction to 
maintain/improve the sdk in its current shape, AND start to prepare its 
future (in another shape if we don't have the choice to do differently)
We need to figure out RIGHT NOW a path for the future of the SDK because :
1- it will take time to realise it and get back the same level of 
features we have today. especially if the only available solution is to 
rewrite it.
2- we need to give visibility for the future so that IT decision makers 
can choose Flex for long term projects. If we don't give this 
visibility, only short term projects will be able to use Flex. And it 
will be seens as "no future" technology in IT world.


Le 21/11/2012 10:33, Hordur Thordarson a écrit :
> On 20.11.2012, at 22:14, Kevin Newman wrote:
>
>> Mark Zuckerberg also said very publicly that Facebook "burned" (his word) 2 years of development with HTML5, "We burned two years. That's really painful. Probably we will look back saying that is one of the *biggest mistakes* if not *the biggest strategic mistake* that we made." It was less of a "cave" and more of a fundamental shift in understanding (and a correct one).
> Agreed and that's really what I ment by "caved in", they just realized it was never going to be as good as a native app.  The problem with HTML5/JS as an app mechanism is that it just wasn't designed for that.  Some changes have been made to it in order to make it easier to write applications (as opposed to web sites which is a totally different thing) but it really isn't very good for that at all except maybe for small apps.  The JavaFX crowd is having the exact same discussion the Flex crowd is, except pretty much no one in the JavaFX crowd wants to deploy to HTML/JS.  They want JavaFX runtimes for mobile so that they can have one set of code and the same or very similar runtime everywhere (sound familiar ?).  And the community is actually working towards a solution that gives them that.  But Oracle, like Adobe, seems to have given into the "HTML5 for everything" rhetoric so they are at least currently not backing this.
>
>> This is where Adobe has an opportunity with AIR, that they seem intent on failing to capitalize on (at least in their marketing narratives, and the signals the decision makers are sending out into the market place - the Flash engineers are doing pretty cool stuff with stage3D and whatnot).
> Yep, very frustrating that Adobe gave up on this vision because they had by far the strongest dev/deployment story out there with almost the best of everything. with Flash player or AIR for the desktop and AIR for mobile and almost single source for all the platforms (UI tweaks/diffs for phones/tablets obviously).  This is of course still possible, we just don't know how long it is going to last :-(  But while it works, I hope Apache Flex will continue to be maintained/improved in it's current shape.
>
>> Anyway, Apache Flex doesn't need to wait for Adobe's higher-ups to figure it out - Flex can go HaXe, and have a multi-platform ubiquity story and an open source story to boot.
> Sure.  I have to say though that my clients don't really care if the tools I use are open source or not or whether the language I write in is ActionScript or Haxe or smth else.  They care about functionality, usability, cross-platformness and ease of deployment/updating of the resulting product, and they also want development to cost as little as possible, hence the less problems I have during dev and the less testing I have to do in multiple browsers or with multiple runtimes, the better.
>
>> Kevin N.
>>
>>
>> On 11/17/12 5:25 AM, Hordur Thordarson wrote:
>>> Eventually FB caved in and created a fully native app.

Re: Flex 5 in haxe

[Hordur Thordarson <ho...@lausn.is>]

On 20.11.2012, at 22:14, Kevin Newman wrote:

> Mark Zuckerberg also said very publicly that Facebook "burned" (his word) 2 years of development with HTML5, "We burned two years. That's really painful. Probably we will look back saying that is one of the *biggest mistakes* if not *the biggest strategic mistake* that we made." It was less of a "cave" and more of a fundamental shift in understanding (and a correct one).

Agreed and that's really what I ment by "caved in", they just realized it was never going to be as good as a native app.  The problem with HTML5/JS as an app mechanism is that it just wasn't designed for that.  Some changes have been made to it in order to make it easier to write applications (as opposed to web sites which is a totally different thing) but it really isn't very good for that at all except maybe for small apps.  The JavaFX crowd is having the exact same discussion the Flex crowd is, except pretty much no one in the JavaFX crowd wants to deploy to HTML/JS.  They want JavaFX runtimes for mobile so that they can have one set of code and the same or very similar runtime everywhere (sound familiar ?).  And the community is actually working towards a solution that gives them that.  But Oracle, like Adobe, seems to have given into the "HTML5 for everything" rhetoric so they are at least currently not backing this.

> 
> This is where Adobe has an opportunity with AIR, that they seem intent on failing to capitalize on (at least in their marketing narratives, and the signals the decision makers are sending out into the market place - the Flash engineers are doing pretty cool stuff with stage3D and whatnot).

Yep, very frustrating that Adobe gave up on this vision because they had by far the strongest dev/deployment story out there with almost the best of everything. with Flash player or AIR for the desktop and AIR for mobile and almost single source for all the platforms (UI tweaks/diffs for phones/tablets obviously).  This is of course still possible, we just don't know how long it is going to last :-(  But while it works, I hope Apache Flex will continue to be maintained/improved in it's current shape.

> 
> Anyway, Apache Flex doesn't need to wait for Adobe's higher-ups to figure it out - Flex can go HaXe, and have a multi-platform ubiquity story and an open source story to boot.

Sure.  I have to say though that my clients don't really care if the tools I use are open source or not or whether the language I write in is ActionScript or Haxe or smth else.  They care about functionality, usability, cross-platformness and ease of deployment/updating of the resulting product, and they also want development to cost as little as possible, hence the less problems I have during dev and the less testing I have to do in multiple browsers or with multiple runtimes, the better.

> 
> Kevin N.
> 
> 
> On 11/17/12 5:25 AM, Hordur Thordarson wrote:
>> Eventually FB caved in and created a fully native app.
> 

Re: Flex 5 in haxe

[Kevin Newman <Ca...@unFocus.com>]

Mark Zuckerberg also said very publicly that Facebook "burned" (his 
word) 2 years of development with HTML5, "We burned two years. That's 
really painful. Probably we will look back saying that is one of the 
*biggest mistakes* if not *the biggest strategic mistake* that we made." 
It was less of a "cave" and more of a fundamental shift in understanding 
(and a correct one).

This is where Adobe has an opportunity with AIR, that they seem intent 
on failing to capitalize on (at least in their marketing narratives, and 
the signals the decision makers are sending out into the market place - 
the Flash engineers are doing pretty cool stuff with stage3D and whatnot).

Anyway, Apache Flex doesn't need to wait for Adobe's higher-ups to 
figure it out - Flex can go HaXe, and have a multi-platform ubiquity 
story and an open source story to boot.

Kevin N.


On 11/17/12 5:25 AM, Hordur Thordarson wrote:
> Eventually FB caved in and created a fully native app.

Re: Flex 5 in haxe

[Hordur Thordarson <ho...@lausn.is>]

On 17.11.2012, at 03:32, Jeffry Houser wrote:

> On 11/16/2012 10:25 PM, Hordur Xtest2 Imap wrote:
>> Also, when Steve J started his crusade against Flash on the iPhone, part of the argument was HTML5 is so good you can do anything with that, that you can do in Flash. Fast forward a few years and the reality is almost all mobile apps are native apps, not web apps. Some think that will change eventually, I don't.
> 
>  A very common criticism of mobile apps and Native App stores is that the bulk of apps are just a "Wrapper" around HTML / web sites. Now; I don't use, or know about, enough apps to be able to gauge the truthfulness of such criticism.  But, I have heard of quite a few approaches to make native apps using HTML5.

If I remember correctly, the FaceBook app on iOS was exactly such a case, it was an app but underneath was either fully web based bundled as an app or at least heavily based on web tech.  Users complained about it for a long time as it was glacially slow, even on the latest iPhones.  Eventually FB caved in and created a fully native app.

> 
> 
> -- 
> Jeffry Houser
> Technical Entrepreneur
> 203-379-0773
> --
> http://www.flextras.com?c=104
> UI Flex Components: Tested! Supported! Ready!
> --
> http://www.theflexshow.com
> http://www.jeffryhouser.com
> http://www.asktheflexpert.com
> --
> Part of the DotComIt Brain Trust
> 

Re: Flex 5 in haxe

[Jeffry Houser <je...@dot-com-it.com>]

On 11/16/2012 10:25 PM, Hordur Xtest2 Imap wrote:
> Also, when Steve J started his crusade against Flash on the iPhone, part of the argument was HTML5 is so good you can do anything with that, that you can do in Flash. Fast forward a few years and the reality is almost all mobile apps are native apps, not web apps. Some think that will change eventually, I don't.

   A very common criticism of mobile apps and Native App stores is that 
the bulk of apps are just a "Wrapper" around HTML / web sites. Now; I 
don't use, or know about, enough apps to be able to gauge the 
truthfulness of such criticism.  But, I have heard of quite a few 
approaches to make native apps using HTML5.


-- 
Jeffry Houser
Technical Entrepreneur
203-379-0773
--
http://www.flextras.com?c=104
UI Flex Components: Tested! Supported! Ready!
--
http://www.theflexshow.com
http://www.jeffryhouser.com
http://www.asktheflexpert.com
--
Part of the DotComIt Brain Trust

Re: Flex 5 in haxe

[Hordur Xtest2 Imap <ho...@lausn.is>]

Well I dont agree with this.

If we narrow down the discussion a bit and just talk about Flex apps in the browser, then as far as I know there are only two usable ways of running apps there, via Flash player or as HTML/JS. One way depends on Adobe technology and the other on the implementation of HTML/JS by several browser vendors who arent always the best of buddies so to speak. One tech is tried and tested and just plain works pretty well, the other one is undergoing heavy development and has a long way to go before reaching the same maturity as the first one.

There has been talk of performance problems with Flex/AS3 and allthough I have not had such problems myself I'm sure there are some. But do people seriously think that these problems will get better by compiling to Javascript? Have you heard of Dart? It is the language that Google created as a JS replacement because JS sucks for anything other than small projects. Also, when Steve J started his crusade against Flash on the iPhone, part of the argument was HTML5 is so good you can do anything with that, that you can do in Flash. Fast forward a few years and the reality is almost all mobile apps are native apps, not web apps. Some think that will change eventually, I don't. 

So while the "HTML5 can do it all and Flash player is a bug ridden, insecure pos" rhetoric is annoying, I think most of us know better.

I certainly have situations where a potential client will not put a Flash based app of mine into their website, just because it is Flash based rather than HTML. But I have many more situations where the client either doesn't care or stops caring after trying the app. Because Flex sells itself when given a chance, and in the end all the client cares about is how much it costs to write the app and how well it works and Flex in Flash player is a winner in both these categories compared with most everything else.

So, while I agree that for Apache Flex to be dependant on Adobe VM tech is not ideal, I think it is better than being dependant on the browser makers' HTML/JS efforts.

Finally just to answer Gordon's question about Flex work, I have plenty of Flex work and if anything it is increasing.

Sent from my iPhone

On 17.11.2012, at 00:01, Joan Llenas Masó <jo...@garnetworks.com> wrote:

> We could discuss for hours about the technical aspects of the Flash Player
> and how well Flex integrates with it, however there's one thing that is not
> going to change:
> - Customer Perception.
> 
> This very fact is key to decide the future of Flex because nobody wants to
> use a technology that no one wants to "buy".
> 
> Statistics have spoken for a few years already:
> - Google trends:
> http://www.google.com/trends/explore#q=%22adobe%20flex%22%2C%20%22javafx%22%2C%20HTML5%2C%20RIA&cmpt=q
> - Indeed:
> http://www.indeed.com/jobtrends?q=%22adobe+flex%22%2C+javafx%2C+html5%2C+ria&l=
> 
> I have been working with Flex since 1.5 and demand has lowered drastically
> within the last 3 years.
> 
> The message is loud and clear:
> - FLASH PLAYER IS FOR GAMES.
> - ADOBE IS NOT COMMITED TO FLEX ANYMORE.
> - HTML5 DOES THE SAME AS FLEX.
> 
> We know it.
> So, in order to make Flex a sucessful technology we have to decouple it
> from the Flash Player.
> It doesn't matter if we do that via Haxe, C# or AS3. We must prove to our
> customers that Flex is a technical solution that has embraced Flash Player,
> but is so good and so well known that we can port it to other runtimes
> without loosing any of its advantages.
> As I said in another thread Flex to me is:
> 1. cross browser/platform
> 2. MXML
> 3. Modularity
> 4. Spark architecture
> 
> I see all those 4 dots satisfied with Flash player, HTML5 and even JavaFX.
> It happens that Haxe satisfies those 3 runtimes at once. So for me it's the
> 1st choice at this moment.
> 
> 
> Cheers
> 
> 
> On Sat, Nov 17, 2012 at 12:29 AM, Nils Dupont <ni...@gmail.com>wrote:
> 
>> @Gordon
>> ActionScript 2.0 was introduced in 2004 and is still supported in Flash
>> Player.
>> As you say, AS3 / AVM2 will not disappear from one day to the other, and
>> Adobe, also, was clear on this point.
>> Maybe an average Flex application just doesn't need the new features that
>> will be introduced in AS4 (gaming / GPU oriented features I can imagine)?
>> Maybe AS3 is solid and mature enough for an average Flex application?
>> Maybe here Adobe should communicate in a better way: AS4 will be the
>> language dedicated to game development, AS3 will be the language dedicated
>> to business application development.
>> I think companies will have more and more interest in Flex if they see that
>> new components are added very often by the community, that bugs are
>> corrected in a decent delay by the community, that they can have a quick
>> support on any point from an active community.
>> For "mobile" oriented applications (smartphones / tablets), I really think
>> that there is no "perfect" solution at the moment, except doing pure native
>> applications for each OS. I would say that Flex is not so bad for doing an
>> average business application on mobile. There are performance issues, of
>> course, but I think in a near future (mobile devices are more and more
>> powerful in terms of CPU), and with some optimisations on the framework
>> itself, Flex can achieve a very decent work.
>> As far as I know, there are 2 clear performance issues for Flex Mobile
>> applications :
>> 1) Big Lists + complex itemRenderers
>> 2) Transitions between views
>> Concerning point 1) it is very easy to implement a HTML List with
>> StageWebView and to interact with it with Javascript, if ever the list is
>> too big to be displayed properly by Flex List component (for example on
>> last Ipad Retina screens). It would be maybe interesting to wrap this
>> functionality in a new "StageWebList" component.
>> Concerning point 2), there are more and more applications that don't use
>> these transitions anymore (e.g. Twitter application) and even HTML5/JS
>> applications perform very poorly on most devices. I even tested
>> Starling+Feathers UI and the performance is also not so good compared to
>> native applications list components.
>> Except these 2 points, Flex is really not so bad to deploy business
>> applications on mobile devices. And if we have to use captive runtime in
>> the future, it is not a big deal in my opinion.
>> To conclude, I am currently working on a big project done with Flex (mostly
>> dedicated to desktop), and I do it with Flex because it would be a
>> nightmare to do it with HTML5/Javascript, in the current state of these
>> technologies (technologies that I know very well).
>> I don't care to be able to target GPU for this project, I just need a solid
>> and mature framework, and I'm very happy that Apache Flex is here now,
>> because it gives me the hope that if I encounter bugs, there will be an
>> active community to help me to correct them or to find workarounds with a
>> shorter delay than before.
>> 
>> Nils
>> 
>> 
>> 
>> 
>> 2012/11/16 Alain Ekambi <ja...@gmail.com>
>> 
>>> @Gordon
>>> We actually see an increasing interest in Flex/AIR coming for our
>>> customers.
>>> With the small team that we have we actualy cant keep up with the
>> requests.
>>> But i have to say we have a different  approach to Flex development tho.
>>> 
>>> 
>>> 2012/11/16 Alex Harui <ah...@adobe.com>
>>> 
>>>> 
>>>> 
>>>> 
>>>> On 11/16/12 1:52 PM, "Fréderic Cox" <co...@gmail.com> wrote:
>>>> 
>>>>> I'm glad Alex is here because I believe he does not only have
>>>>> the experience but also great ideas where Flex should be headed. And
>> he
>>>>> might have been blocked previously by business decisions but now can
>>> take
>>>>> Flex to a even higher level.
>>>>> 
>>>> Keep in mind that I'm the biggest proponent of the full re-write.  We
>> may
>>>> still find a few performance mistakes in the current code (like the
>> Chart
>>>> styles init that just got fixed), but really, some very smart people
>> have
>>>> spent a lot of time on the current code and haven't found any easy
>> wins.
>>>> IMO, the framework is slow because lots of code is running just in
>> case.
>>>> This is especially true for mobile apps where you have the most
>>> constrained
>>>> runtime environment.  The issue that came in today on the users list
>>> about
>>>> slow List performance I'm sure is in part due to TextLine being a bit
>>>> slower, but probably more due to lots of other code running as well.
>>>> 
>>>> Plus, as many have recently said, the intertwined code we currently
>> have
>>>> makes it hard for the volunteer to be successful in their spare time.
>>>> 
>>>> I tried the big refactor and it was too difficult for me, but one of
>> the
>>>> main difficulties was the fact that there was lots of other development
>>>> going on in the trunk at the same time and keeping my branch running
>> was
>>>> nearly impossible.  It could be that there won't be as much active
>>>> development in Apache Flex and a refactor branch will be manageable,
>> but
>>>> the
>>>> other problem you run into is that every line of code is needed for
>> some
>>>> reason at some point, and you tend to start leaving code in.
>>>> 
>>>> Starting over definitely has its risks, but I think it will have the
>> best
>>>> outcome.  It won't make 100% parity ever and I'd shoot for 80% over two
>>> or
>>>> three years.  But it will be designed to port to other platforms, and
>> be
>>>> modular so the volunteer has a chance of making a difference.
>>>> 
>>>> --
>>>> Alex Harui
>>>> Flex SDK Team
>>>> Adobe Systems, Inc.
>>>> http://blogs.adobe.com/aharui
>>>> 
>>>> 
>>> 
>> 

Re: Flex 5 in haxe

[Joan Llenas Masó <jo...@garnetworks.com>]

We could discuss for hours about the technical aspects of the Flash Player
and how well Flex integrates with it, however there's one thing that is not
going to change:
- Customer Perception.

This very fact is key to decide the future of Flex because nobody wants to
use a technology that no one wants to "buy".

Statistics have spoken for a few years already:
- Google trends:
http://www.google.com/trends/explore#q=%22adobe%20flex%22%2C%20%22javafx%22%2C%20HTML5%2C%20RIA&cmpt=q
- Indeed:
http://www.indeed.com/jobtrends?q=%22adobe+flex%22%2C+javafx%2C+html5%2C+ria&l=

I have been working with Flex since 1.5 and demand has lowered drastically
 within the last 3 years.

The message is loud and clear:
- FLASH PLAYER IS FOR GAMES.
- ADOBE IS NOT COMMITED TO FLEX ANYMORE.
- HTML5 DOES THE SAME AS FLEX.

We know it.
So, in order to make Flex a sucessful technology we have to decouple it
from the Flash Player.
It doesn't matter if we do that via Haxe, C# or AS3. We must prove to our
customers that Flex is a technical solution that has embraced Flash Player,
but is so good and so well known that we can port it to other runtimes
without loosing any of its advantages.
As I said in another thread Flex to me is:
1. cross browser/platform
2. MXML
3. Modularity
4. Spark architecture

I see all those 4 dots satisfied with Flash player, HTML5 and even JavaFX.
It happens that Haxe satisfies those 3 runtimes at once. So for me it's the
1st choice at this moment.


Cheers


On Sat, Nov 17, 2012 at 12:29 AM, Nils Dupont <ni...@gmail.com>wrote:

> @Gordon
> ActionScript 2.0 was introduced in 2004 and is still supported in Flash
> Player.
> As you say, AS3 / AVM2 will not disappear from one day to the other, and
> Adobe, also, was clear on this point.
> Maybe an average Flex application just doesn't need the new features that
> will be introduced in AS4 (gaming / GPU oriented features I can imagine)?
> Maybe AS3 is solid and mature enough for an average Flex application?
> Maybe here Adobe should communicate in a better way: AS4 will be the
> language dedicated to game development, AS3 will be the language dedicated
> to business application development.
> I think companies will have more and more interest in Flex if they see that
> new components are added very often by the community, that bugs are
> corrected in a decent delay by the community, that they can have a quick
> support on any point from an active community.
> For "mobile" oriented applications (smartphones / tablets), I really think
> that there is no "perfect" solution at the moment, except doing pure native
> applications for each OS. I would say that Flex is not so bad for doing an
> average business application on mobile. There are performance issues, of
> course, but I think in a near future (mobile devices are more and more
> powerful in terms of CPU), and with some optimisations on the framework
> itself, Flex can achieve a very decent work.
> As far as I know, there are 2 clear performance issues for Flex Mobile
> applications :
> 1) Big Lists + complex itemRenderers
> 2) Transitions between views
> Concerning point 1) it is very easy to implement a HTML List with
> StageWebView and to interact with it with Javascript, if ever the list is
> too big to be displayed properly by Flex List component (for example on
> last Ipad Retina screens). It would be maybe interesting to wrap this
> functionality in a new "StageWebList" component.
>  Concerning point 2), there are more and more applications that don't use
> these transitions anymore (e.g. Twitter application) and even HTML5/JS
> applications perform very poorly on most devices. I even tested
> Starling+Feathers UI and the performance is also not so good compared to
> native applications list components.
> Except these 2 points, Flex is really not so bad to deploy business
> applications on mobile devices. And if we have to use captive runtime in
> the future, it is not a big deal in my opinion.
> To conclude, I am currently working on a big project done with Flex (mostly
> dedicated to desktop), and I do it with Flex because it would be a
> nightmare to do it with HTML5/Javascript, in the current state of these
> technologies (technologies that I know very well).
> I don't care to be able to target GPU for this project, I just need a solid
> and mature framework, and I'm very happy that Apache Flex is here now,
> because it gives me the hope that if I encounter bugs, there will be an
> active community to help me to correct them or to find workarounds with a
> shorter delay than before.
>
> Nils
>
>
>
>
> 2012/11/16 Alain Ekambi <ja...@gmail.com>
>
> > @Gordon
> > We actually see an increasing interest in Flex/AIR coming for our
> > customers.
> > With the small team that we have we actualy cant keep up with the
> requests.
> > But i have to say we have a different  approach to Flex development tho.
> >
> >
> > 2012/11/16 Alex Harui <ah...@adobe.com>
> >
> > >
> > >
> > >
> > > On 11/16/12 1:52 PM, "Fréderic Cox" <co...@gmail.com> wrote:
> > >
> > > > I'm glad Alex is here because I believe he does not only have
> > > > the experience but also great ideas where Flex should be headed. And
> he
> > > > might have been blocked previously by business decisions but now can
> > take
> > > > Flex to a even higher level.
> > > >
> > > Keep in mind that I'm the biggest proponent of the full re-write.  We
> may
> > > still find a few performance mistakes in the current code (like the
> Chart
> > > styles init that just got fixed), but really, some very smart people
> have
> > > spent a lot of time on the current code and haven't found any easy
> wins.
> > > IMO, the framework is slow because lots of code is running just in
> case.
> > > This is especially true for mobile apps where you have the most
> > constrained
> > > runtime environment.  The issue that came in today on the users list
> > about
> > > slow List performance I'm sure is in part due to TextLine being a bit
> > > slower, but probably more due to lots of other code running as well.
> > >
> > > Plus, as many have recently said, the intertwined code we currently
> have
> > > makes it hard for the volunteer to be successful in their spare time.
> > >
> > > I tried the big refactor and it was too difficult for me, but one of
> the
> > > main difficulties was the fact that there was lots of other development
> > > going on in the trunk at the same time and keeping my branch running
> was
> > > nearly impossible.  It could be that there won't be as much active
> > > development in Apache Flex and a refactor branch will be manageable,
> but
> > > the
> > > other problem you run into is that every line of code is needed for
> some
> > > reason at some point, and you tend to start leaving code in.
> > >
> > > Starting over definitely has its risks, but I think it will have the
> best
> > > outcome.  It won't make 100% parity ever and I'd shoot for 80% over two
> > or
> > > three years.  But it will be designed to port to other platforms, and
> be
> > > modular so the volunteer has a chance of making a difference.
> > >
> > > --
> > > Alex Harui
> > > Flex SDK Team
> > > Adobe Systems, Inc.
> > > http://blogs.adobe.com/aharui
> > >
> > >
> >
>

Re: Flex 5 in haxe

[Carlos Rovira <ca...@codeoscopic.com>]

Just to say that I talked with Nicolas Canesse and he would help and
support the idea of "Flex+haxe" although as he says he can't lead the
effort since he's not a Flex developer. The intention is that Haxe will
support new AVM from Adobe as expected, so all the work in this area will
be more stable if based on Haxe.

As someone post here today, he still supports the idea behind his open
letter to this community:

http://ncannasse.fr/blog/open_letter_to_flex_community

Best,

Carlos

Re: Flex 5 in haxe

[Nils Dupont <ni...@gmail.com>]

@Gordon
ActionScript 2.0 was introduced in 2004 and is still supported in Flash
Player.
As you say, AS3 / AVM2 will not disappear from one day to the other, and
Adobe, also, was clear on this point.
Maybe an average Flex application just doesn't need the new features that
will be introduced in AS4 (gaming / GPU oriented features I can imagine)?
Maybe AS3 is solid and mature enough for an average Flex application?
Maybe here Adobe should communicate in a better way: AS4 will be the
language dedicated to game development, AS3 will be the language dedicated
to business application development.
I think companies will have more and more interest in Flex if they see that
new components are added very often by the community, that bugs are
corrected in a decent delay by the community, that they can have a quick
support on any point from an active community.
For "mobile" oriented applications (smartphones / tablets), I really think
that there is no "perfect" solution at the moment, except doing pure native
applications for each OS. I would say that Flex is not so bad for doing an
average business application on mobile. There are performance issues, of
course, but I think in a near future (mobile devices are more and more
powerful in terms of CPU), and with some optimisations on the framework
itself, Flex can achieve a very decent work.
As far as I know, there are 2 clear performance issues for Flex Mobile
applications :
1) Big Lists + complex itemRenderers
2) Transitions between views
Concerning point 1) it is very easy to implement a HTML List with
StageWebView and to interact with it with Javascript, if ever the list is
too big to be displayed properly by Flex List component (for example on
last Ipad Retina screens). It would be maybe interesting to wrap this
functionality in a new "StageWebList" component.
 Concerning point 2), there are more and more applications that don't use
these transitions anymore (e.g. Twitter application) and even HTML5/JS
applications perform very poorly on most devices. I even tested
Starling+Feathers UI and the performance is also not so good compared to
native applications list components.
Except these 2 points, Flex is really not so bad to deploy business
applications on mobile devices. And if we have to use captive runtime in
the future, it is not a big deal in my opinion.
To conclude, I am currently working on a big project done with Flex (mostly
dedicated to desktop), and I do it with Flex because it would be a
nightmare to do it with HTML5/Javascript, in the current state of these
technologies (technologies that I know very well).
I don't care to be able to target GPU for this project, I just need a solid
and mature framework, and I'm very happy that Apache Flex is here now,
because it gives me the hope that if I encounter bugs, there will be an
active community to help me to correct them or to find workarounds with a
shorter delay than before.

Nils




2012/11/16 Alain Ekambi <ja...@gmail.com>

> @Gordon
> We actually see an increasing interest in Flex/AIR coming for our
> customers.
> With the small team that we have we actualy cant keep up with the requests.
> But i have to say we have a different  approach to Flex development tho.
>
>
> 2012/11/16 Alex Harui <ah...@adobe.com>
>
> >
> >
> >
> > On 11/16/12 1:52 PM, "Fréderic Cox" <co...@gmail.com> wrote:
> >
> > > I'm glad Alex is here because I believe he does not only have
> > > the experience but also great ideas where Flex should be headed. And he
> > > might have been blocked previously by business decisions but now can
> take
> > > Flex to a even higher level.
> > >
> > Keep in mind that I'm the biggest proponent of the full re-write.  We may
> > still find a few performance mistakes in the current code (like the Chart
> > styles init that just got fixed), but really, some very smart people have
> > spent a lot of time on the current code and haven't found any easy wins.
> > IMO, the framework is slow because lots of code is running just in case.
> > This is especially true for mobile apps where you have the most
> constrained
> > runtime environment.  The issue that came in today on the users list
> about
> > slow List performance I'm sure is in part due to TextLine being a bit
> > slower, but probably more due to lots of other code running as well.
> >
> > Plus, as many have recently said, the intertwined code we currently have
> > makes it hard for the volunteer to be successful in their spare time.
> >
> > I tried the big refactor and it was too difficult for me, but one of the
> > main difficulties was the fact that there was lots of other development
> > going on in the trunk at the same time and keeping my branch running was
> > nearly impossible.  It could be that there won't be as much active
> > development in Apache Flex and a refactor branch will be manageable, but
> > the
> > other problem you run into is that every line of code is needed for some
> > reason at some point, and you tend to start leaving code in.
> >
> > Starting over definitely has its risks, but I think it will have the best
> > outcome.  It won't make 100% parity ever and I'd shoot for 80% over two
> or
> > three years.  But it will be designed to port to other platforms, and be
> > modular so the volunteer has a chance of making a difference.
> >
> > --
> > Alex Harui
> > Flex SDK Team
> > Adobe Systems, Inc.
> > http://blogs.adobe.com/aharui
> >
> >
>

Re: Flex 5 in haxe

[Alain Ekambi <ja...@gmail.com>]

What we do is calling Flash/Flex APis  through a custom FABridge (That we
are planing to contribuate soon). So at the  of the day it still a
Flash/Flex application but not written in ActionScript/MXML.
You can have a look at a demo here : http://flex4j.appspot.com/

For AIR we wrapped the AIR JS API  with GWT JSNI(JavaScript Native
Interface)

This has helped us bring more Java devs to the Flash platform then we used
to do with  the MXML/AS3 approach.



2012/11/16 Gordon Smith <go...@adobe.com>

> Did you use some HTML/JS implementation of native Flash/AIR APIs such as
> Sprite?
>
> - Gordon
>
> -----Original Message-----
> From: Alain Ekambi [mailto:jazzmatadazz@gmail.com]
> Sent: Friday, November 16, 2012 2:43 PM
> To: flex-dev@incubator.apache.org
> Subject: Re: Flex 5 in haxe
>
> We dont use ActionScript/MXML at all.
>
> ActionScript/MXML  were not scaling  for our customers(most of them use
> J2EE) so we  exported the Flash/AIR/Flex API to Java using GWT giving
> their devs the ability to write Flex using the tools they are familiar with.
>
>
>
>
> 2012/11/16 Gordon Smith <go...@adobe.com>
>
> > > we have a different  approach to Flex development
> >
> > Can you elaborate on that a little?
> >
> > -----Original Message-----
> > From: Alain Ekambi [mailto:jazzmatadazz@gmail.com]
> > Sent: Friday, November 16, 2012 2:22 PM
> > To: flex-dev@incubator.apache.org
> > Subject: Re: Flex 5 in haxe
> >
> > @Gordon
> > We actually see an increasing interest in Flex/AIR coming for our
> > customers.
> > With the small team that we have we actualy cant keep up with the
> requests.
> > But i have to say we have a different  approach to Flex development tho.
> >
> >
> > 2012/11/16 Alex Harui <ah...@adobe.com>
> >
> > >
> > >
> > >
> > > On 11/16/12 1:52 PM, "Fréderic Cox" <co...@gmail.com> wrote:
> > >
> > > > I'm glad Alex is here because I believe he does not only have the
> > > > experience but also great ideas where Flex should be headed. And
> > > > he might have been blocked previously by business decisions but
> > > > now can take Flex to a even higher level.
> > > >
> > > Keep in mind that I'm the biggest proponent of the full re-write.
> > > We may still find a few performance mistakes in the current code
> > > (like the Chart styles init that just got fixed), but really, some
> > > very smart people have spent a lot of time on the current code and
> > > haven't
> > found any easy wins.
> > > IMO, the framework is slow because lots of code is running just in
> case.
> > > This is especially true for mobile apps where you have the most
> > > constrained runtime environment.  The issue that came in today on
> > > the users list about slow List performance I'm sure is in part due
> > > to TextLine being a bit slower, but probably more due to lots of
> > > other code
> > running as well.
> > >
> > > Plus, as many have recently said, the intertwined code we currently
> > > have makes it hard for the volunteer to be successful in their spare
> > time.
> > >
> > > I tried the big refactor and it was too difficult for me, but one of
> > > the main difficulties was the fact that there was lots of other
> > > development going on in the trunk at the same time and keeping my
> > > branch running was nearly impossible.  It could be that there won't
> > > be as much active development in Apache Flex and a refactor branch
> > > will be manageable, but the other problem you run into is that every
> > > line of code is needed for some reason at some point, and you tend
> > > to start leaving code in.
> > >
> > > Starting over definitely has its risks, but I think it will have the
> > > best outcome.  It won't make 100% parity ever and I'd shoot for 80%
> > > over two or three years.  But it will be designed to port to other
> > > platforms, and be modular so the volunteer has a chance of making a
> > difference.
> > >
> > > --
> > > Alex Harui
> > > Flex SDK Team
> > > Adobe Systems, Inc.
> > > http://blogs.adobe.com/aharui
> > >
> > >
> >
>

RE: Flex 5 in haxe

[Gordon Smith <go...@adobe.com>]

Did you use some HTML/JS implementation of native Flash/AIR APIs such as Sprite?

- Gordon

-----Original Message-----
From: Alain Ekambi [mailto:jazzmatadazz@gmail.com] 
Sent: Friday, November 16, 2012 2:43 PM
To: flex-dev@incubator.apache.org
Subject: Re: Flex 5 in haxe

We dont use ActionScript/MXML at all.

ActionScript/MXML  were not scaling  for our customers(most of them use
J2EE) so we  exported the Flash/AIR/Flex API to Java using GWT giving their devs the ability to write Flex using the tools they are familiar with.




2012/11/16 Gordon Smith <go...@adobe.com>

> > we have a different  approach to Flex development
>
> Can you elaborate on that a little?
>
> -----Original Message-----
> From: Alain Ekambi [mailto:jazzmatadazz@gmail.com]
> Sent: Friday, November 16, 2012 2:22 PM
> To: flex-dev@incubator.apache.org
> Subject: Re: Flex 5 in haxe
>
> @Gordon
> We actually see an increasing interest in Flex/AIR coming for our 
> customers.
> With the small team that we have we actualy cant keep up with the requests.
> But i have to say we have a different  approach to Flex development tho.
>
>
> 2012/11/16 Alex Harui <ah...@adobe.com>
>
> >
> >
> >
> > On 11/16/12 1:52 PM, "Fréderic Cox" <co...@gmail.com> wrote:
> >
> > > I'm glad Alex is here because I believe he does not only have the 
> > > experience but also great ideas where Flex should be headed. And 
> > > he might have been blocked previously by business decisions but 
> > > now can take Flex to a even higher level.
> > >
> > Keep in mind that I'm the biggest proponent of the full re-write.  
> > We may still find a few performance mistakes in the current code 
> > (like the Chart styles init that just got fixed), but really, some 
> > very smart people have spent a lot of time on the current code and 
> > haven't
> found any easy wins.
> > IMO, the framework is slow because lots of code is running just in case.
> > This is especially true for mobile apps where you have the most 
> > constrained runtime environment.  The issue that came in today on 
> > the users list about slow List performance I'm sure is in part due 
> > to TextLine being a bit slower, but probably more due to lots of 
> > other code
> running as well.
> >
> > Plus, as many have recently said, the intertwined code we currently 
> > have makes it hard for the volunteer to be successful in their spare
> time.
> >
> > I tried the big refactor and it was too difficult for me, but one of 
> > the main difficulties was the fact that there was lots of other 
> > development going on in the trunk at the same time and keeping my 
> > branch running was nearly impossible.  It could be that there won't 
> > be as much active development in Apache Flex and a refactor branch 
> > will be manageable, but the other problem you run into is that every 
> > line of code is needed for some reason at some point, and you tend 
> > to start leaving code in.
> >
> > Starting over definitely has its risks, but I think it will have the 
> > best outcome.  It won't make 100% parity ever and I'd shoot for 80% 
> > over two or three years.  But it will be designed to port to other 
> > platforms, and be modular so the volunteer has a chance of making a
> difference.
> >
> > --
> > Alex Harui
> > Flex SDK Team
> > Adobe Systems, Inc.
> > http://blogs.adobe.com/aharui
> >
> >
>

Re: Flex 5 in haxe

[Alain Ekambi <ja...@gmail.com>]

We dont use ActionScript/MXML at all.

ActionScript/MXML  were not scaling  for our customers(most of them use
J2EE) so we  exported the Flash/AIR/Flex API to Java using GWT giving their
devs the ability to write Flex using the tools they are familiar with.




2012/11/16 Gordon Smith <go...@adobe.com>

> > we have a different  approach to Flex development
>
> Can you elaborate on that a little?
>
> -----Original Message-----
> From: Alain Ekambi [mailto:jazzmatadazz@gmail.com]
> Sent: Friday, November 16, 2012 2:22 PM
> To: flex-dev@incubator.apache.org
> Subject: Re: Flex 5 in haxe
>
> @Gordon
> We actually see an increasing interest in Flex/AIR coming for our
> customers.
> With the small team that we have we actualy cant keep up with the requests.
> But i have to say we have a different  approach to Flex development tho.
>
>
> 2012/11/16 Alex Harui <ah...@adobe.com>
>
> >
> >
> >
> > On 11/16/12 1:52 PM, "Fréderic Cox" <co...@gmail.com> wrote:
> >
> > > I'm glad Alex is here because I believe he does not only have the
> > > experience but also great ideas where Flex should be headed. And he
> > > might have been blocked previously by business decisions but now can
> > > take Flex to a even higher level.
> > >
> > Keep in mind that I'm the biggest proponent of the full re-write.  We
> > may still find a few performance mistakes in the current code (like
> > the Chart styles init that just got fixed), but really, some very
> > smart people have spent a lot of time on the current code and haven't
> found any easy wins.
> > IMO, the framework is slow because lots of code is running just in case.
> > This is especially true for mobile apps where you have the most
> > constrained runtime environment.  The issue that came in today on the
> > users list about slow List performance I'm sure is in part due to
> > TextLine being a bit slower, but probably more due to lots of other code
> running as well.
> >
> > Plus, as many have recently said, the intertwined code we currently
> > have makes it hard for the volunteer to be successful in their spare
> time.
> >
> > I tried the big refactor and it was too difficult for me, but one of
> > the main difficulties was the fact that there was lots of other
> > development going on in the trunk at the same time and keeping my
> > branch running was nearly impossible.  It could be that there won't be
> > as much active development in Apache Flex and a refactor branch will
> > be manageable, but the other problem you run into is that every line
> > of code is needed for some reason at some point, and you tend to start
> > leaving code in.
> >
> > Starting over definitely has its risks, but I think it will have the
> > best outcome.  It won't make 100% parity ever and I'd shoot for 80%
> > over two or three years.  But it will be designed to port to other
> > platforms, and be modular so the volunteer has a chance of making a
> difference.
> >
> > --
> > Alex Harui
> > Flex SDK Team
> > Adobe Systems, Inc.
> > http://blogs.adobe.com/aharui
> >
> >
>

RE: Flex 5 in haxe

[Hugo Miguel Pereira Matinho <hu...@gmail.com>]

Hi all we do also have a slash of momentum building air and mobile apps for
our customers and more and more customers ask us to deliver in flex/air i
believe the framework does have its quirks but nontheless it's still the
best framework to work with and lets be fair HTML5 is not an option and i
can pretty much vouch for that with a big project that went bad because of
it
No dia 16/11/2012 22:33, "Gordon Smith" <go...@adobe.com> escreveu:

> > we have a different  approach to Flex development
>
> Can you elaborate on that a little?
>
> -----Original Message-----
> From: Alain Ekambi [mailto:jazzmatadazz@gmail.com]
> Sent: Friday, November 16, 2012 2:22 PM
> To: flex-dev@incubator.apache.org
> Subject: Re: Flex 5 in haxe
>
> @Gordon
> We actually see an increasing interest in Flex/AIR coming for our
> customers.
> With the small team that we have we actualy cant keep up with the requests.
> But i have to say we have a different  approach to Flex development tho.
>
>
> 2012/11/16 Alex Harui <ah...@adobe.com>
>
> >
> >
> >
> > On 11/16/12 1:52 PM, "Fréderic Cox" <co...@gmail.com> wrote:
> >
> > > I'm glad Alex is here because I believe he does not only have the
> > > experience but also great ideas where Flex should be headed. And he
> > > might have been blocked previously by business decisions but now can
> > > take Flex to a even higher level.
> > >
> > Keep in mind that I'm the biggest proponent of the full re-write.  We
> > may still find a few performance mistakes in the current code (like
> > the Chart styles init that just got fixed), but really, some very
> > smart people have spent a lot of time on the current code and haven't
> found any easy wins.
> > IMO, the framework is slow because lots of code is running just in case.
> > This is especially true for mobile apps where you have the most
> > constrained runtime environment.  The issue that came in today on the
> > users list about slow List performance I'm sure is in part due to
> > TextLine being a bit slower, but probably more due to lots of other code
> running as well.
> >
> > Plus, as many have recently said, the intertwined code we currently
> > have makes it hard for the volunteer to be successful in their spare
> time.
> >
> > I tried the big refactor and it was too difficult for me, but one of
> > the main difficulties was the fact that there was lots of other
> > development going on in the trunk at the same time and keeping my
> > branch running was nearly impossible.  It could be that there won't be
> > as much active development in Apache Flex and a refactor branch will
> > be manageable, but the other problem you run into is that every line
> > of code is needed for some reason at some point, and you tend to start
> > leaving code in.
> >
> > Starting over definitely has its risks, but I think it will have the
> > best outcome.  It won't make 100% parity ever and I'd shoot for 80%
> > over two or three years.  But it will be designed to port to other
> > platforms, and be modular so the volunteer has a chance of making a
> difference.
> >
> > --
> > Alex Harui
> > Flex SDK Team
> > Adobe Systems, Inc.
> > http://blogs.adobe.com/aharui
> >
> >
>

RE: Flex 5 in haxe

[Gordon Smith <go...@adobe.com>]

> we have a different  approach to Flex development 

Can you elaborate on that a little?

-----Original Message-----
From: Alain Ekambi [mailto:jazzmatadazz@gmail.com] 
Sent: Friday, November 16, 2012 2:22 PM
To: flex-dev@incubator.apache.org
Subject: Re: Flex 5 in haxe

@Gordon
We actually see an increasing interest in Flex/AIR coming for our customers.
With the small team that we have we actualy cant keep up with the requests.
But i have to say we have a different  approach to Flex development tho.


2012/11/16 Alex Harui <ah...@adobe.com>

>
>
>
> On 11/16/12 1:52 PM, "Fréderic Cox" <co...@gmail.com> wrote:
>
> > I'm glad Alex is here because I believe he does not only have the 
> > experience but also great ideas where Flex should be headed. And he 
> > might have been blocked previously by business decisions but now can 
> > take Flex to a even higher level.
> >
> Keep in mind that I'm the biggest proponent of the full re-write.  We 
> may still find a few performance mistakes in the current code (like 
> the Chart styles init that just got fixed), but really, some very 
> smart people have spent a lot of time on the current code and haven't found any easy wins.
> IMO, the framework is slow because lots of code is running just in case.
> This is especially true for mobile apps where you have the most 
> constrained runtime environment.  The issue that came in today on the 
> users list about slow List performance I'm sure is in part due to 
> TextLine being a bit slower, but probably more due to lots of other code running as well.
>
> Plus, as many have recently said, the intertwined code we currently 
> have makes it hard for the volunteer to be successful in their spare time.
>
> I tried the big refactor and it was too difficult for me, but one of 
> the main difficulties was the fact that there was lots of other 
> development going on in the trunk at the same time and keeping my 
> branch running was nearly impossible.  It could be that there won't be 
> as much active development in Apache Flex and a refactor branch will 
> be manageable, but the other problem you run into is that every line 
> of code is needed for some reason at some point, and you tend to start 
> leaving code in.
>
> Starting over definitely has its risks, but I think it will have the 
> best outcome.  It won't make 100% parity ever and I'd shoot for 80% 
> over two or three years.  But it will be designed to port to other 
> platforms, and be modular so the volunteer has a chance of making a difference.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>

Re: Flex 5 in haxe

[Fréderic Cox <co...@gmail.com>]

@Gordon, Alex,

We are also creating new apps as well as maintaining older ones. We
previously created web-only OR mobile-only apps. But lately we are
creating a library project which holds 95% of the code and 2 specific
projects for mobile and AIR versions of the app. Just today I presented a
sales application where our sales team can sign contracts with clients
using an iPad app and even manage the same data from the same app on their
laptop. The only difference is a native extension in the mobile version
which adds a meeting in the iOS calendar. It is pure brilliance and
management was very satisfied with this. For a new project we will create
a project where users can upload photos, video and send them to us
(something like WeTransfer.com but more specific to our company) and this
will be both mobile as desktop with the same codebase (and only one
developer working on it, just like for the sales app. It's rapid
development nonetheless)



On 16/11/12 23:22, "Alain Ekambi" <ja...@gmail.com> wrote:

>@Gordon
>We actually see an increasing interest in Flex/AIR coming for our
>customers.
>With the small team that we have we actualy cant keep up with the
>requests.
>But i have to say we have a different  approach to Flex development tho.
>
>
>2012/11/16 Alex Harui <ah...@adobe.com>
>
>>
>>
>>
>> On 11/16/12 1:52 PM, "Fréderic Cox" <co...@gmail.com> wrote:
>>
>> > I'm glad Alex is here because I believe he does not only have
>> > the experience but also great ideas where Flex should be headed. And
>>he
>> > might have been blocked previously by business decisions but now can
>>take
>> > Flex to a even higher level.
>> >
>> Keep in mind that I'm the biggest proponent of the full re-write.  We
>>may
>> still find a few performance mistakes in the current code (like the
>>Chart
>> styles init that just got fixed), but really, some very smart people
>>have
>> spent a lot of time on the current code and haven't found any easy wins.
>> IMO, the framework is slow because lots of code is running just in case.
>> This is especially true for mobile apps where you have the most
>>constrained
>> runtime environment.  The issue that came in today on the users list
>>about
>> slow List performance I'm sure is in part due to TextLine being a bit
>> slower, but probably more due to lots of other code running as well.
>>
>> Plus, as many have recently said, the intertwined code we currently have
>> makes it hard for the volunteer to be successful in their spare time.
>>
>> I tried the big refactor and it was too difficult for me, but one of the
>> main difficulties was the fact that there was lots of other development
>> going on in the trunk at the same time and keeping my branch running was
>> nearly impossible.  It could be that there won't be as much active
>> development in Apache Flex and a refactor branch will be manageable, but
>> the
>> other problem you run into is that every line of code is needed for some
>> reason at some point, and you tend to start leaving code in.
>>
>> Starting over definitely has its risks, but I think it will have the
>>best
>> outcome.  It won't make 100% parity ever and I'd shoot for 80% over two
>>or
>> three years.  But it will be designed to port to other platforms, and be
>> modular so the volunteer has a chance of making a difference.
>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
>>

Re: Flex 5 in haxe

[Alain Ekambi <ja...@gmail.com>]

@Gordon
We actually see an increasing interest in Flex/AIR coming for our customers.
With the small team that we have we actualy cant keep up with the requests.
But i have to say we have a different  approach to Flex development tho.


2012/11/16 Alex Harui <ah...@adobe.com>

>
>
>
> On 11/16/12 1:52 PM, "Fréderic Cox" <co...@gmail.com> wrote:
>
> > I'm glad Alex is here because I believe he does not only have
> > the experience but also great ideas where Flex should be headed. And he
> > might have been blocked previously by business decisions but now can take
> > Flex to a even higher level.
> >
> Keep in mind that I'm the biggest proponent of the full re-write.  We may
> still find a few performance mistakes in the current code (like the Chart
> styles init that just got fixed), but really, some very smart people have
> spent a lot of time on the current code and haven't found any easy wins.
> IMO, the framework is slow because lots of code is running just in case.
> This is especially true for mobile apps where you have the most constrained
> runtime environment.  The issue that came in today on the users list about
> slow List performance I'm sure is in part due to TextLine being a bit
> slower, but probably more due to lots of other code running as well.
>
> Plus, as many have recently said, the intertwined code we currently have
> makes it hard for the volunteer to be successful in their spare time.
>
> I tried the big refactor and it was too difficult for me, but one of the
> main difficulties was the fact that there was lots of other development
> going on in the trunk at the same time and keeping my branch running was
> nearly impossible.  It could be that there won't be as much active
> development in Apache Flex and a refactor branch will be manageable, but
> the
> other problem you run into is that every line of code is needed for some
> reason at some point, and you tend to start leaving code in.
>
> Starting over definitely has its risks, but I think it will have the best
> outcome.  It won't make 100% parity ever and I'd shoot for 80% over two or
> three years.  But it will be designed to port to other platforms, and be
> modular so the volunteer has a chance of making a difference.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>

Re: Flex 5 in haxe

[Alex Harui <ah...@adobe.com>]

On 11/16/12 1:52 PM, "Fréderic Cox" <co...@gmail.com> wrote:

> I'm glad Alex is here because I believe he does not only have
> the experience but also great ideas where Flex should be headed. And he
> might have been blocked previously by business decisions but now can take
> Flex to a even higher level.
> 
Keep in mind that I'm the biggest proponent of the full re-write.  We may
still find a few performance mistakes in the current code (like the Chart
styles init that just got fixed), but really, some very smart people have
spent a lot of time on the current code and haven't found any easy wins.
IMO, the framework is slow because lots of code is running just in case.
This is especially true for mobile apps where you have the most constrained
runtime environment.  The issue that came in today on the users list about
slow List performance I'm sure is in part due to TextLine being a bit
slower, but probably more due to lots of other code running as well.

Plus, as many have recently said, the intertwined code we currently have
makes it hard for the volunteer to be successful in their spare time.

I tried the big refactor and it was too difficult for me, but one of the
main difficulties was the fact that there was lots of other development
going on in the trunk at the same time and keeping my branch running was
nearly impossible.  It could be that there won't be as much active
development in Apache Flex and a refactor branch will be manageable, but the
other problem you run into is that every line of code is needed for some
reason at some point, and you tend to start leaving code in.

Starting over definitely has its risks, but I think it will have the best
outcome.  It won't make 100% parity ever and I'd shoot for 80% over two or
three years.  But it will be designed to port to other platforms, and be
modular so the volunteer has a chance of making a difference.

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

Re: Flex 5 in haxe

[Fréderic Cox <co...@gmail.com>]

I agree with Jude, we should use Flex 5 to show Adobe what they gave away.
I am still creating apps using Adobe AIR and Flex 4.6 and I'm able to
create feature-rich apps which run on mobile and desktop using the same
codebase. This is pure gold but Adobe doesn't realize it, or did but did
not have the financial results yet to keep this on board. That is
business. I'm glad Alex is here because I believe he does not only have
the experience but also great ideas where Flex should be headed. And he
might have been blocked previously by business decisions but now can take
Flex to a even higher level.

I am always developing apps but want to help out on Apache Flex also
because I truly believe in the power of Flex.

On 16/11/12 22:25, "jude" <fl...@gmail.com> wrote:

>+1 to Nick's comments. Alex has stated that Adobe is looking at how the
>Flex community responds to Apache Flex.
>
>We need the Flash Player and AIR. Adobe needs to continue to support us.
>Adobe cannot starve it's children anymore. This needs to change.
>
>Flex is the greatest framework / toolchain I've ever used. It's not
>perfect
>but it was / is the best out there IMHO. Adobe needs to realize they have
>the best solution for targeting multiple platform out there and not to
>throw it all away. We can't go to JS. It's slow compared to Flash.
>
>I attended a presentation on Starling and I think there is a future there.
>Instead of writing to flash.display.DisplayObject you write to
>starling.display.DisplayObject. It is about 1000x faster. All GPU. I think
>we'd lose built in accessibility but you can still use the flash.display.*
>display list and text. We can look into providing an alternative to that.
>Abstracting out the drawing engine would allow us to drop in different
>targets.
>
>Bruce has mentioned writing an open source FP. That would free us from
>being tied to any one VM but I would imagine it's gotta be a lot of work.
>Maybe having the compiler generating different output for other VM targets
>would be better. Maybe add Unity or Silverlight targets.
>
>Adobe is investing heavily in Gaming. So we can rely on that target for
>the
>near future. In the meantime don't throw out the 6 yrs of work by
>excellent
>Flex engineers. I think it is way too soon to talk about a rewrite.
>
>I think more effort should be put in to talking to Adobe about exactly
>what
>is going on.
>
>On Fri, Nov 16, 2012 at 2:58 PM, Gordon Smith <go...@adobe.com> wrote:
>
>> > From what I previously read, I don't think we were getting an updated
>> Falcon compiler that will generate AVM3 code.
>> > They were not planning on open-sourcing that (but correct me if I'm
>> wrong in that aspect).
>>
>> That's correct. Adobe has no plans to open-source its new AS4-for-V12
>> compiler.
>>
>> - Gordon
>>
>> -----Original Message-----
>> From: Nicholas Kwiatkowski [mailto:nicholas@spoon.as]
>> Sent: Friday, November 16, 2012 12:27 PM
>> To: flex-dev@incubator.apache.org
>> Subject: Re: Flex 5 in haxe
>>
>> On Fri, Nov 16, 2012 at 3:08 PM, Stefan Horochovec <
>> stefan.horochovec@gmail.com> wrote:
>>
>> [snip]
>>
>>
>> > The development of the new VM and AS4 specification is not reported or
>> > discussed with Apache Flex, knowing that we depend exclusively of
>> > Flash Player and AIR to execute applications. This in my opinion is
>> terrible.
>> >
>> > Again we will have to wait for an update from Falcon to generate code
>> > for the V12, this delay the progress of the Flex when we are expecting
>> > more and more code from Adobe.
>> >
>> > I'm not saying that we should use haxe, or some other compiler, just
>> > think the time is an even broader discussion. The Flex should continue
>> > only with Flash Player / Adobe AIR runtime?
>> >
>>
>> This is, and has been par for the course.  When Adobe doesn't want to
>>hear
>> us whine and moan, they close off development.   It happened before
>>(and in
>> many more products than just Flex/Flash), and I'm sure it will happen
>> often in the future.  They feel they can surround themselves with
>> "stakeholders"
>> (a small, select subset of customers that their marketing team found
>>them)
>> to make major changes to platforms, products, etc.   At least this time,
>> they were pretty clear in saying we wouldn't have a seat in the table
>>for
>> the future.  Previous times they gave us the illusion that we did.
>>
>> From what I previously read, I don't think we were getting an updated
>> Falcon compiler that will generate AVM3 code.  They were not planning on
>> open-sourcing that (but correct me if I'm wrong in that aspect).
>>
>> I'm pretty sure the community as a whole over the last 11 months have
>> determined to break our dependency of the Flash Player.  We've had a
>>LOT of
>> proposals on how to do it -- none of them executed yet.  The silliest of
>> the bunch in my opinion is porting to HaXe or starting from scratch.
>>Our
>> power is leveraged from Adobe's initial 200,000 hours of labor over the
>> last many years.  We got an awesome code-base that while, it needs some
>> major tweaks, is is really good shape.  Dumping out the baby with the
>> bath-water is not the way to go on a platform that is mature and used by
>> MANY large enterprises.   That being said -- this is now in the Apache
>> world and I can't stop anybody from doing that, but I won't also be
>> helping redo Flex from scratch.
>>
>> -Nick
>>

Re: Flex 5 in haxe

[jude <fl...@gmail.com>]

+1 to Nick's comments. Alex has stated that Adobe is looking at how the
Flex community responds to Apache Flex.

We need the Flash Player and AIR. Adobe needs to continue to support us.
Adobe cannot starve it's children anymore. This needs to change.

Flex is the greatest framework / toolchain I've ever used. It's not perfect
but it was / is the best out there IMHO. Adobe needs to realize they have
the best solution for targeting multiple platform out there and not to
throw it all away. We can't go to JS. It's slow compared to Flash.

I attended a presentation on Starling and I think there is a future there.
Instead of writing to flash.display.DisplayObject you write to
starling.display.DisplayObject. It is about 1000x faster. All GPU. I think
we'd lose built in accessibility but you can still use the flash.display.*
display list and text. We can look into providing an alternative to that.
Abstracting out the drawing engine would allow us to drop in different
targets.

Bruce has mentioned writing an open source FP. That would free us from
being tied to any one VM but I would imagine it's gotta be a lot of work.
Maybe having the compiler generating different output for other VM targets
would be better. Maybe add Unity or Silverlight targets.

Adobe is investing heavily in Gaming. So we can rely on that target for the
near future. In the meantime don't throw out the 6 yrs of work by excellent
Flex engineers. I think it is way too soon to talk about a rewrite.

I think more effort should be put in to talking to Adobe about exactly what
is going on.

On Fri, Nov 16, 2012 at 2:58 PM, Gordon Smith <go...@adobe.com> wrote:

> > From what I previously read, I don't think we were getting an updated
> Falcon compiler that will generate AVM3 code.
> > They were not planning on open-sourcing that (but correct me if I'm
> wrong in that aspect).
>
> That's correct. Adobe has no plans to open-source its new AS4-for-V12
> compiler.
>
> - Gordon
>
> -----Original Message-----
> From: Nicholas Kwiatkowski [mailto:nicholas@spoon.as]
> Sent: Friday, November 16, 2012 12:27 PM
> To: flex-dev@incubator.apache.org
> Subject: Re: Flex 5 in haxe
>
> On Fri, Nov 16, 2012 at 3:08 PM, Stefan Horochovec <
> stefan.horochovec@gmail.com> wrote:
>
> [snip]
>
>
> > The development of the new VM and AS4 specification is not reported or
> > discussed with Apache Flex, knowing that we depend exclusively of
> > Flash Player and AIR to execute applications. This in my opinion is
> terrible.
> >
> > Again we will have to wait for an update from Falcon to generate code
> > for the V12, this delay the progress of the Flex when we are expecting
> > more and more code from Adobe.
> >
> > I'm not saying that we should use haxe, or some other compiler, just
> > think the time is an even broader discussion. The Flex should continue
> > only with Flash Player / Adobe AIR runtime?
> >
>
> This is, and has been par for the course.  When Adobe doesn't want to hear
> us whine and moan, they close off development.   It happened before (and in
> many more products than just Flex/Flash), and I'm sure it will happen
> often in the future.  They feel they can surround themselves with
> "stakeholders"
> (a small, select subset of customers that their marketing team found them)
> to make major changes to platforms, products, etc.   At least this time,
> they were pretty clear in saying we wouldn't have a seat in the table for
> the future.  Previous times they gave us the illusion that we did.
>
> From what I previously read, I don't think we were getting an updated
> Falcon compiler that will generate AVM3 code.  They were not planning on
> open-sourcing that (but correct me if I'm wrong in that aspect).
>
> I'm pretty sure the community as a whole over the last 11 months have
> determined to break our dependency of the Flash Player.  We've had a LOT of
> proposals on how to do it -- none of them executed yet.  The silliest of
> the bunch in my opinion is porting to HaXe or starting from scratch.  Our
> power is leveraged from Adobe's initial 200,000 hours of labor over the
> last many years.  We got an awesome code-base that while, it needs some
> major tweaks, is is really good shape.  Dumping out the baby with the
> bath-water is not the way to go on a platform that is mature and used by
> MANY large enterprises.   That being said -- this is now in the Apache
> world and I can't stop anybody from doing that, but I won't also be
> helping redo Flex from scratch.
>
> -Nick
>

RE: Flex 5 in haxe

[Gordon Smith <go...@adobe.com>]

Even if a high-quality open-source version of Flash Player were developed, it wouldn't have anything like the ubiquity that Adobe's player has, so you'd have distribution issues.

- Gordon

-----Original Message-----
From: Bruce Montague [mailto:Bruce_Montague@symantec.com] 
Sent: Friday, November 16, 2012 1:13 PM
To: flex-dev@incubator.apache.org
Subject: RE: Flex 5 in haxe

Hi, I do not know that much about Flex, the history of Flex, or all the other background relating to this thread, etc.. How realistic would it be for an open source community to write an open source, portable, (likely vanilla C), equivalent of  Flash Player and the AVM? Maybe not including all of the features, but a good-enough subset? Haven't there been a couple of attempts to do this, some with earlier versions of donated code? (Was that really open source code?) Why did none of these efforts succeed? Patents on codecs and the like?

Thanks,

-bruce


-----Original Message-----
From: Gordon Smith [mailto:gosmith@adobe.com]
Sent: Friday, November 16, 2012 12:58 PM
To: flex-dev@incubator.apache.org
Subject: RE: Flex 5 in haxe

> From what I previously read, I don't think we were getting an updated Falcon compiler that will generate AVM3 code.
> They were not planning on open-sourcing that (but correct me if I'm wrong in that aspect).

That's correct. Adobe has no plans to open-source its new AS4-for-V12 compiler.

- Gordon

-----Original Message-----
From: Nicholas Kwiatkowski [mailto:nicholas@spoon.as]
Sent: Friday, November 16, 2012 12:27 PM
To: flex-dev@incubator.apache.org
Subject: Re: Flex 5 in haxe

On Fri, Nov 16, 2012 at 3:08 PM, Stefan Horochovec < stefan.horochovec@gmail.com> wrote:

[snip]


> The development of the new VM and AS4 specification is not reported or 
> discussed with Apache Flex, knowing that we depend exclusively of 
> Flash Player and AIR to execute applications. This in my opinion is terrible.
>
> Again we will have to wait for an update from Falcon to generate code 
> for the V12, this delay the progress of the Flex when we are expecting 
> more and more code from Adobe.
>
> I'm not saying that we should use haxe, or some other compiler, just 
> think the time is an even broader discussion. The Flex should continue 
> only with Flash Player / Adobe AIR runtime?
>

This is, and has been par for the course.  When Adobe doesn't want to hear
us whine and moan, they close off development.   It happened before (and in
many more products than just Flex/Flash), and I'm sure it will happen often in the future.  They feel they can surround themselves with "stakeholders"
(a small, select subset of customers that their marketing team found them)
to make major changes to platforms, products, etc.   At least this time,
they were pretty clear in saying we wouldn't have a seat in the table for the future.  Previous times they gave us the illusion that we did.

>From what I previously read, I don't think we were getting an updated Falcon compiler that will generate AVM3 code.  They were not planning on open-sourcing that (but correct me if I'm wrong in that aspect).

I'm pretty sure the community as a whole over the last 11 months have determined to break our dependency of the Flash Player.  We've had a LOT of proposals on how to do it -- none of them executed yet.  The silliest of the bunch in my opinion is porting to HaXe or starting from scratch.  Our power is leveraged from Adobe's initial 200,000 hours of labor over the last many years.  We got an awesome code-base that while, it needs some major tweaks, is is really good shape.  Dumping out the baby with the bath-water is not the way to go on a platform that is mature and used by
MANY large enterprises.   That being said -- this is now in the Apache
world and I can't stop anybody from doing that, but I won't also be helping redo Flex from scratch.

-Nick

Re: Flex 5 in haxe

[Kevin Newman <Ca...@unFocus.com>]

The main problem is bigger than that. Adobe through it's marketing has 
told everyone that Flash is for Games. They have been actively working 
against the idea that Flash is about ubiquity (they could pick that up 
again, AIR fills the gap, but I don't see any signs they will).

That story is basically dead at Adobe, so it'll be hard to find 
customers for a platform that relies on that narrative. "You want me to 
build my business app on a gaming platform? No thanks."

Flex could still run with that narrative. A build once deploy everywhere 
RIA solution. I don't think the marketing will work if flex is tied to 
Adobe's gaming platform, especially while they are actively working 
against the ubiquity story (their evangelists have been actively warning 
against building non-gaming apps with Flash).

Flex would need a completely new and independent narrative to make it 
work. An additional open source thread could really go a long way to 
address the feeling of having been burned by the Adobe and their pivot 
to gaming exclusivity.

A port to HaXe addresses these issues, while maintaining support for 
legacy code bases.

Kevin N.


On 11/16/12 4:47 PM, jude wrote:
> The main problem is the unstable relation
> the player and AIR. It's not meant to run without it. We need everyone to
> know this is the best solution out there including our clients and tell
> them the problems.

Re: Flex 5 in haxe

[jude <fl...@gmail.com>]

Another penny... Adobe was not good at marketing Flex (or AIR). And I don't
think we're doing well at selling or marketing Flex either. How many people
or clients know it's the best solution out there for targeting multiple
platforms plus it's many other benefits? I can't speak for everyone but I
know I didn't mention it enough. The main problem is the unstable relation
the player and AIR. It's not meant to run without it. We need everyone to
know this is the best solution out there including our clients and tell
them the problems.

On Fri, Nov 16, 2012 at 3:32 PM, Ben Dalton <be...@gmail.com> wrote:

> Another couple pennies worth of input...
>
> One of the things that isn't being considered is that even though you can
> compile the Haxe language back down to many different bytecodes, it's still
> not a way to directly remove the dependency on Adobe's runtime. So much of
> the core of Flex is dependent on the flashplayerglobal libraries which
> won't be present in other runtimes.
>
> My guess is that in order to achieve any sort of independence, we'll need
> to first consider the targeted runtimes and figure out what's the minimum
> common denominator feature set we feel comfortable depending on and
> rearchitect the framework around that functionality being available to our
> framework and abstracted out into a common interface.
>
> I don't think it will simply be sufficient to "rebase" our framework on top
> of another runtime and attempt to bridge the gap between the target runtime
> and what was offered in FP. That sounds like a recipe for headache at best.
>
> My vote for all of this is to keep dependence on AS3 and FP for Flex 5.
> Focusing on improvements in performance and load times while focusing on
> compatibility with AIR as a major aspect of our development.
>
> After Flex 5, we can reconsider targeting other platforms or other
> languages for development.
>
>
>
> On Fri, Nov 16, 2012 at 1:20 PM, Fréderic Cox <co...@gmail.com>
> wrote:
>
> > Personally I think we are looking at the wrong problem here. The changes
> > proposed seem quite drastic to me. I believe we can achieve great things
> > using the current codebase and target. Sure, we need to remove the
> > dependency from Flash at some time but we need to be realistic here ..
> > Porting too Haxe, porting to HTML/JS, ... they are not realistic targets
> > for now due to the limited features compared to what we currently have.
> > After that we can look at porting to a target that has the same feature
> > capabilities. This can be HTML5 but at this moment this is not the case
> so
> > I believe we shouldn't look at too drastic options which might bring this
> > project down. Let's produce results by fixing bugs and improving
> > performance. You'll see that a lot of the "frustration" around
> performance
> > is due to the code in the Flex framework and not AS3.
> >
> > On Fri, Nov 16, 2012 at 10:13 PM, Bruce Montague <
> > Bruce_Montague@symantec.com> wrote:
> >
> > > Hi, I do not know that much about Flex, the history of Flex, or all the
> > > other background relating to this thread, etc.. How realistic would it
> be
> > > for an open source community to write an open source, portable, (likely
> > > vanilla C), equivalent of  Flash Player and the AVM? Maybe not
> including
> > > all of the features, but a good-enough subset? Haven't there been a
> > couple
> > > of attempts to do this, some with earlier versions of donated code?
> (Was
> > > that really open source code?) Why did none of these efforts succeed?
> > > Patents on codecs and the like?
> > >
> > > Thanks,
> > >
> > > -bruce
> > >
> > >
> > > -----Original Message-----
> > > From: Gordon Smith [mailto:gosmith@adobe.com]
> > > Sent: Friday, November 16, 2012 12:58 PM
> > > To: flex-dev@incubator.apache.org
> > > Subject: RE: Flex 5 in haxe
> > >
> > > > From what I previously read, I don't think we were getting an updated
> > > Falcon compiler that will generate AVM3 code.
> > > > They were not planning on open-sourcing that (but correct me if I'm
> > > wrong in that aspect).
> > >
> > > That's correct. Adobe has no plans to open-source its new AS4-for-V12
> > > compiler.
> > >
> > > - Gordon
> > >
> > > -----Original Message-----
> > > From: Nicholas Kwiatkowski [mailto:nicholas@spoon.as]
> > > Sent: Friday, November 16, 2012 12:27 PM
> > > To: flex-dev@incubator.apache.org
> > > Subject: Re: Flex 5 in haxe
> > >
> > > On Fri, Nov 16, 2012 at 3:08 PM, Stefan Horochovec <
> > > stefan.horochovec@gmail.com> wrote:
> > >
> > > [snip]
> > >
> > >
> > > > The development of the new VM and AS4 specification is not reported
> or
> > > > discussed with Apache Flex, knowing that we depend exclusively of
> > > > Flash Player and AIR to execute applications. This in my opinion is
> > > terrible.
> > > >
> > > > Again we will have to wait for an update from Falcon to generate code
> > > > for the V12, this delay the progress of the Flex when we are
> expecting
> > > > more and more code from Adobe.
> > > >
> > > > I'm not saying that we should use haxe, or some other compiler, just
> > > > think the time is an even broader discussion. The Flex should
> continue
> > > > only with Flash Player / Adobe AIR runtime?
> > > >
> > >
> > > This is, and has been par for the course.  When Adobe doesn't want to
> > hear
> > > us whine and moan, they close off development.   It happened before
> (and
> > in
> > > many more products than just Flex/Flash), and I'm sure it will happen
> > > often in the future.  They feel they can surround themselves with
> > > "stakeholders"
> > > (a small, select subset of customers that their marketing team found
> > them)
> > > to make major changes to platforms, products, etc.   At least this
> time,
> > > they were pretty clear in saying we wouldn't have a seat in the table
> for
> > > the future.  Previous times they gave us the illusion that we did.
> > >
> > > From what I previously read, I don't think we were getting an updated
> > > Falcon compiler that will generate AVM3 code.  They were not planning
> on
> > > open-sourcing that (but correct me if I'm wrong in that aspect).
> > >
> > > I'm pretty sure the community as a whole over the last 11 months have
> > > determined to break our dependency of the Flash Player.  We've had a
> LOT
> > of
> > > proposals on how to do it -- none of them executed yet.  The silliest
> of
> > > the bunch in my opinion is porting to HaXe or starting from scratch.
>  Our
> > > power is leveraged from Adobe's initial 200,000 hours of labor over the
> > > last many years.  We got an awesome code-base that while, it needs some
> > > major tweaks, is is really good shape.  Dumping out the baby with the
> > > bath-water is not the way to go on a platform that is mature and used
> by
> > > MANY large enterprises.   That being said -- this is now in the Apache
> > > world and I can't stop anybody from doing that, but I won't also be
> > > helping redo Flex from scratch.
> > >
> > > -Nick
> > >
> >
>

Re: Flex 5 in haxe

[Ben Dalton <be...@gmail.com>]

Another couple pennies worth of input...

One of the things that isn't being considered is that even though you can
compile the Haxe language back down to many different bytecodes, it's still
not a way to directly remove the dependency on Adobe's runtime. So much of
the core of Flex is dependent on the flashplayerglobal libraries which
won't be present in other runtimes.

My guess is that in order to achieve any sort of independence, we'll need
to first consider the targeted runtimes and figure out what's the minimum
common denominator feature set we feel comfortable depending on and
rearchitect the framework around that functionality being available to our
framework and abstracted out into a common interface.

I don't think it will simply be sufficient to "rebase" our framework on top
of another runtime and attempt to bridge the gap between the target runtime
and what was offered in FP. That sounds like a recipe for headache at best.

My vote for all of this is to keep dependence on AS3 and FP for Flex 5.
Focusing on improvements in performance and load times while focusing on
compatibility with AIR as a major aspect of our development.

After Flex 5, we can reconsider targeting other platforms or other
languages for development.



On Fri, Nov 16, 2012 at 1:20 PM, Fréderic Cox <co...@gmail.com> wrote:

> Personally I think we are looking at the wrong problem here. The changes
> proposed seem quite drastic to me. I believe we can achieve great things
> using the current codebase and target. Sure, we need to remove the
> dependency from Flash at some time but we need to be realistic here ..
> Porting too Haxe, porting to HTML/JS, ... they are not realistic targets
> for now due to the limited features compared to what we currently have.
> After that we can look at porting to a target that has the same feature
> capabilities. This can be HTML5 but at this moment this is not the case so
> I believe we shouldn't look at too drastic options which might bring this
> project down. Let's produce results by fixing bugs and improving
> performance. You'll see that a lot of the "frustration" around performance
> is due to the code in the Flex framework and not AS3.
>
> On Fri, Nov 16, 2012 at 10:13 PM, Bruce Montague <
> Bruce_Montague@symantec.com> wrote:
>
> > Hi, I do not know that much about Flex, the history of Flex, or all the
> > other background relating to this thread, etc.. How realistic would it be
> > for an open source community to write an open source, portable, (likely
> > vanilla C), equivalent of  Flash Player and the AVM? Maybe not including
> > all of the features, but a good-enough subset? Haven't there been a
> couple
> > of attempts to do this, some with earlier versions of donated code? (Was
> > that really open source code?) Why did none of these efforts succeed?
> > Patents on codecs and the like?
> >
> > Thanks,
> >
> > -bruce
> >
> >
> > -----Original Message-----
> > From: Gordon Smith [mailto:gosmith@adobe.com]
> > Sent: Friday, November 16, 2012 12:58 PM
> > To: flex-dev@incubator.apache.org
> > Subject: RE: Flex 5 in haxe
> >
> > > From what I previously read, I don't think we were getting an updated
> > Falcon compiler that will generate AVM3 code.
> > > They were not planning on open-sourcing that (but correct me if I'm
> > wrong in that aspect).
> >
> > That's correct. Adobe has no plans to open-source its new AS4-for-V12
> > compiler.
> >
> > - Gordon
> >
> > -----Original Message-----
> > From: Nicholas Kwiatkowski [mailto:nicholas@spoon.as]
> > Sent: Friday, November 16, 2012 12:27 PM
> > To: flex-dev@incubator.apache.org
> > Subject: Re: Flex 5 in haxe
> >
> > On Fri, Nov 16, 2012 at 3:08 PM, Stefan Horochovec <
> > stefan.horochovec@gmail.com> wrote:
> >
> > [snip]
> >
> >
> > > The development of the new VM and AS4 specification is not reported or
> > > discussed with Apache Flex, knowing that we depend exclusively of
> > > Flash Player and AIR to execute applications. This in my opinion is
> > terrible.
> > >
> > > Again we will have to wait for an update from Falcon to generate code
> > > for the V12, this delay the progress of the Flex when we are expecting
> > > more and more code from Adobe.
> > >
> > > I'm not saying that we should use haxe, or some other compiler, just
> > > think the time is an even broader discussion. The Flex should continue
> > > only with Flash Player / Adobe AIR runtime?
> > >
> >
> > This is, and has been par for the course.  When Adobe doesn't want to
> hear
> > us whine and moan, they close off development.   It happened before (and
> in
> > many more products than just Flex/Flash), and I'm sure it will happen
> > often in the future.  They feel they can surround themselves with
> > "stakeholders"
> > (a small, select subset of customers that their marketing team found
> them)
> > to make major changes to platforms, products, etc.   At least this time,
> > they were pretty clear in saying we wouldn't have a seat in the table for
> > the future.  Previous times they gave us the illusion that we did.
> >
> > From what I previously read, I don't think we were getting an updated
> > Falcon compiler that will generate AVM3 code.  They were not planning on
> > open-sourcing that (but correct me if I'm wrong in that aspect).
> >
> > I'm pretty sure the community as a whole over the last 11 months have
> > determined to break our dependency of the Flash Player.  We've had a LOT
> of
> > proposals on how to do it -- none of them executed yet.  The silliest of
> > the bunch in my opinion is porting to HaXe or starting from scratch.  Our
> > power is leveraged from Adobe's initial 200,000 hours of labor over the
> > last many years.  We got an awesome code-base that while, it needs some
> > major tweaks, is is really good shape.  Dumping out the baby with the
> > bath-water is not the way to go on a platform that is mature and used by
> > MANY large enterprises.   That being said -- this is now in the Apache
> > world and I can't stop anybody from doing that, but I won't also be
> > helping redo Flex from scratch.
> >
> > -Nick
> >
>

Re: Flex 5 in haxe

[Fréderic Cox <co...@gmail.com>]

Personally I think we are looking at the wrong problem here. The changes
proposed seem quite drastic to me. I believe we can achieve great things
using the current codebase and target. Sure, we need to remove the
dependency from Flash at some time but we need to be realistic here ..
Porting too Haxe, porting to HTML/JS, ... they are not realistic targets
for now due to the limited features compared to what we currently have.
After that we can look at porting to a target that has the same feature
capabilities. This can be HTML5 but at this moment this is not the case so
I believe we shouldn't look at too drastic options which might bring this
project down. Let's produce results by fixing bugs and improving
performance. You'll see that a lot of the "frustration" around performance
is due to the code in the Flex framework and not AS3.

On Fri, Nov 16, 2012 at 10:13 PM, Bruce Montague <
Bruce_Montague@symantec.com> wrote:

> Hi, I do not know that much about Flex, the history of Flex, or all the
> other background relating to this thread, etc.. How realistic would it be
> for an open source community to write an open source, portable, (likely
> vanilla C), equivalent of  Flash Player and the AVM? Maybe not including
> all of the features, but a good-enough subset? Haven't there been a couple
> of attempts to do this, some with earlier versions of donated code? (Was
> that really open source code?) Why did none of these efforts succeed?
> Patents on codecs and the like?
>
> Thanks,
>
> -bruce
>
>
> -----Original Message-----
> From: Gordon Smith [mailto:gosmith@adobe.com]
> Sent: Friday, November 16, 2012 12:58 PM
> To: flex-dev@incubator.apache.org
> Subject: RE: Flex 5 in haxe
>
> > From what I previously read, I don't think we were getting an updated
> Falcon compiler that will generate AVM3 code.
> > They were not planning on open-sourcing that (but correct me if I'm
> wrong in that aspect).
>
> That's correct. Adobe has no plans to open-source its new AS4-for-V12
> compiler.
>
> - Gordon
>
> -----Original Message-----
> From: Nicholas Kwiatkowski [mailto:nicholas@spoon.as]
> Sent: Friday, November 16, 2012 12:27 PM
> To: flex-dev@incubator.apache.org
> Subject: Re: Flex 5 in haxe
>
> On Fri, Nov 16, 2012 at 3:08 PM, Stefan Horochovec <
> stefan.horochovec@gmail.com> wrote:
>
> [snip]
>
>
> > The development of the new VM and AS4 specification is not reported or
> > discussed with Apache Flex, knowing that we depend exclusively of
> > Flash Player and AIR to execute applications. This in my opinion is
> terrible.
> >
> > Again we will have to wait for an update from Falcon to generate code
> > for the V12, this delay the progress of the Flex when we are expecting
> > more and more code from Adobe.
> >
> > I'm not saying that we should use haxe, or some other compiler, just
> > think the time is an even broader discussion. The Flex should continue
> > only with Flash Player / Adobe AIR runtime?
> >
>
> This is, and has been par for the course.  When Adobe doesn't want to hear
> us whine and moan, they close off development.   It happened before (and in
> many more products than just Flex/Flash), and I'm sure it will happen
> often in the future.  They feel they can surround themselves with
> "stakeholders"
> (a small, select subset of customers that their marketing team found them)
> to make major changes to platforms, products, etc.   At least this time,
> they were pretty clear in saying we wouldn't have a seat in the table for
> the future.  Previous times they gave us the illusion that we did.
>
> From what I previously read, I don't think we were getting an updated
> Falcon compiler that will generate AVM3 code.  They were not planning on
> open-sourcing that (but correct me if I'm wrong in that aspect).
>
> I'm pretty sure the community as a whole over the last 11 months have
> determined to break our dependency of the Flash Player.  We've had a LOT of
> proposals on how to do it -- none of them executed yet.  The silliest of
> the bunch in my opinion is porting to HaXe or starting from scratch.  Our
> power is leveraged from Adobe's initial 200,000 hours of labor over the
> last many years.  We got an awesome code-base that while, it needs some
> major tweaks, is is really good shape.  Dumping out the baby with the
> bath-water is not the way to go on a platform that is mature and used by
> MANY large enterprises.   That being said -- this is now in the Apache
> world and I can't stop anybody from doing that, but I won't also be
> helping redo Flex from scratch.
>
> -Nick
>

RE: Flex 5 in haxe

[Bruce Montague <Br...@symantec.com>]

Hi, I do not know that much about Flex, the history of Flex, or all the other background relating to this thread, etc.. How realistic would it be for an open source community to write an open source, portable, (likely vanilla C), equivalent of  Flash Player and the AVM? Maybe not including all of the features, but a good-enough subset? Haven't there been a couple of attempts to do this, some with earlier versions of donated code? (Was that really open source code?) Why did none of these efforts succeed? Patents on codecs and the like?

Thanks,

-bruce


-----Original Message-----
From: Gordon Smith [mailto:gosmith@adobe.com] 
Sent: Friday, November 16, 2012 12:58 PM
To: flex-dev@incubator.apache.org
Subject: RE: Flex 5 in haxe

> From what I previously read, I don't think we were getting an updated Falcon compiler that will generate AVM3 code.
> They were not planning on open-sourcing that (but correct me if I'm wrong in that aspect).

That's correct. Adobe has no plans to open-source its new AS4-for-V12 compiler.

- Gordon

-----Original Message-----
From: Nicholas Kwiatkowski [mailto:nicholas@spoon.as]
Sent: Friday, November 16, 2012 12:27 PM
To: flex-dev@incubator.apache.org
Subject: Re: Flex 5 in haxe

On Fri, Nov 16, 2012 at 3:08 PM, Stefan Horochovec < stefan.horochovec@gmail.com> wrote:

[snip]


> The development of the new VM and AS4 specification is not reported or 
> discussed with Apache Flex, knowing that we depend exclusively of 
> Flash Player and AIR to execute applications. This in my opinion is terrible.
>
> Again we will have to wait for an update from Falcon to generate code 
> for the V12, this delay the progress of the Flex when we are expecting 
> more and more code from Adobe.
>
> I'm not saying that we should use haxe, or some other compiler, just 
> think the time is an even broader discussion. The Flex should continue 
> only with Flash Player / Adobe AIR runtime?
>

This is, and has been par for the course.  When Adobe doesn't want to hear
us whine and moan, they close off development.   It happened before (and in
many more products than just Flex/Flash), and I'm sure it will happen often in the future.  They feel they can surround themselves with "stakeholders"
(a small, select subset of customers that their marketing team found them)
to make major changes to platforms, products, etc.   At least this time,
they were pretty clear in saying we wouldn't have a seat in the table for the future.  Previous times they gave us the illusion that we did.

>From what I previously read, I don't think we were getting an updated Falcon compiler that will generate AVM3 code.  They were not planning on open-sourcing that (but correct me if I'm wrong in that aspect).

I'm pretty sure the community as a whole over the last 11 months have determined to break our dependency of the Flash Player.  We've had a LOT of proposals on how to do it -- none of them executed yet.  The silliest of the bunch in my opinion is porting to HaXe or starting from scratch.  Our power is leveraged from Adobe's initial 200,000 hours of labor over the last many years.  We got an awesome code-base that while, it needs some major tweaks, is is really good shape.  Dumping out the baby with the bath-water is not the way to go on a platform that is mature and used by
MANY large enterprises.   That being said -- this is now in the Apache
world and I can't stop anybody from doing that, but I won't also be helping redo Flex from scratch.

-Nick

Re: Flex 5 in haxe

[Carlos Rovira <ca...@codeoscopic.com>]

Hi Kevin,

all depends of how things evolve but I must say that my propossal (and my
contribution if someday get materialized in code) about Haxe is base the
API in current Flex 4.x as a starting point (a draft), but modeling and
changing it as project evolve. This project is for fun, at least in its
conception, and taking into account that it will be done in spare time, I
would not try even to plan any migration or compatibility with old Flex
applications to that FlexHaxe thing. We should copy the right things and
rethink the old or bad ones. For people that wants to continue the current
path (Flex 4.x) always will be maintenance a new features/patches in that
"Flex line". Apache Flex count we members involved in such different ways,
what's very cool to get both things done. A new Flex framework should be
new and free from any ties from the pass.


2012/11/20 Kevin Newman <Ca...@unfocus.com>

> HaXe really is more similar to AS3 than many here seem to think (it's more
> of a superset than a subset - though there are some missing features like
> namespace). Would Flex really need to start from scratch when porting to
> HaXe? Could some level of automation be utilized (there's an unfinished
> tool that could be picked up and worked on for doing just that)?
>
> The biggest problem with a change in platform has more to do legacy
> support.
>
> What do you do with all that AS3 code? If Flex is written in HaXe, and you
> still target Flash/AIR platform, you can still rely on the old AS3 compiler
> to leverage all that legacy SWC and AS3 code. HaXe in this migration path
> doesn't require dumping legacy code at all. Win/win. Flex migration could
> even be modularized, because of this. I wonder if a small proof of concept
> could be attempted - convert some core Flex components to HaXe, compile to
> SWC, and leave the rest in AS3, and see how that goes.
>
> A benefit of the switch, of course, is HaXe allows movement to many
> platforms other than ABC/Flash/AIR - including open stacks such as NME,
> Neko and HTML5.
>
> In short HaXe nets Flex a lot. Legacy code base support through Flash/AIR,
> support for completely open stack(s) for apps, and HTML5 support. This is
> the power of open source.
>
> HaXe Foundation:
> http://haxe-foundation.org/
>
> Kevin N.
>
>
> On 11/16/12 3:58 PM, Gordon Smith wrote:
>
>> The silliest of the bunch in my opinion is porting to HaXe or starting
>> from scratch.
>>
>
>


-- 
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F:  +34 912 35 57 77
http://www.codeoscopic.com
http://www.directwriter.es
http://www.avant2.es

Re: Flex 5 in haxe

[Kevin Newman <Ca...@unFocus.com>]

HaXe really is more similar to AS3 than many here seem to think (it's 
more of a superset than a subset - though there are some missing 
features like namespace). Would Flex really need to start from scratch 
when porting to HaXe? Could some level of automation be utilized 
(there's an unfinished tool that could be picked up and worked on for 
doing just that)?

The biggest problem with a change in platform has more to do legacy support.

What do you do with all that AS3 code? If Flex is written in HaXe, and 
you still target Flash/AIR platform, you can still rely on the old AS3 
compiler to leverage all that legacy SWC and AS3 code. HaXe in this 
migration path doesn't require dumping legacy code at all. Win/win. Flex 
migration could even be modularized, because of this. I wonder if a 
small proof of concept could be attempted - convert some core Flex 
components to HaXe, compile to SWC, and leave the rest in AS3, and see 
how that goes.

A benefit of the switch, of course, is HaXe allows movement to many 
platforms other than ABC/Flash/AIR - including open stacks such as NME, 
Neko and HTML5.

In short HaXe nets Flex a lot. Legacy code base support through 
Flash/AIR, support for completely open stack(s) for apps, and HTML5 
support. This is the power of open source.

HaXe Foundation:
http://haxe-foundation.org/

Kevin N.


On 11/16/12 3:58 PM, Gordon Smith wrote:
> The silliest of the bunch in my opinion is porting to HaXe or starting from scratch.

RE: Flex 5 in haxe

[Gordon Smith <go...@adobe.com>]

> From what I previously read, I don't think we were getting an updated Falcon compiler that will generate AVM3 code.
> They were not planning on open-sourcing that (but correct me if I'm wrong in that aspect).

That's correct. Adobe has no plans to open-source its new AS4-for-V12 compiler.

- Gordon

-----Original Message-----
From: Nicholas Kwiatkowski [mailto:nicholas@spoon.as] 
Sent: Friday, November 16, 2012 12:27 PM
To: flex-dev@incubator.apache.org
Subject: Re: Flex 5 in haxe

On Fri, Nov 16, 2012 at 3:08 PM, Stefan Horochovec < stefan.horochovec@gmail.com> wrote:

[snip]


> The development of the new VM and AS4 specification is not reported or 
> discussed with Apache Flex, knowing that we depend exclusively of 
> Flash Player and AIR to execute applications. This in my opinion is terrible.
>
> Again we will have to wait for an update from Falcon to generate code 
> for the V12, this delay the progress of the Flex when we are expecting 
> more and more code from Adobe.
>
> I'm not saying that we should use haxe, or some other compiler, just 
> think the time is an even broader discussion. The Flex should continue 
> only with Flash Player / Adobe AIR runtime?
>

This is, and has been par for the course.  When Adobe doesn't want to hear
us whine and moan, they close off development.   It happened before (and in
many more products than just Flex/Flash), and I'm sure it will happen often in the future.  They feel they can surround themselves with "stakeholders"
(a small, select subset of customers that their marketing team found them)
to make major changes to platforms, products, etc.   At least this time,
they were pretty clear in saying we wouldn't have a seat in the table for the future.  Previous times they gave us the illusion that we did.

>From what I previously read, I don't think we were getting an updated Falcon compiler that will generate AVM3 code.  They were not planning on open-sourcing that (but correct me if I'm wrong in that aspect).

I'm pretty sure the community as a whole over the last 11 months have determined to break our dependency of the Flash Player.  We've had a LOT of proposals on how to do it -- none of them executed yet.  The silliest of the bunch in my opinion is porting to HaXe or starting from scratch.  Our power is leveraged from Adobe's initial 200,000 hours of labor over the last many years.  We got an awesome code-base that while, it needs some major tweaks, is is really good shape.  Dumping out the baby with the bath-water is not the way to go on a platform that is mature and used by
MANY large enterprises.   That being said -- this is now in the Apache
world and I can't stop anybody from doing that, but I won't also be helping redo Flex from scratch.

-Nick

Re: Flex 5 in haxe

[Nicholas Kwiatkowski <ni...@spoon.as>]

On Fri, Nov 16, 2012 at 3:08 PM, Stefan Horochovec <
stefan.horochovec@gmail.com> wrote:

[snip]


> The development of the new VM and AS4 specification is not reported or
> discussed with Apache Flex, knowing that we depend exclusively of Flash
> Player and AIR to execute applications. This in my opinion is terrible.
>
> Again we will have to wait for an update from Falcon to generate code for
> the V12, this delay the progress of the Flex when we are expecting more and
> more code from Adobe.
>
> I'm not saying that we should use haxe, or some other compiler, just think
> the time is an even broader discussion. The Flex should continue only with
> Flash Player / Adobe AIR runtime?
>

This is, and has been par for the course.  When Adobe doesn't want to hear
us whine and moan, they close off development.   It happened before (and in
many more products than just Flex/Flash), and I'm sure it will happen often
in the future.  They feel they can surround themselves with "stakeholders"
(a small, select subset of customers that their marketing team found them)
to make major changes to platforms, products, etc.   At least this time,
they were pretty clear in saying we wouldn't have a seat in the table for
the future.  Previous times they gave us the illusion that we did.

>From what I previously read, I don't think we were getting an updated
Falcon compiler that will generate AVM3 code.  They were not planning on
open-sourcing that (but correct me if I'm wrong in that aspect).

I'm pretty sure the community as a whole over the last 11 months have
determined to break our dependency of the Flash Player.  We've had a LOT of
proposals on how to do it -- none of them executed yet.  The silliest of
the bunch in my opinion is porting to HaXe or starting from scratch.  Our
power is leveraged from Adobe's initial 200,000 hours of labor over the
last many years.  We got an awesome code-base that while, it needs some
major tweaks, is is really good shape.  Dumping out the baby with the
bath-water is not the way to go on a platform that is mature and used by
MANY large enterprises.   That being said -- this is now in the Apache
world and I can't stop anybody from doing that, but I won't also be helping
redo Flex from scratch.

-Nick

Re: Flex 5 in haxe

[Stefan Horochovec <st...@gmail.com>]

Hi

Well, I'm sad to say it, but those doubts now arise from the fact that Flex
generates bytecode that runs on a VM that does not perterce to us, we are
required to use the features it comes, and not what would like to have.
Some features that were designed in the list (Generics, proposed by myself)
would not be possible due to lack of resources the VM.

I believe the best way to become Flex is a framework for RIA development,
but without the dependence on Flash Player. Disagree with this dependence
because we have to adjust ourselves when Adobe changed their thinking about
Flash Player, as is happening now.

The development of the new VM and AS4 specification is not reported or
discussed with Apache Flex, knowing that we depend exclusively of Flash
Player and AIR to execute applications. This in my opinion is terrible.

Again we will have to wait for an update from Falcon to generate code for
the V12, this delay the progress of the Flex when we are expecting more and
more code from Adobe.

I'm not saying that we should use haxe, or some other compiler, just think
the time is an even broader discussion. The Flex should continue only with
Flash Player / Adobe AIR runtime?

Regards

Stefan Horochovec



2012/11/16 Gordon Smith <go...@adobe.com>

> > Currently I see no compelling reason to move to the new VM when it comes
> out. Once we know more about it that may change but it sounds like it wont
> be compatible with AS3.
>
> The new VM will not execute the old bytecode that any AS3 compiler
> currently produces. Adobe is turning its new Falcon-based AS3 compiler into
> an AS4 compiler that produces the new bytecode for V12.
>
> > The existing one for the moment works and is likely to be around for
> many many years.
>
> Yes, Adobe isn't going to "break the web" by discontinuing V11 support any
> time soon.
>
> - Gordon
>
>
> -----Original Message-----
> From: Justin Mclean [mailto:justin@classsoftware.com]
> Sent: Friday, November 16, 2012 5:18 AM
> To: flex-dev@incubator.apache.org
> Subject: Re: Flex 5 in haxe
>
> Hi,
>
> > I've said it before it is a really great idea to write Flex in a
> > language that can be compiled to other platforms. Haxe is a great
> > language that lives to its promise.
> I only know a little about Haxe. Could you comment on what would be
> required (in terms of skills and effort) to port Flex to Haxe? I know it's
> ActionScript like but is missing a few features that Flex may be using?
> Other than compiling to multiple targets does it have any other significant
> advantages? Any idea if there are likely to be major performance issues due
> to the fact that Flex is reasonably complex and designed for the Flash VM?
>
> > Going with Actionscript now would be a problem as it won't be long
> > until the next Actionscript will come out and then Flex 5 would have
> > to be written again.
> Currently I see no compelling reason to move to the new VM when it comes
> out. Once we know more about it that may change but it sounds like it wont
> be compatible with AS3. The existing one for the moment works and is likely
> to be around for many many years.
>
> > I wonder how large the next Flash player would be in terms of file size.
> Bigger but not significantly so I would guess (1.5x current size at
> most?). Again don't really see this as an issue for not using it.
>
> Thanks,
> Justin
>
>

RE: Flex 5 in haxe

[Gordon Smith <go...@adobe.com>]

> Currently I see no compelling reason to move to the new VM when it comes out. Once we know more about it that may change but it sounds like it wont be compatible with AS3.

The new VM will not execute the old bytecode that any AS3 compiler currently produces. Adobe is turning its new Falcon-based AS3 compiler into an AS4 compiler that produces the new bytecode for V12.

> The existing one for the moment works and is likely to be around for many many years.

Yes, Adobe isn't going to "break the web" by discontinuing V11 support any time soon.

- Gordon


-----Original Message-----
From: Justin Mclean [mailto:justin@classsoftware.com] 
Sent: Friday, November 16, 2012 5:18 AM
To: flex-dev@incubator.apache.org
Subject: Re: Flex 5 in haxe

Hi,

> I've said it before it is a really great idea to write Flex in a 
> language that can be compiled to other platforms. Haxe is a great 
> language that lives to its promise.
I only know a little about Haxe. Could you comment on what would be required (in terms of skills and effort) to port Flex to Haxe? I know it's ActionScript like but is missing a few features that Flex may be using? Other than compiling to multiple targets does it have any other significant advantages? Any idea if there are likely to be major performance issues due to the fact that Flex is reasonably complex and designed for the Flash VM?

> Going with Actionscript now would be a problem as it won't be long 
> until the next Actionscript will come out and then Flex 5 would have 
> to be written again.
Currently I see no compelling reason to move to the new VM when it comes out. Once we know more about it that may change but it sounds like it wont be compatible with AS3. The existing one for the moment works and is likely to be around for many many years.

> I wonder how large the next Flash player would be in terms of file size. 
Bigger but not significantly so I would guess (1.5x current size at most?). Again don't really see this as an issue for not using it.

Thanks,
Justin

Re: Flex 5 in haxe

[John Cunliffe <ma...@gmail.com>]

According to Wikipedia: Haxe also includes platform-specific API, but as of
2012, it only supports a subset of the functionality available in each
platform[5] <http://en.wikipedia.org/wiki/Haxe#cite_note-hapi-5>, with only
the Flash platform API fully usable.

On Mon, Nov 19, 2012 at 1:32 AM, Gordon Smith <go...@adobe.com> wrote:

> > Haxe is a C++ "like" language.  It is not ActionScript, JavaScript, etc.
>
> It looks more like ActionScript than C++ to me. Below is an example from
> http://haxe.org/doc/snip/newtonmethod . Note that variable declarations
> are
>
>     var f0:Float
>
> not
>
>     Float f0;
>
> - Gordon
>
> class Newton{
>
> public static function main(){
>
> neko.Lib.println("Enter Starting Point");
> var x0 : Float = Std.parseFloat(neko.Sys.stdin().readLine());
>
> neko.Lib.println("How Many Iterations?");
> var count : Int = Std.parseInt(neko.Sys.stdin().readLine());
>
> // Initialization of variables
> var f0 : Float;
> var df0 : Float;
> var p0 : Float;
> var p1 : Float;
>
> p0=x0; // Initial guess at x0
>
> for(i in 0...count)
>
> {
>
> f0=x0*x0-401; // f(x) = x^2-401 or evaluate sqrt(401)
> df0=2*x0;     // f'(x) = 2x (derivative of f(x))
>
> p1=p0-(f0/df0);  // p1=p0-(f(x)/f'(x)) Newton's Method Here
>
> neko.Lib.println("p1 = " + p1);
> p0=p1; //switch variables for next iteration
> x0=p1; //switch variables for next iteration
>
> }
> }
> }ess at x0
>
> for(i in 0...count)
>
> {
>
> f0=x0*x0-401; // f(x) = x^2-401 or evaluate sqrt(401)
> df0=2*x0;     // f'(x) = 2x (derivative of f(x))
>
> p1=p0-(f0/df0);  // p1=p0-(f(x)/f'(x)) Newton's Method Here
>
> neko.Lib.println("p1 = " + p1);
> p0=p1; //switch variables for next iteration
> x0=p1; //switch variables for next iteration
>
> }
> }
> }
>
> -----Original Message-----
> From: Nicholas Kwiatkowski [mailto:nicholas@spoon.as]
> Sent: Friday, November 16, 2012 9:31 AM
> To: flex-dev@incubator.apache.org
> Subject: Re: Flex 5 in haxe
>
> On Fri, Nov 16, 2012 at 8:17 AM, Justin Mclean <justin@classsoftware.com
> >wrote:
>
> >
> > I only know a little about Haxe. Could you comment on what would be
> > required (in terms of skills and effort) to port Flex to Haxe? I know
> > it's ActionScript like but is missing a few features that Flex may be
> using?
> > Other than compiling to multiple targets does it have any other
> > significant advantages? Any idea if there are likely to be major
> > performance issues due to the fact that Flex is reasonably complex and
> designed for the Flash VM?
> >
>
> Haxe is a C++ "like" language.  It is not ActionScript, JavaScript, etc.
>  It would be a complete re-write of everything we currently already know
> and use.
>
> Haxe is unique in that that single C++ like language then can output to
> navtive apps, SWF, Silverlight, HTML/JS, etc.  It's not very good at any of
> them, and the biggest problem with the language is that it limits itself to
> the least common detonator of all the platforms it supports.
>
>
> > Currently I see no compelling reason to move to the new VM when it
> > comes out. Once we know more about it that may change but it sounds
> > like it wont be compatible with AS3. The existing one for the moment
> > works and is likely to be around for many many years.
> >
> >
> AS2 is still well supported (and, surprisingly used) in most outputs.  No
> reason to move and essentially invalidate all the work done up to this
> point in time.  If we change technologies (HaXe or AS4) we throw out
> EVERYTHING the community has built up to now.  Sure, we will have a shiney
> new product, but nothing will stand on it.
>

RE: Flex 5 in haxe

[Gordon Smith <go...@adobe.com>]

> Haxe is a C++ "like" language.  It is not ActionScript, JavaScript, etc.

It looks more like ActionScript than C++ to me. Below is an example from http://haxe.org/doc/snip/newtonmethod . Note that variable declarations are

    var f0:Float

not

    Float f0;

- Gordon

class Newton{

public static function main(){

neko.Lib.println("Enter Starting Point");
var x0 : Float = Std.parseFloat(neko.Sys.stdin().readLine());

neko.Lib.println("How Many Iterations?");
var count : Int = Std.parseInt(neko.Sys.stdin().readLine());

// Initialization of variables
var f0 : Float;
var df0 : Float;
var p0 : Float;
var p1 : Float;

p0=x0; // Initial guess at x0

for(i in 0...count) 

{

f0=x0*x0-401; // f(x) = x^2-401 or evaluate sqrt(401)
df0=2*x0;     // f'(x) = 2x (derivative of f(x))

p1=p0-(f0/df0);  // p1=p0-(f(x)/f'(x)) Newton's Method Here

neko.Lib.println("p1 = " + p1);
p0=p1; //switch variables for next iteration
x0=p1; //switch variables for next iteration

}
}
}ess at x0

for(i in 0...count) 

{

f0=x0*x0-401; // f(x) = x^2-401 or evaluate sqrt(401)
df0=2*x0;     // f'(x) = 2x (derivative of f(x))

p1=p0-(f0/df0);  // p1=p0-(f(x)/f'(x)) Newton's Method Here

neko.Lib.println("p1 = " + p1);
p0=p1; //switch variables for next iteration
x0=p1; //switch variables for next iteration

}
}
}

-----Original Message-----
From: Nicholas Kwiatkowski [mailto:nicholas@spoon.as] 
Sent: Friday, November 16, 2012 9:31 AM
To: flex-dev@incubator.apache.org
Subject: Re: Flex 5 in haxe

On Fri, Nov 16, 2012 at 8:17 AM, Justin Mclean <ju...@classsoftware.com>wrote:

>
> I only know a little about Haxe. Could you comment on what would be 
> required (in terms of skills and effort) to port Flex to Haxe? I know 
> it's ActionScript like but is missing a few features that Flex may be using?
> Other than compiling to multiple targets does it have any other 
> significant advantages? Any idea if there are likely to be major 
> performance issues due to the fact that Flex is reasonably complex and designed for the Flash VM?
>

Haxe is a C++ "like" language.  It is not ActionScript, JavaScript, etc.
 It would be a complete re-write of everything we currently already know and use.

Haxe is unique in that that single C++ like language then can output to navtive apps, SWF, Silverlight, HTML/JS, etc.  It's not very good at any of them, and the biggest problem with the language is that it limits itself to the least common detonator of all the platforms it supports.


> Currently I see no compelling reason to move to the new VM when it 
> comes out. Once we know more about it that may change but it sounds 
> like it wont be compatible with AS3. The existing one for the moment 
> works and is likely to be around for many many years.
>
>
AS2 is still well supported (and, surprisingly used) in most outputs.  No reason to move and essentially invalidate all the work done up to this point in time.  If we change technologies (HaXe or AS4) we throw out EVERYTHING the community has built up to now.  Sure, we will have a shiney new product, but nothing will stand on it.

Re: Flex 5 in haxe

[Nicholas Kwiatkowski <ni...@spoon.as>]

On Fri, Nov 16, 2012 at 8:17 AM, Justin Mclean <ju...@classsoftware.com>wrote:

>
> I only know a little about Haxe. Could you comment on what would be
> required (in terms of skills and effort) to port Flex to Haxe? I know it's
> ActionScript like but is missing a few features that Flex may be using?
> Other than compiling to multiple targets does it have any other significant
> advantages? Any idea if there are likely to be major performance issues due
> to the fact that Flex is reasonably complex and designed for the Flash VM?
>

Haxe is a C++ "like" language.  It is not ActionScript, JavaScript, etc.
 It would be a complete re-write of everything we currently already know
and use.

Haxe is unique in that that single C++ like language then can output to
navtive apps, SWF, Silverlight, HTML/JS, etc.  It's not very good at any of
them, and the biggest problem with the language is that it limits itself to
the least common detonator of all the platforms it supports.


> Currently I see no compelling reason to move to the new VM when it comes
> out. Once we know more about it that may change but it sounds like it wont
> be compatible with AS3. The existing one for the moment works and is likely
> to be around for many many years.
>
>
AS2 is still well supported (and, surprisingly used) in most outputs.  No
reason to move and essentially invalidate all the work done up to this
point in time.  If we change technologies (HaXe or AS4) we throw out
EVERYTHING the community has built up to now.  Sure, we will have a shiney
new product, but nothing will stand on it.

Re: Flex 5 in haxe

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> I've said it before it is a really great idea to write Flex in a language
> that can be compiled to other platforms. Haxe is a great language that
> lives to its promise.
I only know a little about Haxe. Could you comment on what would be required (in terms of skills and effort) to port Flex to Haxe? I know it's ActionScript like but is missing a few features that Flex may be using? Other than compiling to multiple targets does it have any other significant advantages? Any idea if there are likely to be major performance issues due to the fact that Flex is reasonably complex and designed for the Flash VM?

> Going with Actionscript now would be a problem as it
> won't be long until the next Actionscript will come out and then Flex 5
> would have to be written again.
Currently I see no compelling reason to move to the new VM when it comes out. Once we know more about it that may change but it sounds like it wont be compatible with AS3. The existing one for the moment works and is likely to be around for many many years.

> I wonder how large the next Flash player would be in terms of file size. 
Bigger but not significantly so I would guess (1.5x current size at most?). Again don't really see this as an issue for not using it.

Thanks,
Justin

Re: Flex 5 in haxe

[James Roland Cabresos <j....@gmail.com>]

Why still consider Adobe when they've already abandoned Flex? (I'm refering
to Adobe as an organization, no offense to the Adobe guys here.)

I've said it before it is a really great idea to write Flex in a language
that can be compiled to other platforms. Haxe is a great language that
lives to its promise. Going with Actionscript now would be a problem as it
won't be long until the next Actionscript will come out and then Flex 5
would have to be written again. I wonder how large the next Flash player
would be in terms of file size. I assume it's going to be big with 3
different AVMs to support older swfs.

On Fri, Nov 16, 2012 at 8:20 PM, Alain Ekambi <ja...@gmail.com>wrote:

> For what i saw and experienced if it s not based on ActionScript  Adobe is
> not interested.
> No matter how good that could be for Flash in general.
>
>
> 2012/11/16 Eugene Krevenets (aka Hyzhak) <hy...@yandex.com>
>
> > By the way Nicolas Cannasse has been already propose Apache Flex
> community
> > to join forces.
> > http://ncannasse.fr/blog/open_letter_to_flex_community
> >
> > --
> > Best regards.
> >
> > Eugene Krevenets. Software Engineer of Realaxy.
> >
> > Blog: http://anykeytocreate.blogspot.com
> > Code: http://hyzhak.github.com
> > linkedIn: http://me.linkedin.com/in/eugenekrevenets
> >
>

Re: Flex 5 in haxe

[Alain Ekambi <ja...@gmail.com>]

For what i saw and experienced if it s not based on ActionScript  Adobe is
not interested.
No matter how good that could be for Flash in general.


2012/11/16 Eugene Krevenets (aka Hyzhak) <hy...@yandex.com>

> By the way Nicolas Cannasse has been already propose Apache Flex community
> to join forces.
> http://ncannasse.fr/blog/open_letter_to_flex_community
>
> --
> Best regards.
>
> Eugene Krevenets. Software Engineer of Realaxy.
>
> Blog: http://anykeytocreate.blogspot.com
> Code: http://hyzhak.github.com
> linkedIn: http://me.linkedin.com/in/eugenekrevenets
>

Re: Flex 5 in haxe

["Eugene Krevenets (aka Hyzhak)" <hy...@yandex.com>]

By the way Nicolas Cannasse has been already propose Apache Flex community to join forces.
http://ncannasse.fr/blog/open_letter_to_flex_community

-- 
Best regards. 

Eugene Krevenets. Software Engineer of Realaxy.

Blog: http://anykeytocreate.blogspot.com
Code: http://hyzhak.github.com
linkedIn: http://me.linkedin.com/in/eugenekrevenets

Re: Flex 5 in haxe

[Kevin Newman <Ca...@unFocus.com>]

Just some notes on Starling:

* Starling is written in AS3, so that'd need to be ported to HaXe along 
with everything else (unless you just use it for the Flash target).

* Native Apps: Starling uses Stage3D, which NME doesn't (yet) support 
(afaik, and I did just look somewhat recently). I suppose you could just 
write an NME target directly from Flex (as discussed on another thread), 
and then use it's backends.

* HTML5 target: Starling would basically need to be rewritten in JS and 
WebGL and/or Canvas (required for IE). Actually, there may be an NME 
target for HTML5 - that'd be pretty convenient, if an NME target is 
already complete.

Kevin N.

Re: Flex 5 in haxe

["Eugene Krevenets (aka Hyzhak)" <hy...@yandex.com>]

Excellent idea. 

Good news - If we going to do so, we just make our work more easy because going to create new compiler for VMNext with Nicolas Cannasse.
But bad news - in this situation i think guys from Adobe doesn't help us with new compiler.

16.11.2012, 11:49, "Carlos Rovira" <ca...@codeoscopic.com>:
> Hi,
>
> as we were discussing yesterday, there's room to a new Flex framework
> written from scratch. As we don't want to rely in Adobe technologies
> anymore we were talking about haxe. We can make it now that work would be
> starting from zero.
>
> Haxe is a platform developed by Nicolas Canesse that made it's own
> community. Nicolas is a genius of compilers. People coming from Flash Open
> Source will remember MTASC compiler back in 2004-5. If you search and
> investigate you will found that haxe is very powerful and is "the great
> unknown technology".
>
> http://haxe.org/
>
> haxeNME is like Adobe AIR and seems to be more performant in iOS, and
> Android (see
> http://esdot.ca/site/2012/performance-showdown-starling-vs-nd2d-vs-genome2d-vs-haxe-nme).
> Supports as well Windows, Mac, Linux and BB.
>
> http://www.haxenme.org/
>
> There's an haxe plugin for IntelliJ. But in my test it seems that only
> supports haxe and not NME yet.
>
> (Disclaimer: I'm to new to haxe and haxeNME and maybe I wrong making some
> statements here).
>
> - Haxe is OOP and is "one language to rule them all" philoshopy.
>
> - Haxe compiler is better that the set provided by Adobe (I'm referring to
> AS3 legacy compiler. Falcon is new technology and maybe this is not true. I
> does not have any info to make a comparision between falcon and haxe
> compiler).
>
> - Haxe language is more evolved (maybe even Adobe AS4 will copy things from
> haxe...)
>
> - Haxe support HTML5/JS out of the box (but it seems to be in beta status).
>
> - There's a Starling port in haxe.
>
> Regarding Flex: haxe compiler could bring to flex things like *metadata
> evolution* or *AOP*. Adobe compiler will never get that evolution since
> gamming is not focused in that kind of things...This is more likely to see
> in haxe if Flex 5 works than expect it from Adobe.
>
> Drawbacks:
>
> IDE: IntelliJ+haxe plugin. IntelliJ is the best option for Flex, and
> supports haxe, but I think haxeNME is not supported yet. But IntelliJ guys
> are behind the plugin, so things could evolve ok in this point.
>
> MXML: I think there's nothing like MXML in haxe today, and this is one of
> the key points in Flex. We would need to put the efforts of MXML in making
> it possible in haxe. We could talk with Nicolas Canesse about this
> possibility. Since Falcon has little support of MXML, I see we don't loose
> almost nothing.
>
> So my proposal is:
>
> * Start Flex 5 from scratch with haxe.
>
> * Use the Flex 4 API to model Flex 5 over haxe (as the first draft).
>
> * Start using Starling haxe library as the core displayobject API (to be
> able to target Stage3D/Workers in  Flash).
>
> * Make an UIComponent decoupled implementation based on composition over
> inheritance (here experience of Alex Harui and other will be very wellcome
> to start with a good foundation).
>
> Optional:
>
> * Take into account the SWF and HTML5 outputs in the first drafts.
>
> This would start as an experiment based on fun of coding, and we could see
> where it goes over time. If it gets momentum, people join the cause, and so
> on...
>
> --
> Carlos Rovira
> Director de Tecnología
> M: +34 607 22 60 05
> F:  +34 912 35 57 77
> http://www.codeoscopic.com
> http://www.directwriter.es
> http://www.avant2.es

-- 
Best regards. 

Eugene Krevenets. Software Engineer of Realaxy.

Blog: http://anykeytocreate.blogspot.com
Code: http://hyzhak.github.com
linkedIn: http://me.linkedin.com/in/eugenekrevenets

RE: Flex 5 in haxe

["Michael A. Labriola" <la...@digitalprimates.net>]

>I'm guessing that this is because the major companies who used to use Flex and swore that they had plenty of compiler engineers who would help finish Falcon have moved on to other >technologies.

Just to speak for all of those companies, much of this happened at the Flex summit. When many of these companies pledged their support, it was within the context of lobbying Adobe to contribute both the FalconAS and FalconJS code, knowing it was not nearly final form and in many cases prototype code, in December/11 or January/12 and for Adobe to finish their development in the open with community help. Within that context, many companies said they would contribute compiler engineering resources to move along the effort, finish the MXML piece and work on the JS piece.

None of those prerequisites happened and the Falcon code finally made it in September. This is not a comment on when we received the code... just a defense to the many well intentioned companies who are likely no longer here to speak for themselves.

Mike

RE: Flex 5 in haxe

[Gordon Smith <go...@adobe.com>]

> Since Falcon has little support of MXML, I see we don't loose almost nothing.

Given that Falcon can compile MXML apps like Checkinapp, I don't think it's accurate to characterize its level of MXML support as "little". My own characterization would be "80% complete". But completing the other 20% is a daunting task ( it's certainly many person-months of work) and not enough people are stepping up to help. I'm guessing that this is because the major companies who used to use Flex and swore that they had plenty of compiler engineers who would help finish Falcon have moved on to other technologies.

So I agree that any and all compiler technologies, including Haxe, should get serious consideration.

However, I think before Apache Flex makes a compiler decision, it needs to decide what runtimes it is targeting. Move to V12? Abandon Flash? Produce HTML/JS? Produce native iOS code? Produce native Java for Android?

- Gordon


-----Original Message-----
From: carlos.rovira@gmail.com [mailto:carlos.rovira@gmail.com] On Behalf Of Carlos Rovira
Sent: Friday, November 16, 2012 2:49 AM
To: flex-dev@incubator.apache.org
Subject: Flex 5 in haxe

Hi,

as we were discussing yesterday, there's room to a new Flex framework written from scratch. As we don't want to rely in Adobe technologies anymore we were talking about haxe. We can make it now that work would be starting from zero.

Haxe is a platform developed by Nicolas Canesse that made it's own community. Nicolas is a genius of compilers. People coming from Flash Open Source will remember MTASC compiler back in 2004-5. If you search and investigate you will found that haxe is very powerful and is "the great unknown technology".

http://haxe.org/

haxeNME is like Adobe AIR and seems to be more performant in iOS, and Android (see http://esdot.ca/site/2012/performance-showdown-starling-vs-nd2d-vs-genome2d-vs-haxe-nme).
Supports as well Windows, Mac, Linux and BB.

http://www.haxenme.org/

There's an haxe plugin for IntelliJ. But in my test it seems that only supports haxe and not NME yet.

(Disclaimer: I'm to new to haxe and haxeNME and maybe I wrong making some statements here).

- Haxe is OOP and is "one language to rule them all" philoshopy.

- Haxe compiler is better that the set provided by Adobe (I'm referring to
AS3 legacy compiler. Falcon is new technology and maybe this is not true. I does not have any info to make a comparision between falcon and haxe compiler).

- Haxe language is more evolved (maybe even Adobe AS4 will copy things from
haxe...)

- Haxe support HTML5/JS out of the box (but it seems to be in beta status).

- There's a Starling port in haxe.

Regarding Flex: haxe compiler could bring to flex things like *metadata
evolution* or *AOP*. Adobe compiler will never get that evolution since gamming is not focused in that kind of things...This is more likely to see in haxe if Flex 5 works than expect it from Adobe.

Drawbacks:

IDE: IntelliJ+haxe plugin. IntelliJ is the best option for Flex, and supports haxe, but I think haxeNME is not supported yet. But IntelliJ guys are behind the plugin, so things could evolve ok in this point.

MXML: I think there's nothing like MXML in haxe today, and this is one of the key points in Flex. We would need to put the efforts of MXML in making it possible in haxe. We could talk with Nicolas Canesse about this possibility. Since Falcon has little support of MXML, I see we don't loose almost nothing.

So my proposal is:

* Start Flex 5 from scratch with haxe.

* Use the Flex 4 API to model Flex 5 over haxe (as the first draft).

* Start using Starling haxe library as the core displayobject API (to be able to target Stage3D/Workers in  Flash).

* Make an UIComponent decoupled implementation based on composition over inheritance (here experience of Alex Harui and other will be very wellcome to start with a good foundation).

Optional:

* Take into account the SWF and HTML5 outputs in the first drafts.

This would start as an experiment based on fun of coding, and we could see where it goes over time. If it gets momentum, people join the cause, and so on...



--
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F:  +34 912 35 57 77
http://www.codeoscopic.com
http://www.directwriter.es
http://www.avant2.es