7 reasons to write in ActionScript

There seemed to be some disagreement about my previous post on InsideRIA about moving your Flex Components from MXML to an ActionScript only base. The article was intended to teach readers about the Flex Component lifecycle; but backed into it by starting with an easy MXML only component and iterating it to an AS3 only component. Each code iteration introduced elements of the component lifecycle.

I have to admit, I never expected to run into an anti-AS3 sentiment in the comments. MXML and ActionScript both have their purpose when building Flex applications. I find MXML is great for layout purposes. I feel that ActionScript is superior and gives you a lot more control over the code you write; how it executes; and when. MXML often masks these details. The Flex Framework was built entirely in ActionScript; and surely the Adobe engineers made that decision for a reason.

I wasn’t quite sure how to articulate my pro-ActionScript thoughts, so I polled some twitter friends to help me articulate my thoughts. Here are five reasons why I prefer ActionScript:

1. Constructors: In MXML you can’t create a constructor method. This can be worked around by listening to framework lifecycle events. The preinitialize event is most appropriate event to listen to, although in my experience creationComplete is more commonly use.
2. MXML Is turned into AS3: MXML is translated into ActionScript 3 by the Flex Compiler. You can view the generated source by specifying the -keep-generated-actionscript compiler argument. Take a look at the code; you’ll be surprised at how complex it can be. If you write in AS3 from the start, your components are not converted. I find that starting with AS3 creates cleaner code from the start.
3. Order of Execution is Clear: MXML can make layout quick and easy, but it often masks what is actually going on. In MXML, you can specify properties, styles, and event listeners all in-line as attributes to the MXML tag. When are your properties set? When are styles set? When are event listeners created? When are the children for your container created? MXML masks these details; ActionScript does not.
4. Debugging is Easier: Have you ever been stepping through code with the Flex Debugger only to find that the debugger lands on a line of MXML and you don’t know why? It can be frustrating because you don’t know if you’re updating a property, changing a style, or firing off an event. With ActionScript, this is a non issue.
5. Portability: MXML code is tied to the Flex Compiler, whereas ActionScript 3 code is portable and can be used elsewhere, such as with Flash Professional. Even the Flex Framework can be used without the Flex Compiler, although you’ll have to take it on yourself initialize the appropriate Managers on your own. There is some posts about this here and here ) and here. Over time, I would hope that Adobe makes it easier to share the Flex Framework Components with other IDEs; independent of the Flex Compiler.
6. ASDocs: In Flex 2, and 3, MXML didn’t support ASDocs. If you’re building code for an earlier framework, you’re not able to make use of this powerful tool for documenting your API. Flex 4 has added ASDoc support to MMXL files; but if you haven’t upgraded your applications to Flex 4 yet, this is still be a limitation.
7. Performance: MXML can lead itself to overuse of containers; at least in many apps I’ve seen. Some Flex Containers can have costly layout procedures, especially since they inherits all the layout logic of its hierarchy chain. Lots of embedded containers can cause performance issues. Sometimes you don’t always need to make use of those containers; and you can create a simpler use. The Flex 4 Spark architecture addresses the multiple layouts issue in part by encapsulating the layout logic away from the container. Sometimes extending UIComponent and sizing and positioning elements yourself will result in more efficient code.

I don’t intend this post as an anti-MXML post. It is serves its’ purpose and allows you to get up to speed quickly. The biggest complaint in the comments of my previous posts against the use of AS3 is that long-term maintenance is easier in MXML. In some cases I can accept that; but I'm not sure that is always true. It is our job, as programmers, to consider all approaches and then choose the approach that is appropriate given our time, budget, and project goals.