Thoughts on Apache Flex Proposal

Adobe has submitted a proposal to accept their Cindyflexingrella to a very reputable orphanage: Apache Software Foundation. Overall, this can be a great news for the Flex community, which as opposed to Adobe, can afford to allocate enough of strong software engineers to make this framework flourish.

There were lots of applications for becoming initial committer to this new Apache Flex project. Only 25 of them made the list, and I’m happy to report that Farata’s own Anatole Tartakovsky has been accepted to this list. Just to make sure you understand Anatole’s caliber, I can tell you that five years ago he sifted through 16 thousand lines of code of Flex most complex component – DataGrid – and turned it into a more elegant object by removing about a half of its code. Back than, we had no easy way to make this component a part of Flex SDK.

The list of committers includes a number of people knowing really well what Flex has under its skin: Alex Harui, Michael Labriola, Peter Elst, to name a few. So the brain power is in place. But there are two sections in this proposal that bother me:

Known risks.
Moving from a corporate-led project to the Apache model of collaboration is a challenge, and Adobe is committed to help making the transition as smooth as possible, by delegating employees to work on the new project. We would like to see more free collaboration from the community but with the same principles that has kept Flex with the high-quality design and ease-of-use it has maintained under Adobe’s governing hand.

If I’d read this paragraph two months ago, it would sound great to me. Not anymore. It includes the words “Adobe is committed to…”. Sorry, can’t trust to any commitments made by this company that published an that infamous blog on a day that should be remembered as 11/9.

The second section that can kill this project is titled “External Dependencies”, but should be renamed into “Strings Attached”:

Some parts of Flex development rely on third-party libraries. The complete list is still being determined but some are:
• Adobe AIR SDK
• Adobe Flash Player SDK
• Adobe Text Layout Framework (TLF)
• Adobe Open Source Media Framework (OSMF)
• Adobe Font Engine (AFE)

Flash Player is a VM. Flex framework is pretty much useless if a VM won’t support it. Even if the next version of Apache Flex will include some killer features, how good it is if Flash Player won’t support them? It’s hard to believe that Adobe will plan future releases of Flash Player based on the needs of Apache Flex. I don’t like the phrase “We have made it clear to our community that going forward, the community, rather than Adobe, will determine the future of Flex.” Dear Adobe, we can’t determine the future unless you open source Flash Player. Open source might have an alternative though – not to use Flash Player as a runtime. Flex compiler makes a couple of passes producing first the ABC code (ActionScript Byte Code), and only then the byte code for Flash Player to run. If an open source community will come up with a compiler to turn ABC code into another run-time engine, Flash Player won’t be needed (this is how Adobe AIR apps get deployed in iOS now). But what other runtime?

The other big ticket item is Adobe AIR SDK. This is an great SDK for cross-platform desktop and mobile software development. AIR relies heavily on Flex SDK, and keeping in sink future releases of Apache Flex and Adobe AIR is not a trivial task.

What about the tooling? Flash Builder is always lagging behind, but Flex developers are using it. The proposal reads, “The existing Flash Builder trademark will be used as a commercial entity.” I’d rather see Flash Builder at Apache, but this is not a show stopper. JetBrains IntelliJ IDEA is a better IDE than Flash Builder and, hopefully, they’ll become a tool of choice for Apache Flex developers.

To summarize, I’m glad that Flex framework is given to the public, but the sky is not as bright as I’d wish it to be.

To make this post somewhat technical, I’m including a code fragment that Flex developers will understand.

    <s:Transition id="greatMove" fromState="Adobe" toState="Apache"> 
       <s:Sequence id="t1" targets="{[p2]}"> 
           <s:Wipe id="ADBE" direction="left" duration="1000"/> 
          <mx:Glow id="ApacheFlex" duration="1000000" alphaFrom="1.0" 
                    alphaTo="0.3" color="0x00FF00"/> 

I didn’t even try to compile the code above. Feel free to try it out, improve, and submit back to share with Apache Flex community.

Yakov Fain

11 thoughts on “Thoughts on Apache Flex Proposal

  1. Great post, Yakov. I’ve commented in the ASF incubator mailing lists, and I have voiced the same concerns you have regarding the fact that a compiler without a runtime environment or VM is not of much use. Maybe you should sent out a comment on the FlexProposal to the ASF incubator mailing lists, here’s the thread:

  2. This isn’t even close:

    IF: Flex depends on the Flash VM.
    AND: The Flash VM is controlled by a company that clearly doesn’t give a crap about Flex.
    THEN: Flex has no future.

    This is quite sad really. I like Flex, invested time and money into it. I went to MAX 2011 to really dive into it and hear Adobe talk about it’s bright future. A few weeks later they incompetently pulled the plug on it. That is kind of the definition of betrayal. There’s a lot of things that go into building successful platforms and a big one is that the platform provider doesn’t screw it’s developers.

  3. Our latest Flex project was scrapped and overnight I became an iOS developer. Unless we get an announcement to open source the runtime *very* soon, I don’t see much of a future. The attrition rates will continue to rise and nobody will be left. I don’t use Flash/Flex *even for fun* personal projects now because Adobe has sapped all of the joy out of it. An open source VM might bring devs back into the fold but it would have to be announced soon because the community is moving on and the more time they spend away, the more likely it is they will never come back.

  4. One of the main reason for developing in Flex is a ubiquitous runtime – Flash Player. This is something that neither Microsoft nor Oracle were able to pull off with their RIA products, and as a result, they failed. Not sure if Adobe earns any licensing fees from Flash Player, but If this is not the case, then Adobe might want to kill Apache Flex on purpose by not offering up to date runtime.

  5. I don’t get this concern of Flash Player VM “not supporting” Flex in the future.
    Other than signed RSL’s I dont see anything in the Flash Player VM today that is built specifically to support Flex, and Flex did fine so far.
    Adobe’s stated areas of future innovation for the VM are “gaming” and “video”, which I would think implies better display performance, multi-threading etc. all of which can be leveraged by Apache Flex for huge wins. The concern IMO, should be more like can Apache Flex, effectively leverage all future enhancements that will be made to the VM.

    Unless Adobe decides to kill Flash Player VM / AIR, thereby backtracking on their stated agenda of pushing the envelope forward in gaming and video, I do’nt see how this is a real concern. Maybe I am missing something ?

    • I don’t know what can go wrong, but by having separate owners of two dependent pieces of software clearly introduces an integration phase for all future releases. Will Adobe’s plans/schedules match with the needs of Apache Flex? I don’t know, but most likely they won’t match. Hopefully, Adobe won’t make another reorg pulling off everyone who might be dealing with Apache Flex.

    • I don’t think that creation of a code generator turning Flex code that runs in the compiled mode inside a VM into interpreted JavaScript is an easy job. IMO, Flex code should run in the VM while JS code should be originally written in JS.

      Many years ago Google introduced GWT, which allows you to write code in Java, which is automatically converted into JS. But, for some reason, GWT never became a popular tool among Web developers. Flex-to-JS may be possible, but using JS frameworks will be a preferable way for creating JS Web applications.

  6. I invested time and money in flash/flex technology. Adobe promised a lot and made u-turn out of blue to me. I know Flex/JS won’t work that well & it’s too far away from reality. GTW never took off as expected but didn’t die either.

    I wonder what alternative technology we can consider if Adobe pull plug on flash/air or late in updating flash version. As many developer I will be also look out for something else…

  7. Adobe is giving a bad impression to enterprise world for no reason. I am working on flex projects for 20 months and like it. It seems no flash on apple makes such huge difference on revenue is shocking to me. Android and OS support flash on tablets and smart phone, which makes good percentage of user coverage. I don’t understand why a company stops such big development after a record revenue quarter. As a developer I don’t understand but don’t have a lot of faith in Adobe and looking at other technologies for future projects.

Comments are closed.