Church Of The Flying Meta-Tag Monster

April 19, 2009 at 4:31 pm 5 comments


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.


Entry filed under: Adobe AIR, OpenScreen.

An introduction to e2spreadsheet Opening files in e2spreadsheet

5 Comments Add your own

  • 1. JesterXL  |  April 19, 2009 at 5:24 pm

    You’re a major-baiter!


    3. Use framework caching; if the user has the Flex framework cached, you’re SWF is as small as a AS only SWF.

    5. FlashDevelop supports Flex; their MXML support isn’t 100% there (can’t import MXML as classes) but it’s good enough.

    6. No one intends to put the Flex framework, as-is, on a mobile device. The whole reason they spent so much time on the API is so they can create different implementations with similar API’s; you can use a more efficient mobile framework using the same API for example. They haven’t done this yet, but I bet they will. Here’s an example I know Igor Costa is using for Flash Lite 3:

    I agree, though, that FlexBuilder itself is pretty project based, and we’ve all bitched at Adobe for years about how FlexBuilder is very Flex focus vs. ActionScript project focused.

    7. lol wut?

    9. They are private because when they wrote it, they didn’t want to support the current implementation. Therefore, they only have to support public & protected implementations in future versions of Flex SDK’s. That way, whenever a new SDK comes out that fixes bugs (3.1, 3.2, 3.3., etc), you can update to the new SDK, but you’re app doesn’t break. That’s pretty powerful.

    …however, a lot of us monkey patch hacking private and mx_internal all the time, hehe… at least we CAN, and that’s important.

    10. Totally agree. However, the Flex SDK isn’t appropriate for all projects. A lot of my projects, I use 2 classes; UIComponent and Button. That’s it! The rest are merely extending UIComponent, and creating custom controls, just like I would in pure ActionScript components. Again, it all comes down to what types of projects you are doing. It’s very hard to do a lot of hardcore custom designs using the Flex SDK. Adobe knows it, hence trying to get Flex 4 Gumbo to be easier to skin. Regardless, without good tooling, a lot of us will still default to rolling our own custom components.

    While there is a filesize cost to extending UIComponent vs. Sprite, you gain a LOT. Just depends on how you code.

  • 2. TJ Downes  |  April 19, 2009 at 6:45 pm

    As with anything, use the right tool for the job. Pure AS isn’t always the answer, neither is Flex. If you use a framework to develop your apps then you are already doing what Flex attempts to do for you: Maintain a common and consistent code base that others can work with and also provide some common functionality out of the box. So by your standard, use of any framework would be evil, and I don’t buy that.

    Platform is not important, as long as it meets the requirements. What is important is educating people how to use these platforms so that applications are designed better and the developer is more aware of the pros and cons of the platform and the available alternatives.

    • 3. e2easy  |  April 19, 2009 at 7:05 pm

      “So by your standard, use of any framework would be evil” Sorry if I implied this – it isn’t what I believe. And after all my criticism of Flex, I concluded with positive suggestions about the kind of improvements that I’d like to see. If I thought that Flex was irredeemable – I wouldn’t have done that. I’m a recent convert to design patterns too, so I think frameworks can be a good thing. I intentionally designed my argument to promote discussion.

  • 4. TJ Downes  |  April 20, 2009 at 9:14 pm

    I think were Flex makes most sense is for those who are relatively new to OO development. It’s an easy entry point and over time people like can see the light.

    After working with Flex for a couple of years I now use the MXML only for slim components, and rapid development/prototyping. I haven’t yet moved to a pure AS3 environment simply because I can’t see the point of developing all the common componentsI use daily from scratch. Sure, over time this would be a lot easier, but in the same token wouldn’t I simply be building my own framework?

    However, I do believe that to date many of the components are bloated or difficult to modify. For example, the Tree control is a nightmare and I avoid it at all costs. I think it’s simply a matter of getting to know the framework and learning what you can and shouldn’t do, and then making decisions on a per project basis as to what development approach to take. I guess what I am saying is that your post does have many valid points, but often I can ignore them because it boils down to productivity for me. 😀

  • 5. e2easy  |  April 22, 2009 at 7:34 am

    This article…

    Analysing the size of the flex framework, or why I hate the AdvancedDataGrid.

    …is pertinent to the point I was making about bloated Flex classes.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed

  RSS feed          View Daniel Freeman's LinkedIn profileView my profile

Add to Technorati Favorites

April 2009
« Mar   May »

%d bloggers like this: