Church Of The Flying Meta-Tag Monster

In “Blashphemy! Burn the Flex-hating heretic!”, I likened Flex evangelism to a religious cult.  If I pursue this theological metaphor, then Pure ActionScript developers, like myself, are clearly atheists.  Our choice is not dictated by faith or devotion to Adobe Flex.  Pure ActionScript is IDE agnostic.  It’s a pragmatic individual choice.  It does not blindly follow the congregation.  (Most information on Flex, most blogs and training courses, will focus on MXML.)

It is possible to utilise the Flex-framework and components, via a Pure ActionScript approach.  However, I am presenting Pure ActionScript approach here as an ALTERNATIVE to the Flex components.  Not a complimentary philosophy.

So, let’s compare the use of Pure ActionScript to the Flex/MXML (Flying Meta-Tag monster) approach.

The Ten Commandments of the Church of the Flying Meta-Tag Monster…

1. Thou shalt use meta-tags.

Flex evangelists will tell you that MXML is simply an equivalent way of expressing ActionScript.  (The apples vs. apples argument).  While this is true, and you can always express MXML as ActionScript, it does not work the other way around.

It is possible to automatically convert MXML script to ActionScript script.  So it is also possible to automatically generate ActionScript from a Flex Design View visual representation.  Yet Flex doesn’t include this feature for the benefit of Pure ActionScript developers who want to manipulate, resize and position their components visually.  Why not?

2. Thou shalt find me difficult to learn.

Actually, MXML evangelists often claim the opposite.  “MXML resembles HTML – therefore it is easy to learn.”  But in actuality, this resemblance is superficial, and it certainly does not prepare the novice for the finer points of MXML development.  But the similarity between ActionScript and other programming languages is much more profound.  For a software developer, the transition to Pure ActionScript is relatively painless.  Whereas MXML requires the user to ascend a steep learning curve, irregardless of their transferrable skills.

3. Thou shalt not produce a small file.

The Flex-framework is incredibly bloated!  Flex evangelists will claim that file size is irrelevant.  But at least the smaller, leaner, files produced using Pure ActionScript don’t keep you waiting, staring at a loading bar, while the application loads.

4. Thou shalt not create applications that run efficiently.

Ok, it depends how you write it.  But you have much more control over the computational load with a hand-crafted Pure ActionScript program.

5. Thou shalt not use any other IDE.

A Pure ActionScript application can be developed in Flex, Flash, or third-party IDE.  Or you can switch between IDEs, depending how you feel that day, or the phase of the moon.  This also means that you are free to re-use your code across IDEs, and collaborate on Flex-based projects, Flash based projects, work with other programmers, or graphic designers.

6. Thou shalt not target multiple platforms.

In Flex you decide at the outset whether your project is for the browser or the desktop.  Flex is dogmatically restrictive.  Suppose you have a Browser project, and you open a file that references AIR-runtime objects.  Flex will actually delete the include statements from your source code!

When I develop a Pure ActionScript AIR application, I write it first without AIR-runtime methods.  Then I include those methods within a main class that inherits the main class of the non-AIR program.  This methodology enables me to deploy my applications to either AIR or the browser, and to test most of my application without launching the AIR runtime.

Pure ActionScript produces a smaller file-size and lower computational load.  These are important considerations for adapting an application to a Mobile device.

7. Thou shalt not port thy applications to any other language.

It is easy to port Pure ActionScript code to another programming language.  But it is easier to pass through the eye of a needle than it is to port a Pure ActionScript / MXML hybrid.  Some developers have ported ActionScript programs to the iPhone.

8. Thou shalt be required to read the documentation daily.

This is my penance as a Flex contractor.  Sometimes, I’m required to make Flex components behave as if they were not Flex components.  If I’m very lucky, this can be achieved be overriding a method, or responding to an event.  Each Flex object has hundreds of documented properties, methods and events.  Each documented with a very brief description.  Sometimes, you can hit upon something useful by trial and error, just reading through the list, and trying out things that looks relevant.

The problem with the Flex components is that they are too complicated.  Adobe has tried to make them flexible and configurable, adding so many bells and whistles.  I would have preferred the Flex components to be smaller, simpler, with fewer parameters.  But documented from the point of view of a programmer who might want to override its methods.

9. Thou shalt not change the sacred private methods.

Sometimes, it’s not enough to treat a Flex component as a black box implementation.  Sometimes, you need to familiarise yourself with the code, and override private methods.  Why did Adobe make them private?  Why are they sacred?  Why not just protected?

10. Thou shalt not embark on sophisticated projects.

Flex makes simple things a little simpler.  But, In the author’s opinion, more sophisticated projects, and highly customised interfaces should be approached using Pure Actionscript.  It is easier to write a custom component from scratch than to change and rewrite custom Flex components to do precisely what you want.

As a hard-core Pure ActionScript programmer, it’s often quicker for me to write something that to search for, and understand, a third-party object.  (Why use a DataGrid? – when you can write a couple of nested for loops that set up a grid of TextFields.)

. . . . .

I set out to present a polarised and contentious argument, and to promote discussion.  But, the process of contrasting two approaches started leading me into constructive ideas about how the Flex environment could be improved for the benefit of Pure ActionScript developers.

Automatic generation of ActionScript from a design view and a simpler set of Flex components designed and documented for the programmer who likes to use inheritance and override methods.  If these Flex components were small and simple enough, then perhaps they could be appropriate for mobile devices, and Open Screen deployment.