Review of Flex 2
Daniel Niland (www.graphictraveler.com)

For as long as I have developed applications in Flash, I have suffered the slings and arrows of my colleagues, those people who code in “real” languages.  Like riding a moped in a Harley gang, I’ve been the brunt of dismissive snickers when I tell the coderati that I develop in actionscript.  Understandably, I get defensive.  Oh, believe me, I haven’t backed down from these .net crusaders, these java junkies, or the worst, Unix geeks.  I stood my ground explaining, even pontificating, on how serious a platform flash can be.

But the reaction was generally a roll of the eyes;  “Talk to me when you get a real dev environment.”  And, red-faced with defeat and shame, my argument was over.  I had lost once again; I had no answer.  You see, I was lost in a tangled web, a precarious suite of software, shareware, and false hopes, constantly on the verge of collapse, created by entitled wunderkinds straight out of college who mysteriously fabricated these “unified” dev environments with ant and mtasc and flashdev and eclipse plugins from third-world countries that never seemed to work the way they should.  “How could you break it again!” they would scream, and we lowly users would shrug and look confused.  “When you save the .info file keep a backup and merge your changes in the /temp directory then put your line, it’s this one right here for goodness sake, in the build file with the strict parameter set to FALSE!  Idiot!”

No matter how much work we put into them, our dev environments were a weak, shallow reproduction of the slick integrated development environments my derisive colleagues had been taking for granted for years, and it was moving mountains just to get that far.  Those “suites” were a cakewalk compared to such things as “shared libraries”, which were about as fun as being knocked up the side of the head with a Mac Plus.  And even that was much better than where we were at the beginning of the actionscript coding era, where about the only reasonable advice you could get was “put all your code on the first frame of the main timeline so you know where to find it”.  Good advice, actually.

Anyway, what I’m trying to say is: we’ve had it bad in the Flash world; real bad.  In a perverse way, however, I was used to it.  I’ve grown fairly comfortable with my cobbled-together way of doing things and even enjoy being able to look down on those who “don’t get it”.  Geez people, it’s not supposed to be easy; you’ve got to earn your stripes here.  And really, could Adobe come up with anything better?

Now, I finally looked at… this is sort of difficult because I get all teared up just thinking about that moment… Ok… deep breath.  I finally looked at Flex 2 and well, you know those overwhelming feelings of joy you get when your team wins the World Series?  You know, that giddy euphoria where you pump your fist, hug your neighbor, pump your fist again because you forgot you already did that and then let out a big scream of triumph.  Well, I’m about happy enough to name my first child “Flex”.  I want to somehow, sweet goodness, convince my boss to let me use it for my projects at work (Like whales on migration, I think they’re starting to come around).

So what am I so happy about?  I guess I should actually talk about what the product does; this is a review after all. 
I won’t talk about the first thing you’re likely to notice when you open up the Flex Builder; the wysiwyg control editor in the Flex Builder, though it is quite a time saver to lay out your controls, flip over to mxml, do some quick tweaks, then flip back to design mode to see your changes.  You come to the understanding real quick that mxml and those visible components are one in the same.  Pretty slick. 

I won’t talk about the project pane where you can see all your files laid out before you like some kingly feast, to organize and manipulate and compile as your lordly will dictates.  No more humiliation by temperamental wunderkinds here; they can be banished to their cubicles now and everyone, including them, will be much happier for it.

I won’t talk about the intellisense that makes the act of coding much more efficient, as I already had pretty good intellisense with FlashDevelop.  For anyone who has been unfortunate enough to actually use the Flash IDE, then you should be pretty impressed by how easy this feature is to use; just write your variable name, hit the period, and viola, an entire list of possible values for you to use.  The list is dynamically updated so every time you add a new variable, it will auto-magically be included.

I won’t talk about how easy the Flex Builder is to use in general.  The user interface is great.  Menu options are easy to find and logical.  I won’t talk about these things because, well, I’m over them now.  They were the first thing I saw and noticed, but they’re part of the IDE and they’re meant to blend into the background.  You get used to them very quickly, and frankly, they’re the minimum of what you’d expect in a modern IDE; they’re there to be taken advantage of and glossed over, and that’s exactly what I’ll do here; big margaritas to whoever designed the Flex Builder, though.  Bravo.  Let’s move on.

As I switched between the code pane and the design pane I realized very quickly that this was way cooler than I thought it would be.  I ripped through all the controls, fiddling with them, setting events and binding data with abandon and then I had a sort of epiphany that slowly built up to my World Series rapture moment.  This mxml I was playing with was really just a way to describe the relationships of a bunch of objects.  This is pretty useful if you’re setting out a simple user interface as all the relationships, the little placement and proportion details that are an absolute headache to code yourself, are taken care of for you without you even realizing it’s a huge deal (believe me, it is).  All these xml relationships, though, can only take you so far.  As soon as you want to move beyond what some may call the “smart ui” anti-pattern, where all the logic for the application is tied up with the implementation of the graphical elements, then you need a lot more flexibility.

And then I understood the power of Flex.  You don’t need to use the mxml at all, and definitely not all the time.  You can use all these components in a variety of ways, only one of which involves mxml.  As I frantically explored more and more of the Flex libraries the trumpets blew and choirs of sweet angelic voices crescendoed, the tympanis bashed, the string section arpeggioed, then I had to turn off my stereo, it was getting too loud to concentrate!

I’ve been creating applications in Flash for a few years now, and many of those applications have been extremely complicated.  I know how darned difficult it is to make a library, an API (application program interface) that other people can use without throwing up their hands and screaming obscenities at you and the future generations that may spring from your loins.  The problem is this: everyone wants to use your libraries to do different things.  Some people just want it to do a very simple thing, and other people want it to do things that the computer science doctorates at Google would run away from like little girls.  You haven’t lived until you get curveballs like “Can you make the icons automatically translate the location of the mouse cursor into four-dimensional Croatian proverbs?  The CEO is really a big fan.”  Well, hey, that’s pretty hard to do, and in the past, I’d probably give them my best sniff and say something like “boy, I’d have to say that’ll be somewhere around the square root of negative two possible” but now I’m not so sure. I bet Flex could make that happen.

What Flex does is layer the levels of access to its components.  If you want to do very straight-forward simple things, like we all do about 90% of the time, then you use the mxml system and don’t worry about all the other stuff.  You get a huge amount of the work done for you, but you have to live with what they give you for the most part.  Next there is a layer that is a bit more intense, but not exactly rocket science.  You can stick with the mxml and do a few sharp zig-zags (all relatively easy), or you can go ahead and write pure code in .as files that use the libraries just like any other that you instantiate in Flash.  Then, there is usually another layer of flexibility built into the components that lets you really go in and do some crazy specialization.  This is generally done exclusively in code files and will get you up to about 99% of your possible tasks.  Finally, if you just can’t get the component to do what you want it to, you can either sub-class the component itself so that you overwrite various functions to do what you want, or you can open up the holy sanctum of the Flex code base itself and make completely new components.  And here’s the kicker, the Flex framework is such that it’s insanely easy to incorporate these different levels of complexity together in one happy application.  This is scalability on a scale far past my ability to create libraries on my own; I will joyously throw out all the data managers and init managers and bitmap managers and all the other managers --enough managers to fit a decent-sized motivational seminar-- all gone or at least severely simplified, made easier to use and integrate.

With Flex, I foresee myself doing everything I used to do but in a fraction of the time and effort, which should free me up to learn golf (or maybe make even better applications), all done in an IDE that is powerful and easy to use.

So pardon me if I walk into the break room with my head held high, a second-class citizen no more.  They’d better back down if they have any of those old snide remarks hanging on their lips because I’ll pull out a big old can of Flex whoop-um.  Don’t think I won’t.

Man, it feels good.