I recently gave a presentation on Flex frameworks at the New York Flex Users Group. More than 50 people showed up, which proves that this is an important topic. By the end of the presentation the temperature in the room had increased because an innocent talk had turned into a heated discussion.

First, I’d like to make a few points, and share with you some observations. Before starting the presentation, I asked the following questions:

1. How many people know Java. About 60% raised their hands. I was expecting around 80% since Flex works nicely with J2EE on the server side.
2. How many people know design patterns? Only 40% raised their hands this time. This was somewhat troublesome and explains why people have problems understanding Flex frameworks.

Last Monday, I had been teaching a one-day hands-on class on Cairngorm. Without discussing the pros and cons of Cairngorm, I believe it’s an easy framework to learn, assuming that you understand several design patterns. After about five hours (including hands-on exercises), students had a pretty good understanding of how to use this framework. But I remembered a sentence from a recent blog – it was something like: “Is this just me being stupid or are you also not getting Cairngorm?” It’s not about being stupid, it’s about understanding design patterns.

When selecting a Flex framework, we need to distinguish between architectural frameworks and component libraries.

Architectural frameworks don’t give you additional functionality such as better components or code generators, but rather allow you to re-arrange (refactor, organize) your applications' code into separate tiers. Why would you want to consider one of these frameworks? We live in a world where a group of developers who are working on the same project each have different skill sets (read my lips: most of them are junior) and project managers try to lower the risk of project failure by limiting the responsibilities of each developer. Mary, you are responsible for developing just the UI for these 10 views. Srinivas, you are responsible for programming business logic in ActionScript. Manoj, your task is to provide and test remote services supplied by the Java-based content management system and some Web services. Project managers sleep better knowing that if Manoj leaves the project, they can easily find another developer who will pick up his work.

If this sounds familiar, pick an architectural framework that is not too intrusive, which means it doesn’t require developers writing too much boilerplate code just to support the life cycle of the framework. The other consideration is how does it support modularization. In no time you’ll find yourself in a situation where the size of your SWF gets out of hand and the users need to wait for more than a minute just to see the first screen of your beautiful RIA. And finally, what’s the learning curve of this framework for your developers based on their current skills.

The other approach to project development is to use just the Flex framework in conjunction with various component libraries that increase the productivity of developers by offering additional functionality to existing Flex components, deploying various code generators and wizards. If you have at least one senior Flex developer on your team, this is a pretty safe way to run the project.

At the end of yesterday’s discussion several people expressed an interest in running the next meeting as a panel with several people representing different points of view about the usefulness of various frameworks. It should be an interesting shootout.

This presentation will serve as a basis for the chapter of an upcoming OReilly book "Enterprise Development with Flex".

I’ll repeat this presentation as part of the Enterprise Flex Symposium in New York City on August 19, then at the NJ Flex Users Group on August 20, and in Philly’s Flex Users Group on September 11. Come on over and let’s fight.