Sunday, April 18, 2010

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.

Labels: , ,

3 Comments:

At August 22, 2010 at 8:52 AM , Anonymous John Shaffstall said...

Why not both? All the reasons you give for not using MXML is why ActionScript exists. Ever think of that? I like the pair. I think they work well together and are very good at each of their intended purposes. I don't know about you, but leaks, abstraction, size and speed aren't big concerns of mine anymore. Functionality, behavior and presentation are my concerns as it should be these days with such high level development environments and languages. Get over the nit picky details and enjoy the gigabytes of ram, the gigahertz of processor speeds, the tons of harddrive storage, the unbeleivable graphics and just build, build, build. Since I switched to Flex 3 for Web Apps from C++ for Desktop Apps, I am 4 times more productive. Things get done with Flex. Period. Don't knock it, enjoy it.

 
At August 16, 2011 at 8:08 PM , Anonymous Magic said...

Hi John, your tone seem very strong, seem you hadn't meet troubles issues about memory, speed apps, and some secret bugs when working with composite component and in all your time develop apps, if that you're superman.

I think these topics that Prashant accentuate is useful.

 
At March 8, 2012 at 6:16 PM , Blogger ajing said...

Hi John, you cannot assume all your customers or user of your product will have the same level of specification as your development environment. For us, we are developing and supporting a flex-based banking system with employees only using windows xp on a dual core cpu with only 2 gb mem. This specs are standard to all their 2000 employees spanning different countries. Aside from functionality, we are really keen at looking at the performance specially memory. Kudos to you Prashant, your blogs, specially this one had helped us alot.

 

Post a Comment

Subscribe to Post Comments [Atom]

<< Home