MXML vs pure AS3


#1

Hello!

As mentioned in another thread I have an extensive history using AS3 / Air / Flash to build various Applications and Games both Standalone and in Browser .

So far I have never used Flex / MXML but rather created all the interface elements in the AS3 code.

Is this still possible with things like Apache Royale etc. or do I have to bite the bullet and change my workflow to MXML? Especially if I’d like to crosscompile to HTML5 et.al.

Thanks for input!


#2

I have never been a big fan of MXML because of the huge dependency on the framework and UI components etc.

But that’s exactly the pros and cons, if you use MXML and in this case Apache Royale
you have to accept to delegate to it all the UI and render thing and go with its way of doing things.

It should be possible to use Apache Royale in a pure AS3 context but then
you will also have to build anything UI by hand which could be quite daunting for an HTML5 target.

Maybe go on the Apache Royale mailing list and ask them or do some tests yourself
with simple stuff.

It really depends what kind of app you plan to do with HTML5,
if it is quite advanced you might want to do it in Angular, Apache Royale, etc.
for the components part

If it’s quite basic, eg. you could do it by hand with a bit of jquery,
then anything would work I guess.


#3

In JavaScript there is advantages to being a purist and using vanilla JS but with MXML it is not the same. When you write MXML you are making a syntactical decision to use XML markup rather than AS3 code. BUT when it comes down to it that MXML is converted into AS3 by the compiler.

In other words, when you type:

<s:Group>
     <s:Button label="Hello World"/>
</s:Group>

It is the same as typing the code:

function initialize() {
   var group:Group = new Group();
   var button:Button = new Button();
   button.label = "Hello World";
   group.addElement(button);
   application.addElement(group);
}

You don’t benefit by using AS3 in this case because the compiler reads those MXML tags and creates the AS3 you see above. There is no difference between that and AS3. You can see this yourself by using the compiler tag -keep and then checking the new code generated in the output folder.

What is interesting is that MXML is not limited to UI components. You can declare Objects and Classes in MXML and the compiler will transform that into AS3 as well.

So you could have the following MXML file called MyTestMXML.mxml and it would be totally valid:

<fantasio:MyAS3Class text="hello world">
</fantasio:MyAS3Class>

And then later use in AS3 or in MXML:

<s:Declarations>
     <fantasio:MyTestMXML id="test"/>
</s:Declarations>

It does not have to be UIComponent. It can extend Object.

You may have been persuaded in the past to avoid MXML because people have commented that it is slower than pure AS3. As I’ve mentioned it is AS3. What happens is that, without understanding what you are doing you can write a slow application. It doesn’t matter if it’s in MXML or AS3 but using AS3 you have more tighter control.

For example, you could create UI objects on demand rather than all at once. However, that’s exactly how the original Flex 3 framework did it. It was called states and used deferred objects created by function calls. You could specify itemCreationPolicy to determine when a UI component was needed.

Where people get confused is around ItemRenderers. They were perceived as “slow” in that when you have 10-100 visible at a time and then repopulated with new data as a user scrolls by quickly on a phone with a CPU from 2010 it would struggle to keep up.

So people said go pure AS3. That wasn’t quite true though. They said go AS3 but they really said extend the most basic class (I don’t remember the class ATM) that fulfills the item renderer interface. They said don’t use the default ItemRenderer that extends Group that appears sluggish on mobile devices.

They could have extended that base class using MXML as I’ve shown above. Since MXML is converted into AS3 anyway.

A downside to MXML is the lack of constructor but not every class uses the contructor.

The point is that you can use MXML and not suffer performance. However, it could be said it may be easier to make performance related mistakes in MXML but that’s not the same.

For example, people will typically throw in bindings willy nilly here and there like they are on vacation. If you are using AS3 you are not using bindings. You are getting a result from an object and manually populating a field. It doesn’t make sense to create a binding in AS3 because it is less code to do direct assignment.

So knowing how it works under the hood will help you whether you in either case.

But it is always good to be scientifically literate to verify any information.

So when you use MXML or AS3, do test cases and check the performance. Since Royale is still being developed it may or may not be exactly the same code output as mxmlc. Remember that when checking performance for Flex apps you must do a release build (not debug) and test on a release player (not debug). For Royale apps using JavaScript you do not need to do this.


#4

Mostly agreeing with everything, except that in the JS world the vanilla JS been replaced by some things equivalent to MXML, see AngularJS, React etc.

When I oppose pure AS3 vs MXML, yes I do mean the Flex framework classes that come with MXML
but yeah technically you could define your own custom MXML tags that would get compiled to AS3 and works with Redtamarin for example.

Now, when it come to Royale, their goal is to port the Flex framework in such a way you can use it with either a SWF target or a JS target, which means the MXML would be the abstraction for the UI which then could be rendered with either the Flash display list + UI components or to HTML/CSS with JS.

In itself MXML is a pretty damn good idea but it also have some flaws,
I worked on huge projects where I have seen inheritance chains from AS3 to MXML and vise versa from MXML to AS3, it worked but imho it was a huge mess.

ideally you would want something like that

AS3
  |_ AS3
      |_ MXML

eg. always end with the MXML as the “view”

but then issue 1

AS3
  |_ AS3
      |_ AS3

with

MXML1
  |_ MXML2
      |_ MXML3

because MXML is indeed converted to an AS3 class
when you need to extend MXML3 with a chain of inheritance in AS3 you can’t
eg. no multiple inheritance

or issue 2

MXML
  |_ AS3
      |_ MXML
          |_ AS3
              |_ MXML

use MXML for UI layout, then inherit with AS3 because you need code functionality
then inherit again as MXML because you need to update the layout
rinse and repeat, and you get a huge mess (note I saw that kind of stuff in production code for banks)

when your UI components become quite complex it can get weird real fast
also the skinning can get complicated too

now that thing that HTML and MXML share is the effect of reusing “UI kits” (either UI components or CSS kit)

At one moment by just looking at the UI you could tell “oh yeah this has been done with Flex”
the same you could do now with HTML where you can tell it is using Bootstrap or Material Design, etc.

you do recognise the “UI kit” used, even with skinning/customisation

and there you end up with the same flaws: sometimes the skinning/customisation does not allow you to do exactly what you want, eg. that pixel perfect effect, always a bit too much of margin or spacing or not the UI components you actually need

Now, not that I dislike MXML, but when you embrace pure AS3 and no components, you can build any pixel perfect custom UI you want.

It is a much longer talk :), but I noticed with time I went highly minimalist, I ban frameworks and components (I don’t ban libraries) from my code and build everything from scratch for what the app really need.

I realised I was building apps faster that way instead of fighting against a framework and/or a component library.

Simply put I re-embraced eXtreme Programming even more :stuck_out_tongue:.


#5

When I was busy in developing UI for clients it became apparent that I could not use CSS features in apps like I did for Flex 3 apps the same as I did for Flex 4 apps. There was some small feature that Flex 4 UI did not have that could not be easily changed with CSS. Like buttons with an icon placement or something like not being able to easily set the joint type on a border container in CSS (something like you must declare a new stroke object and then set the joint type).

So I agree, it became much more work. So instead I made one off for projects using Spark skins. The button would not have any settable CSS. It would be made specifically for that project. I had to throw away OOP because it did not work here. The designs were too different from project to project.

So in the end I would not have a large CSS file. I would have many medium sized skins. In the same way CSS is specific for a project Skins were specific for a project. They were written in MXML (or FXG in MXML) and it did not take much time when I threw out the need to reuse.

I have made skins that I do reuse but it’s not like OOP were you drop in a class.

It doesn’t matter to me that you use AS3 but I don’t know how you that would be faster. Were you simply drawing a buttons states with the graphics classes and draw commands? Do you have an example component you can post sometime?

Also, the AS - MXML - AS - MXML or MXML - MXML - MXML type of work doesn’t seem like a good idea to me either. For one, the style inheritance gets muddied and I think there were properties get clobbered without warning.

There were some other small issues and I would only use MXML the end for UI although I do have one dialog class that extends MXML once to inherit the sequence effects declared inline and a few properties that subclasses use.


#6

that’s the point, I do not use components, I build from scratch the button/label/whatever I need
only things I reuse are more like alignement,spacing,colors,etc. utilities

you could say my components are basic Shape, Sprite, MovieClip etc. classes

think of it like that: if I need to have this visual UI how should I structure it?

  • I would need a rectangle that can be alligned
  • within this rectangle I would need a TextField that is always centered
  • then I would need a bitmap alwasy spaced 10 pix to the left of the textfield
  • etc.

I can try to do that, but really there is nothing advanced there, just maximising the use of code and the display list.


#7

I’m guessing in the constructor you are using the graphics API to draw the rect and center the TextField. Then adding mouse over and mouse out events to handle button states? It sounds easy to me now the way you describe it.

I understand how it works but my friend um Bob, said he would like to see code examples to learn from if you don’t mind.