Announcing “Project FlaXe”, a vision for the future of Flex

haxe logoAs you’ll likely know, if such things interest you, Adobe pretty much succeeded in killing off Flash last week. They made nearly 10% of their staff redundant. They abandoned the Flash player for mobile browsers. They possibly made most of the Flash Pro “IDE” team redundant (though what has really happened to that team remains unclear.) And late Friday, they announced that they were pulling out of future Flex development and handing Flex over to the community.

The timing of these announcements by Adobe is regrettable. They have spooked the community and left many of us who build on Flash technologies as part of our business unsure of the short to medium term future of Flash. Yet there is currently no alternative RIA solution that can equal Flex. What other solutions there are use very different technologies. making migration difficult at best.

This set me thinking: could the community create a way of migrating existing Flex solutions away from the Flash player? The fact that the SDK will be handed over to an open source foundation offers a way of achieving this: compile Flex solutions to targets other than the Flash player. One way of doing this would be to take the mxmlc compiler code (which is part of the Flex SDK and thus maybe open for community modification too) and add a new backend to it that outputs JavaScript for example. A more exciting possibility though is haXe. Since its launch in 2006, AS3 has changed very little and so has become a somewhat outdated and stagnant language. As Adobe have shown no interest in evolving the language, Nicolas Cannasse developed a replacement for it: haXe. haXe is a more up-to-date, powerful and all-round-better language than AS3. In addition, it can be compiled to the Flash player, JavaScript, the command line and versions to output to Java, C# and iOS are being worked on. However haXe does have one weakness: the only interoperability between it and AS3 lies with the Flash player target, by using SWCs.

So I’m proposing “Project FlaXe” to address that and to turn haXe into a first-class Flex programming language. The steps involved are still a bit undefined at this stage as I’m rapidly trying to research a number of ideas and solutions, but they go something like:

  1. Create or identify a suitable existing AS3 lexical analyser and parser.
  2. Create a utility that uses that parser plus haXe generation routines to create a utility that can read an AS3 source file and output the equivalent haXe source file.
  3. Use this utility to process the whole of the Flex SDK and to generate the haXe equivalent: FlaXe.
  4. Identify those builtin classes used by Flex that are not yet supported by haXe and create haXe versions.
  5. Use the utility to convert existing Flex applications, robot legs and other essential AS3 frameworks and libraries into haXe code.
  6. Initially compile those haXe solutions for the Flash player to allow life to continue as normal for a time.
  7. Start working on optimising those haXe solutions, the FlaXe SDK etc to enable them to run in a fast fashion when compiled to JavaScript and wave goodbye to a dying Flash player.

For stage one, at least two possible starting points exist. Firstly, as previously mentioned, the source for the mxmlc compiler is available and – subject to there being no sticking points with license terms – could be used to provide the parser, with the back end being replaced with a haXe generator. Another possibility is the asblocks and jasblocks projects by Michael Schmalle that appear to offer both AS3 (could be self-complied into haXe maybe?) and Java parsers for reading AS3 files.

If this project interests you and you’d like to get involved in some way, know of any flaws to the idea, or have some good suggestions, please leave a comment or drop me an email at david at davidarno. org.

8 thoughts on “Announcing “Project FlaXe”, a vision for the future of Flex

  1. I do agree that this effort is a really good idea. Although I do think that the flex AS3 classes are ill conceived and could be re-written and re-factored to remove the monolithic dependency on UIComponent[1] for example (others also exist) and use composition rather than inheritance (or other design patterns i.e. mixins).

    Even removing the need for the EventDispatcher altogether would be a great move.


  2. Flash is only abandoned on the mobile platform and this platform has really specific needs like memory consumption. I would be really surprised that a brute force conversion from flex to JS gave you the expected results targeting mobiles.

    I have made the Flex->JavaScript transition on my mains projects near than two years ago. I’m now considering the Desktop JavaScript->Mobile JavaScript transition. You know me, I’ve used PureMVC. Using the same logic used in ActionScript to JavaScript was not a real problem. But UI Components in JavaScript have to rely on specific framework. The real work is here and I don’t think you’ll be able to easily convert Flex UI to let say jQuery or YUI or what…

  3. I have to agree with Tekpool; if AVM2 is too much of a hog to run on a mobile (I still have my doubts about that), so much more so if the bulk of it is ported to Javascript and has to re-interpret AS3 through an interpreted language. A better way to go might be wrapping some kind of relatively high-performance screen graph JS library in haXe and then bridging that with the incoming Flex code in a clever way. A lot of work. I started on a project to bring AS3-ish drawing to canvas about a year ago, but haven’t had much time to go further with it; however you might want to look into the SDK I started, as at least a lot of the basic draw functionality is there, and it could be wrapped with haXe and used in the way you’re thinking of. It’s at:
    and of course it’s free to use or modify, and I’d love to see something useful happen with it, especially right now when I’m looking for answers myself to how I’m going to be building apps a year or two from now if Flex/Flash is no longer a viable option. (Personally, I’m really hoping to see FP10 libraries built out for Jangaroo and never have to get this crazy with Javascript again as long as I live).

  4. @bili,

    Possibly. I’d anticipate that points 1 – 6 will take a few months of just me doing it in my spare time. Point 7 is a mammoth task though that I could never hope to achieve myself, but with help it could be achievable within a year. Maybe I am being naive though.

  5. Transcribed in english, Flaxe reads, on first glance, as flakes. You probably don’t want to name it that, as it normally refers to someone unreliable.

Comments are closed.