Ryan McGeary is a co-worker who, paradoxically, is both a Flex skeptic and a nice guy. In fact, he was good enough to attend FlexManiacs in spite of his aversion to Flex / Flash so that he could provide me (and our CEO) with some constructive feedback. As I had hoped, he came away from the conference with a bunch of thoughtful comments and questions, some of which made me step back and re-evaluate my own attitudes and approaches.

I hope to write responses to several of Ryan’s points in the near future, but I’d like to start with an observation he made about the Flex developer community: he noted that we tend to be IDE dependent. I know that there are some Flex developers out there who do all their work with text editors and won’t touch Flex Builder with sterile gloves, but based on my experience I have to concede that they seem to be a small minority. (Whether they constitute a proportionally smaller segment of the Flex community than their counterparts in other development communities I have no idea. Someone should do a study on that.) As for me, I use Flex Builder every day, and I don’t see a need to change that habit. Let me explain why.

Memory

I have invested substantial effort in developing a knowledge and understanding of the Flex framework. I’m sure that if I were to put the effort into developing a few applications using just TextPad and mxmlc I would end up with even more of the Flex framework committed to memory, and in fact I would need to have it committed to memory in order to be as productive with TextPad as I am with Flex Builder. But I don’t know why I would want all that stuff in my memory when it’s already in my laptop’s memory.

Don’t misunderstand me. I’m not among those who think that it’s a waste of time to teach arithmetic to children now that we have calculators. On the contrary, I strongly believe that everyone should learn to think and act independently - which is one of the reasons my wife and I home school our children. However, I’m not convinced that memorizing highly transient data is of any lasting value.

Like many other technologies, Flex is changing rapidly. While some people are just now discovering Flex 2, Flex 3 is in public Beta. By the time many of us are comfortable with 3, Adobe will be pushing 4 out the door. Who can tell what parts of the framework will change? Some properties and methods that are now private are likely to become protected. Some members - and even entire classes - that we now use every day will probably be deprecated. New methods, properties, and classes will be added that will provide native means of accomplishing tasks that we now hack for ourselves. It seems to me that memorizing all the details of the Flex framework in its current state would only make it more difficult for me to go with the flow of all of these changes, and hinder me from maximizing the benefit that could be derived from them. That being the case, it makes sense — having already built a strong familiarity with the framework — to allow the IDE to help with the details via code hinting.

Other factors

Besides memory helps, auto-complete is also a useful time saver. For example, it’s nice to be able to type “tabn” instead of “TabNavigator” all the time. Also, having the closing tag generated automatically is a helpful bonus. (Go ahead, call me lazy.)

Then again we have the annoying phenomenon of programmer error. I’m old enough to know that no matter how thoroughly I learn Flex (or any other framework) I will still make mistakes from time to time. When that happens, and the compiler fusses at me, it’s really nice to be able to double-click on the error message and be taken right to the very line of code where my error resides.

Another benefit of Flex Builder is the ability to quickly dive into the framework source. I can highlight a framework class or member identifier in my own code, hit F3, and be taken directly to the appropriate place in Adobe’s source code. This is a great help when trying to figure out why I’m getting unexpected side effects, or in determining the best way to extend a framework class.

Let’s not forget the other useful keyboard shortcuts: Shift-CTRL-C to comment a block of code; CTRL-O to open an outline of the current file; Shift-CTRL-O to sort and organize import statements; etc.

So far, I’ve only been dealing with benefits of the IDE’s source editor. The design view (WYSIWYG) makes it easy to quickly throw together a UI layout, and has saved me a substantial amount of time on a number of occasions.

Simply put, a well-built IDE is a useful tool, and Flex Builder - for all of its shortcomings - is a well-built IDE. I acknowledge that there may be some developers who are too lazy to learn the framework at all, and couldn’t even write HelloWorld.mxml without Flex Builder. However, the fact that some people misuse a tool is not an argument against using the tool. Murder has been committed using hammers, but when it comes time to drive a nail I don’t hesitate to reach for my Estwing.