19 Replies Latest reply on Aug 27, 2007 2:34 PM by brado77

    Pure Actionscript vs. MXML

    brado77
      I understand that the answer to this question may be mostly subjective to some, but I'm trying to zero in on the objective part. In developing my apps, I am finding a regular tension between having my Flex components developed in MXML vs. Actionscript. I wanted to ask a general question, and again, trying to be objective as possible, is it better to develop Flex components in MXML or in pure Actionscript?

      While MXML of course let's you perform WYSIWYG development in Flex Builder's GUI editor, I have run into things that can't be done very gracefully in MXML, reuse of MXML components can become cumbersome, and there's a lack of control of loading and unloading of components in MXML, which you can accomplish in Actionscript much better.

      I have noticed that what I have seen of the Flex API is pure Actionscript, which would indicate a lean toward Actionscript, but then I've seen code snippets for components in various places on the web posted in MXML.

      So to try to get down to the crux of the matter -- is it inherently better to develop Flex components in pure Actionscript or in MXML, and why?

      Thanks -- I'm curious as to community responses....

      B
        • 1. Re: Pure Actionscript vs. MXML

          Well, unfortunately Adobe supports MXML more that AS 3. Their documentation examples are almost all in MXML. During the Flex 2 beta, there was no way to do binding besides MXML. (You could bind TO something in AS 3 but not make something bindable. Or maybe it was the other way around, I can't remember.)

          Having said that, I do everything in AS 3. I don't understand the point of MXML. I don't get it. More importantly, if I want to hire anyone to work on my app, I'm not going to hire Flex developers, I'm going to hire Java developers and teach them Flex. The pool of java developers is much bigger, and I'm sorry, but the *average* java developer is better than the *average* flash/flex developer. (You have to factor in that a whole lot of flash developers are ex-designers, bringing down the average.) Teaching a java developer AS 3 is pretty easy. MXML isn't.

          And I've never done WYSIWYG software development in my entire life. I learned that lesson 10 years ago with HTML editors.

          (now, go help me with my percentageheight problem in the general forum),

          tm
          • 2. Re: Pure Actionscript vs. MXML
            brado77 Level 1
            TankMan,

            Thanks for the reply. Assuming that the need to hire Java developers isn't an issue, it seems that the only technical issue you've raised actually supports writing in MXML, not Actionscript. If Adobe doesn't support Actionscript to the degree that they support MXML, and all samples and tutorials cater to MXML, this would seem a fair reason to orient to MXML, not Actionscript.

            If anyone finds any documentation which speaks to the comparison between AS and MXML, please post it....I am really interested.

            Thanks,

            Brad
            • 3. Pure Actionscript vs. MXML
              levancho Level 3
              I think MXML is extremely important part of Flex, not just on its own but with balanced mix of AS3, as you know mxml, burdens responsibility of visually representing application layout and that is the primary reason it should be used for,it is less powerful than AS3 but thats meant to be that way,
              for example I cant find a way to implement more than one interface with MXML, or remove inline even listener, things like that .. (but I realize if I need that much from component I better change it into AS3).
              I do not believe its possible to develop full fledged flex application only in mxml or with minimal AS3 , but on the same side I could say same thing about AS3, because I guarantee complex application layout with AS3 are almost impossible or very time consuming. so to get to the point, the True Power of flex is in ability to give you both of the world,
              to me philosophy comes down tho following :
              to Have custom VISUAL Component development with MXML file.mixed with AS3 initialization code for things like to create initial event listening on component level etc .... so I have package full of custom MXML files extending etxinput texatera etc ... with built in AS initializing code.
              and I do reuse them without any issue.

              for App Logic, Security, everything NON VISUAL -- I have ONLY AS3.
              for Services? hmm its arguable, I also have mixed, 90% is AS3 but then my concrete ServiceLocator class has all my httpServices in and its is MXML (its easier to organize services that way) (again a nice balanced mix of both worlds)
              and lastly mxml learning curve is minimal , not sure what part of mxml is not easy? its just another markup, or better yet just another M(*cough*) XML

              • 4. Re: Pure Actionscript vs. MXML
                brado77 Level 1
                levancho,

                Thanks for the reply. With your GUI components you develop in MXML, how do you control conditional loading of components? This was a major road-block I ran into when coding in MXML. I found that I had little control over when subcomponents were loaded and unloaded, either for performance/memory purposes or for behavioral purposes. For example, the createComplete() event on an MXML component fires when the component is rendered, I believe, which creates a difficulty if you want certain initialization behavior to take place prior to rendering (i.e. at component creation time, for instance). I have also experienced certain rendering blips that the user can see when developing with MXML, which I have rectified by doing certain initialization in AS3 prior to the rendering of the component.

                Likewise, it seems that reuse of components, i.e. extending base compoonents became more cumbersome. For instance, you have no control over MXML constructors. You also cannot override a component that exists in MXML markup.

                So I'm kind of trying to balance out all the input here. Adobe has produced their API entirely in AS3. However, most of the tutorials and samples are almost exclusively MXML. Then I have an associate of mine who has a whole company of expert Flex developers, and his comment was that he uses virtually no MXML -- he views MXML as a prototyping convenience, but production apps are done exclusively in AS3.

                As I originally stated, the preference is largely subjective -- but what I'm trying to get at are the techincal reasons to do one over the other. Perhaps given two different opinions in the responses here, I could rephrase the original question to this:

                Is there any technical (not preference, but functional issue) disadvantage to using exclusively AS3? Is there any technical disadvantae to using MXML, rather than exclusive AS3?

                Thanks,

                Brad
                • 5. Re: Pure Actionscript vs. MXML
                  levancho Level 3
                  Regarding Question : conditional loading of components?
                  as you know each Visual component in Flex goes through predefined initialization phase,
                  from very first call to its constructor till it is rendered and displayed on the screen, and it does not matter if component is created with MXML or AS at the end MXML turns into AS and then turns into bytcode, so issue of accessing components properties, etc... at right time is still an issue regardless how component is created, but, the one of the nicest things about Flex is that it gives you access to all key events of object creation lifecycle , and than its up to you how you plan your strategy,
                  for example if creationComple its too late , what about initialize event, or render event, or activate event .. etc etc ...
                  armed with all these events I can do pretty much anything in my little , or big custom components...
                  • 6. Re: Pure Actionscript vs. MXML
                    I had assumed you were already aware of the obvious "technical issue" with MXML, which is that there are things you can't do in MXML, that you need to do in AS 3. Given that fact, MXML is guilty until proven innocent.
                    • 7. Re: Pure Actionscript vs. MXML
                      brado77 Level 1
                      TankMan,

                      quote:

                      I had assumed you were already aware of the obvious "technical issue" with MXML, which is that there are things you can't do in MXML


                      That's the purpose of my post, I'm trying to quantify exactly what cannot be done with MXML that can be done in AS3. So as you know of these, I'd ask, can you list or expound on these limitations? For example, one of the things I'd mentioned, about constructors and the createComplete event, levancho had a very good response about hooking other events in the component lifecycle. He's right -- that really covers that concern, provided that all of those hooks cover the lifecycle as needed (I haven't tested all of them in MXML vs. AS3 yet, but it seems logical that it is the case). So I'd be very interested in hearing what in your view are the primary limitations of MXML that are better handled in AS3.

                      Thanks,

                      Brad
                      • 8. Re: Pure Actionscript vs. MXML
                        Newt99

                        Hey TankMan,

                        Quoting you:

                        "The pool of java developers is much bigger, and I'm sorry, but the *average* java developer is better than the *average* flash/flex developer. (You have to factor in that a whole lot of flash developers are ex-designers, bringing down the average.) Teaching a java developer AS 3 is pretty easy. MXML isn't."

                        You forgot to say that many Java developers don't care about Flex. At work, we had two pure Java developers who were asked to work on a Flex project with two Flash developers (including me). The first Java developer resigned after a while, saying he does not care about Flex, the user experience and UI in general and wanted to do only Java server-side stuff... OK. The second is willing to learn Flex but is worried to be considered too Flashy on the market after a while. So, there seem to be a real moral problem with many Java developers about using Flex....

                        I personally in turn mastered the following display technologies: Java, Director, Flash and Flex.

                        I realized that Java was going nowhere on the client side (with Applets at any rate) and I was right, but I did master OOP, AWT and Swing + server side programming. I haven't switched to Director then Flash then Flex because I cannot program using Java. I did it because I want to use the best technology available to create the best possible UIs.

                        Another thing. Flex is based on the Flash Player so this is a Flash Developer territory also. Many know inside out the Flash player technology and can solve some problems better because they know Flash, not to mention the fact Flash can be used to create assets for Flex such as skins, Flex components and interactive contents not possible in Flex.

                        Flash developers are detail oriented and more aware than the average Java developer about the one thing that truly matters to the end user: the user experience. At work, I can see that no Java developer cares about that (and I'm not talking about their exceeding the Flash player capacity or the display glitches they are causing).

                        I strongly suggest you assess all the value a Flash developer can bring to a Flex team (I never use Photoshop or Illustrator, I leave that to designers who do a great job).

                        • 9. Re: Pure Actionscript vs. MXML
                          brado77 Level 1
                          Guys,

                          I appreciate all the responses, but this is straying off-topic. As mentioned in my original post, I want to avoid the subjective preference for one vs. the other, I want to avoid developer bias, available hirees, etc. -- all of that is completely immaterial for the purpose of my question. The question is aimed directly at technical differences between MXML and Actionscript 3, and capabilities of one not available in the other. There have been posts that have said things like "I prefer X" and "I never work with Y" and "there are things you can do with X but not with Y". While I appreciate those, that doesn't answer the question. The question can be answered by listing *what the specific differences are*, or restated, what do you gain in function / feature by coding in one vs. the other.

                          If I were to try to draw a conclusion from the responses here, it would be hard not to draw the conclusion that the answer is generally unknown, and use of one over the other is more government by personal comfort level and preference than anything.

                          If anyone can produce some concrete technical differences other than the ones I have mentioned, please, let me know.

                          Thanks,

                          Brad
                          • 10. Re: Pure Actionscript vs. MXML
                            brado, as I recall, the Flex documentation explicitly states that MXML is declarative, and therefore limited. You really want us to tell you the exact limitations of being declarative? It isn't evident? Compare HTML to javascript...
                            • 11. Re: Pure Actionscript vs. MXML

                              Newt, your two-person test sample of Java developers isn't exactly a big enough cross-section of the mass to draw any conclusions. You could still be right, but your example neither supports nor refutes your point.

                              You really "mastered" those technologies? Or do you mean you just learned to use them. Because I've known actual "masters" of java, and of Flash, and I'd be pretty suprised if you're as good at all four technologies as they are at their one. Maybe just your choice of words.

                              I don't see how Flash developers generally understand the user experience more than java developers, unless you're talking about Flash developers who are designers and/or ex-designers. In which case, I'm not really interested in bringing that to a team of software engineers.

                              But, sure, if I was hiring someone to specifically do UI work for my Flex project then yea, I could see Flex-specific skills as more useful.


                              • 12. Re: Pure Actionscript vs. MXML
                                brado77 Level 1
                                TankMan,

                                quote:

                                the Flex documentation explicitly states that MXML is declarative, and therefore limited.


                                Something isn't necessarily limited just because it is declarative. In general, what determines limitations is not that it is declarative, it is the degree to which component functionality is accessible declaratively. And at any rate, MXML isn't completely declarative, it allows embedded Actionscript.

                                quote:

                                You really want us to tell you the exact limitations of being declarative? It isn't evident? Compare HTML to javascript...


                                I would like specific examples of what capabilities you lose by developing MXML components vs. pure Actionscript components. So far you have listed none, you have just stated your preference for Actionscript, and your views on Java programmers. Your example of comparing HTML to javascript is not analog -- HTML is exclusively markup, MXML components are not, they contain script. A closer analogy would be coding web pages in HTML+javascript (a closer representation of an MXML component) vs. pure javascript (a closer representation of pure Actionscript.

                                So to sum up, yes, I would like to know what specific capabilities are lost writing components in MXML (which includes embedded Actionscript) vs. pure Actionscript. I don't need a book, but feel free to list one or two examples.

                                Brad
                                • 13. Pure Actionscript vs. MXML
                                  Newt99 Level 1
                                  To be constructive in the discussion, I have identified three cases:

                                  - Custom MXML component that are simple combine standard Flex MXML components and use states/transitions: MXML

                                  - More complicated components require the use of ActionScript and can override some of the methods of the superclass they inherit (say override methods of the Datagrid class and its superclasses if your component is based on the <mx:Datagrid> tag): MXML with <mx:Script>

                                  - Complex components that cannot be based on existing Flex components. Say you want to create a turn page book component. This will be all ActionScript. Your class will extend UIComponent.

                                  PS: Yes TankMan, I did master Java at the time (it was Java 1.0 and 1.1) according to other Java developers. But if you mean that nowadays, knowing Java means knowing all the APIs, all the JDKs, all CDC/CLDC profiles + all design patterns, I'd like to know one such developer ;-)
                                  • 14. Re: Pure Actionscript vs. MXML
                                    Wait, you've completely lost me- you're saying that MXML isn't declarative because it can include Actionscript? But aren't we comparing Actionscript to MXML here? By that logic, no, there are no limitations to MXML. Since it has actionscript in it. By your classification system, I could just make my entire application one MXML file, with 9000 lines of actionscript in it, doing all the work, and that would count as "MXML".

                                    And with your logic, you might want to re-think the HTML/javascript comparison. It actually is analogous- HTML can have javascript in it, the same way MXML can have actionscript in it. What's the difference? By that logic, HTML isn't declarative either.

                                    • 15. Re: Pure Actionscript vs. MXML
                                      brado77 Level 1
                                      Tankman,

                                      I'll take one last stab here.

                                      quote:

                                      Wait, you've completely lost me- you're saying that MXML isn't declarative because it can include Actionscript?


                                      You said previously that "the Flex documentation explicitly states that MXML is declarative, and therefore limited". I replied with "MXML isn't completely declarative, it allows embedded Actionscript." In other words, while MXML components are declarative, they aren't 100% declarative. An MXML component is both declarative and includes embedded Actionscript. The intent of the original question was to compare writing components in MXML (which includes embedded Actionscript), versus writing components exclusively in Actionscript. Never at any time was there any intention to be discussing writing components in MXML while prohibiting any use of embedded Actionscript, like virtually all tutorials and samples from Adobe do. The thrust is to determine if going in either direction (MXML, which again includes embedded Actionscript, vs. pure Actionscript) either provides or removes any features / functionality that the other has access to.

                                      quote:

                                      By that logic, no, there are no limitations to MXML. Since it has actionscript in it.


                                      Now you've answered the question. In your opinion, writing a component using MXML (once again, which includes embedded Actionscript) has no limitations.

                                      quote:

                                      By your classification system, I could just make my entire application one MXML file, with 9000 lines of actionscript in it, doing all the work, and that would count as "MXML".



                                      Yes, this is true. But the question wasn't an architectural design one of how the app should be broken into subcomponents, the question was about the merits of building your components in MXML vs. pure Actionscript. Your scenario has nothing to do with using MXML vs. pure Actionscript -- that is merely a design choice with whichever one you choose. One could just as easily write 9000 lines of Actionscript in a single monolithic Actionscript class.

                                      Based on your answer above, about there being no limitations of MXML when you include Actionscript, if that is true, then I believe one has to conclude that writing MXML components is superior to Actionscript, based on the fact that Actionscript components cannot be rendered and modified in the designer. Now, whether MXML has limitations was the question posed in this mail thread, and that answer still remains to be seen. But if your answer is true, then MXML is clearly superior, based on avaiable tooling, to Actionscript.
                                      • 16. Re: Pure Actionscript vs. MXML
                                        brado77 Level 1
                                        Newt99,

                                        Now this is getting closer to what I'm getting at -- thanks for the reply. Based on your three cases:

                                        quote:

                                        - Custom MXML component that are simple combine standard Flex MXML components and use states/transitions: MXML

                                        - More complicated components require the use of ActionScript and can override some of the methods of the superclass they inherit (say override methods of the Datagrid class and its superclasses if your component is based on the <mx:Datagrid> tag): MXML with <mx:Script>

                                        - Complex components that cannot be based on existing Flex components. Say you want to create a turn page book component. This will be all ActionScript. Your class will extend UIComponent.


                                        If I have understood correctly, you are asserting that cases 1 and 2 are handled adequately by MXML components, and embedded Actionscript within them. You are also saying that case 3 requires exclusively Actionscript. Let me probe further on case 3. Given that a turn-page book component (or any other complex component) must be all ActionScript and extend UIComponent -- *why* is this the case? What is it specifically about any complex component that prohibits its construction in MXML/embedded Actionscript? This *is* the heart of my question. If your description of case 3 is true, then there is some technical reason that this component cannot be reasonably accomplished in MXML/embedded Actionscript, and I want to know what that techincal reason is.

                                        My purpose in asking this is not to be esoteric -- it is to plant my component design firmly on one or the other, for the most efficient and extensible application architecture, to understand design choices between MXML and Actionscript, and when one might be appropriate or not appropriate, and so I can create APIs that can be used by third parties, which don't suffer from a particular inherent disadvantage for the mere reason of what I've designed it in. Here's some examples of design concerns when considering writing components:

                                        1) Can it be used/rendered in the designer?

                                        2) Can parts of the component be extended / overridden by Actionscript components and/or MXML components?

                                        3) Can I control behavior at any part of the component lifecycle?

                                        4) Can I control behavior in any part of the internal event handling, and/or add new event handling?

                                        5) Will a certain behavior or level of extensibility/customization be available / prohibited by writing in Actionscript or MXML?

                                        These are the kinds of things I'm concerned with.

                                        Thanks again for your response Newt99.

                                        B
                                        • 17. Re: Pure Actionscript vs. MXML
                                          quote:

                                          Based on your answer above, about there being no limitations of MXML when you include Actionscript, if that is true, then I believe one has to conclude that writing MXML components is superior to Actionscript, based on the fact that Actionscript components cannot be rendered and modified in the designer.


                                          OK. The only problem with that conclusion is that I'm against the use of the WYSIWYG designer entirely (as stated earlier, more or less). So, if I write (more of) my app in MXML, then I have the *disadvantage* that some other developer may use the WYSIWG tool on it.

                                          • 18. Re: Pure Actionscript vs. MXML
                                            Newt99 Level 1

                                            Brado,

                                            Basically, when you create a custom component all in ActionScript by extending UIComponent, you are "free" to do almost everything you want. You can display anything within the UIComponent object (using the addChild method) and create the behavior with your own set of methods. Free ? Not entirely. Since you extend the UIComponent class (and you do this because you want your class to be considered as a Flex component), there are a number of possibilities (methods and properties of the UIComponent class) and limitations. A study of the UIComponent class and of the IUIComponent interface in the framework will go a long way to make you understand what the possibilities and limitations are.

                                            Say, you want to create your turn page book component. The base of it will be:

                                            package com.mycompany.components
                                            {
                                            import mx.core.UIComponent

                                            public class TurnPageBook extends UIComponent
                                            {
                                            // Implement your component here
                                            }
                                            }

                                            Once you have implemented your component, you can instantiate it from MXML:

                                            <Application xmlns:mx="..." xmlns:book="com.mycompany.components.*">

                                            <!-- Instantiation of the turn page book here -->
                                            <book:TurnPageBook>
                                            • 19. Re: Pure Actionscript vs. MXML
                                              brado77 Level 1
                                              Thanks Newt99. I'll consider this.

                                              Cheers,

                                              Brad