incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Cunliffe <mahn...@gmail.com>
Subject Re: Flex 5 in haxe
Date Fri, 16 Nov 2012 23:18:00 GMT
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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message