A couple of weeks back, you may have seen my tweets suggesting that I was interested in adding support for MXML to Feathers. I spent an afternoon digging into the source code for the Apache Flex compiler, and it became clear to me that I know where and how to modify the compiler to add support for Starling and Feathers.
Would MXML (and binding) support for Feathers improve your team's productivity? Enough that your company would sponsor its development?
— Josh Tynjala (@joshtynjala) January 23, 2015
Jumped into the code for the Apache Flex MXML compiler yesterday. Figured out some of the things I could modify to support Feathers binding.
— Josh Tynjala (@joshtynjala) January 23, 2015
Earlier that day I made some changes to the Java code for the compiler, rebuilt the binaries, and dropped a modified Apache Flex SDK into Flash Builder. The compiler errors that were normally caused by attempting to use binding with Feathers components went away, and I verified the code generated with the
-keep compiler argument. It still needed work, but it looked good. I knew that I could do this.
I understand that some developers have no interest in using MXML with Feathers. Others find it essential for the types of enterprise apps that they want to build. It’s important for me to find the right balance helping both types of developers. Not only at the technical level (keeping performance and backwards compatibility in mind), but also by managing my time fairly. With that in mind, I felt that working on MXML support needed to be a separate effort from my day to day work with the ActionScript UI components. I have some free time that normally goes to various side projects or consulting, but I’d love to spend extra hours making Feathers better. Those other projects help pay the bills, though, so some extra funding is important. That’s why I was looking for a sponsor, and I knew that many developers working on enterprise apps would see increase productivity with MXML support, so it seemed like the right approach.
A number of eager developers suggested Kickstarter. I’m totally open to crowdfunding advanced Feathers components and tools (I have more ideas for the future), but I wanted to see if a company would step forward — similar to Adobe — to become an official sponsor of Feathers. Not long after I posted those tweets, the folks at YETi CGI contacted me, and we set up a call. We quickly discovered that our shared desires to improve and promote the Flash and AIR ecosystem align very well.
Today, I’m happy to announce that it’s official: MXML support for Feathers is going to happen. I have lot of work ahead of me, and I’ll be sharing my progress in the coming months. Keep watching this blog, and follow me on Twitter for details. If you have any questions, check out the FAQ that I put together below. Thanks!
Frequently Asked Questions
- What features of MXML will be supported?
You will be able to add components as children of containers, set properties, listen for events, add
[Bindable]metadata, and use curly braces to bind data to properties.
- What features of MXML will not be supported?
- Currently, I have no plans to support adding custom states to components in MXML. However, I am always open to community feedback, and if adding custom states is something that a lot of people ask for, that’s something that I can work on after the first release is finished.
- Modifying the compiler? This project sounds like a lot of work. As a lone developer, can you do this on your own?
- This project is certainly not trivial. However, I have studied the relevant compiler source code in detail (and the ActionScript classes that are used for binding), and I know which parts need modifications. I already built some simple prototypes. I successfully modified the generated ActionScript to remove some compiler errors, and I switched some of the code to use Starling or Feathers APIs instead of Flex APIs. There’s still a lot that needs to be done. I won’t deny that. I expect to spend at least three months (part-time) getting it to a feature-complete beta stage. However, I’m very confident that the conversion from Flex to Feathers will go smoothly and at a steady pace.
- Will you spend all of your time adding MXML support while the rest of Feathers gets ignored?
- Adding MXML support to Feathers will not take time away from any other aspect of Feathers. I normally have free hours every month where I work on side projects that have nothing to do with Feathers. I wanted sponsorship for this project so that I can allocate some of those extra hours to Feathers instead. In other words, I will continue working on the Feathers ActionScript components just as much as I have in the past.
- What if I don’t need MXML support? I just want to keep using Feathers the way that I do today with pure ActionScript.
- Using MXML with Feathers will be completely optional. Your existing ActionScript code will not need to be changed at all.
- Will using MXML have a performance impact? Will there be any kind of performance impact on projects that don’t need MXML?
- Will there be any preview builds?
- Yes. I expect to release one or more preview builds as progress is made. They will be available to anyone who wants to try them. These builds may be unstable, and some features may still be missing. However, anyone will have a chance to give them a try and offer feedback. Once MXML support is feature complete, I expect to release a beta build that a larger audience will be interested in. After all the major bugs are worked out, I’ll release the final stable version.
- Who is sponsoring this project?
- I’d like to thank YETi CGI for their generous support.
First, let me be clear that if your project doesn’t require MXML, Feathers will behave and perform the same as it does today. If I couldn’t make that promise, I wouldn’t be interested in going forward with this project.
Most features of MXML are simply a convenient abstraction to avoid writing a lot of ActionScript. The ActionScript code generated behind the scenes by MXML for things like creating components, adding children to containers, setting properties, and listening for events will look very similar to what you would write when doing those things yourself. I don’t expect any performance impact from using these basic features.
Data binding can involve a lot of event listeners, and it may require some extra garbage collection when it gets used. This may have a small impact on performance, if you’re not careful, at least on mobile. However, data binding in Feathers may end up performing better than it does in Flex because we can take advantage of Starling’s event pooling.
Have any other questions or concerns? Please feel free to ask in the comments.