Flex-less MXML: The Flash Evolution
The greatest thing about the Flex Framework in my eyes is its utilization of an XML based language (MXML) for it’s primary scripting. MXML allows you to create, bind and structure objets in a very straightforward manner. This then leads into other advantages such as rapid prototyping and development and so on and so forth.
Mark-up languages have always been easy to author and understand, just look back at HTML for example. Your average person interested in tech could pick up basic HTML in a very short space of time, then boom, their a web developer just by understanding the behavior of a few predefined tags. A mark-up developer never really wonders why the page is working the way it is, they never wonder why they get constraint and layout flows for free and its OK if their code isn’t perfect as they still get some kind of output from it (unless they went wild with a comment tag).
And so now with MXML, it’s proven that an XML based language can work in the context of creating ActionScript applications. So why is MXML limited to the Flex Framework? Well, the simple answer is that a lot of the META-tags and curly-braces used in the MXML language are only compatible with the Flex Framework. Those little snippets are the worker bees of the Flex Framework who fly around making sure everything is hooked up correctly into the underlaying ActionScript.
So does this mean that Flex-less MXML is nonstarter? Well almost, as I mentioned before, MXML’s rules, constructs, methodologies are all linked to the Flex Framework. But what if we could create our own rules, create our own “worker bees”, then we would have Flex-less MXML right?
This of course throws up a thousand different questions like: Would this even be know as MXML anymore? Would it give birth to languages such as FVX (XML for Flash Video) and GEXML (XML for Flash Gaming Engine) or FFBX (XML for Flash Facebook Applications)? How would you define all the rules need to create these languages? Cant we just build our own compilers for this?
Would the creation of all these variants be a good thing? Who knows, who cares!, the point is that then people would have a choice of how they want to develop in Flash, this is so important! As ActionScript becomes ever more verbose and powerful, its adoption rate with newbies will fall because its just too much for the casual developer to pick up.
This brings me back to the point about only having to learn just a few predefined tags. The Flex Framework shall only get bigger and so shall its documentation. Its wizards shall grow in number to counteract this growth, but in the end, the framework shall become almost as hairy as AS3 to the casual developer. We need mini XML frameworks built for targeted needs for the Flash Platform to flourish and evolve.
I know this shall happen in the next few years, but the question is when? Shall it be Adobe who takes the necessary steps or shall it be the community? I look forward to the years ahead 
Yes, I do think you’re on to something there. AS3 has really distanced a lot of Flash designers from scripting stuff. As the language becomes more “professional”, we will need more handholding tools to make sure the casual Flashers can still get things done with the tool.
I think what would be good to see is an extension of the tween-to-XML paradigm introduced in CS3, by combining that with Flex Builder’s Design View. If animators could quickly layout some Flash components and edit a bit of an MXML-esque markup, that would solve most of their needs, and enable further collaboration with developers they might be working with.
One of the least known reasons companies switch to using Flex is that it allows them to use version control, like SVN, to save different versions of the project at different times. MXML has this advantage while a Flash .fla file does not. Text files also have the advantage that you can use diff tools to do a comparison to see changes that you’ve made. Text files also have the advantage that you can also choose your own text editor, etc. The only disadvantage I see is when you want everything (graphics, sounds, etc) grouped together in one FLA. Chances are though, that your project is more complex with more than one FLA file. Wrapping your project up in a zip or using the Flex Export wizard allows you the same convenience.
I think it would be amazing to see a MXML of a Flash FLA file. Actually, you could create one using the plugin architecture of Flash. I had to write a script once that parsed through the DOM of the fla. You could upgrade it to export (save) the dom to an xml file or import (open) an xml file.
judah .. repeat after me … Flex is Flash .. one more time .. Flex is Flash .. all together now .. (you get the idea)
You need to understand that MXML *is* ActionScript. It’s just an abstract, controlled and directed way of writing it.
Your argument about version control is completely incorrect I’m afraid.
Alex — Flex can be used exactly as you describe today. If you don’t use the flex framework, it won’t be linked into your SWF. There’s a couple of key utility classes and interfaces that form the ‘kernel’ of MXML, and are required for the language to work at all (databinding, for example, requires the binding utility classes). But that kernel is a very small set…9X% of the classes in the flex framework aren’t required. So it’s trivial to write your own class libraries…ones that extend flash display object types directly, for example, or ones that extend Object and are completely non visual…and use those in your MXML files, without using the framework classes itself. A swf built with MXML with a root tag derived from Sprite, for example, is 2k. Anything else you add in from there is up to you.
Enjoy.
Ely Greenfield.
Adobe, Flex SDK.
Alex, judah’s point about version control shouldn’t be taken the wrong way. He’s not saying that Flex isn’t Flash. Many large companies that use version control systems don’t like FLA files because they are binary. Regardless of whether its a good best practice, sometimes code is placed on the timeline, and this code isn’t treated the same way in source control. These systems are mostly designed for plain text code files.
MXML is advantageous because it provides a layout mechanism for Flash while retaining the plain text nature of code. In other words, it works great in source control. judah seems to be agreeing with you that MXML for non-Flex projects would be great because it would work well in a source controlled environment.
Ely - I appreciate that you can do things like this:
<display:Sprite xmlns:display="flash.display.*">
<display:Sprite/>
</display:Sprite>
And, the size of the SWF is of no concern to me once the MovieStar release is mainstream.
What I want, is to be able to create my own XML language by defining a simple set of rules. And then to be able to build an app, in an Adobe IDE that can compile based on the rules of my language.
It’s the creation of an XML “kernel” creator I’m interested in seeing. An XML to ActionScript super engine …
I stated MXML so many times in this post because right now it is the only ActionScript XML language, and this is the point im trying to make.
Hey Josh - Yes my comment was probably a little too short, Im commenting while working .. not the best idea.
My point is that you can create Flash (non-MXML) projects without FLA’s, thus my reason for the the version control comment. And if you need to create FLA timeline based animations, they should be modular (ie, reside in many FLA’s and be exported as many SWF’s) and contain minimal ActionScript.
I am just finishing my first ‘real’ flex application. It took me 2 years to find a project where it seemed more appropriate to use flex builder instead of a traditional FLA based project. Anyway my one big concern is the compiled swf ended up being 500kb! 500kb with no graphics embedded. If I built the same thing in the Flash IDE I am sure i could easily keep it under 50kb. So it seems that little bit MXML ends up being ten times the amount of actionscript. Just an observation.
NuEddn jr39ug7djalfgpitg94gbvm
Wonderfull great site