Why ActionScript and why not MXML. [ActionScript vs MXML]

1. You cannot add new childrens to complex components via MXML, you have to use ActionScript.

2. MXML encourages inline event listners and curly brace bindings. These event listeners and bindings are difficult to remove.

3. Compiler creates a lot of ComponentDescriptors. Components created from ComponentDescriptors create a lot of objects (Function, Object, ChildDescriptor etc). This can affect the overall performance, memory and load time.

4. All controls/components declared in mxml have a public scope. This breaks encapsulation.

5. MXML inline event listeners are always in bubble phase. This is really not a problem but just worth mentioning.

6. MXML components create a lot of references e.g. component descriptors, watchers, binding and function objects etc. These references are like noise and make it difficult to analyze memory leaks.

7. In MXML, you cannot use a component as a Singleton.

8. MXML components create a large object graph (component descriptors, bindings, watchers, watcherSetupUtils etc etc) which can be difficult for the GC to analyze. ActionScript components on the other hand are light weight (compared to MXML components) with a lot fewer references. This makes it easy for the GC to analyze the object graph and garbage collect them.
Remember, Flash GC is not forward progressing and incremental. If a large object graph cannot be analyzed in the limited time the GC gets, all objects in the object graph will start leaking.

9. There are many things not possible in an MXML component. I once tried setting a "this" on a static variable in an MXML component but kept getting an error. I could have easily done that in an ActionScript components constructor.

10. Try "override mx_internal someBaseClassMethod()" in an MXML component. I have done a test project where I extended the Canvas component and created an MXML and ActionScript component to test the "override mx_internal someBaseClassMethod()". Got errors in the MXML component (and eventually could not do it) but Actionscript component worked like a charm.

11. The compiler creates a lot of files/ additional functions, addtional getter/setters, private variables for every MXML class. className-generated.as, className-watcherSetupUtils and a few more files that I don't remember but can look it up. Every inline event listener is wrapped in a compiler-generated public function.

12. CTRL + SHIFT + O in Flex/Flash Builder removes unwanted imports in .as files. This doesn't work in .mxml files.

13. Try using a custom component that extends UIComponent in mxml and add a child to it ...

class MyUIComponent extends UIComponent { ... }
[now use the above custom component in an mxml application] 

    

The application will not compile and it will throw an error. But this should be very easy to do it ActionScript.

14. Cannot conditionally create objects. This is a very important for performance and memory. Let me explain this with an example. I have a component which displays a warning image under certain conditions. If the condition is not met, why create the Image component and display nothing. Creating less objects will speed up loading time for the view, consume less memory and the overall ui will be a lot more responsive and snappier.

15. ... and I am sure many more drawbacks that I have not encountered.

The positive side of MXML components is declarative programming/ inline bindings/ inline events but they all come with a cost.

I literally live in the world of Flex profiling and I notice thousands of objects (bindings etc) that could have been avoided and some memory and performance could have been gained. But alas, not every Flex programmer loves coding in ActionScript.

Feel free to add your experiences and views regarding ActionScript/MXML in the comments.