The Joy of Flex

A lot of good blog posts have already gone by on this subject, so I wanted to focus on what I care about most: making the Flex framework better, faster.

The reason I’m excited about today’s announcement is that at Virtual Ubiquity we spend a lot of time and energy figuring out how to make components in the Flex Framework do exactly what we want them to do. I see the potential to accelerate that process, to give us more choices about how to build what we want to build, and to give us more choices among off-the-shelf components that we could use.

Here’s a case in point. In our product we have a horizontal accordion. It’s right smack in the middle of the UI, and it’s the main way users execute commands in the product. So we have invested a lot of design and development time making it look, feel, and operate exactly the way we want it to. The way we built it (short story!) was to copy the existing vertical Accordion component out of the Flex Framework and switch all the x and y coordinates to make it into a horizontal accordion. From there we build a series of subclasses that added more functionality, more behavior, visual transitions, and so on.

Copying source code out of the framework is not an ideal way to build a component. The way we would have liked to have build our component would have been to simply subclass the one in the framework. For that to have been possible, it would have had to be refactored quite a bit. It’s great that we have source to the framework — that’s a big head start in and of itself. But now we’re stuck, because bugs will be fixed and features added to the Accordion, and we’ll miss out on those changes unless we make a careful effort to merge each time we get a new drop of the SDK.

And the meta-problem here is that, assuming we wanted to leverage the framework, copying source out of the framework was our only choice. We need more choices!

I expect that after the open source project gets up and running, our choices will expand considerably. Next year, when we’re faced with a similar situation, I expect our additional choices to be:

• we could choose from a wider variety of components from the open source framework that are flexible enough to subclass
• we could copy the source from an existing component, refactor it ourselves, and submit the results to the framework, knowing that we’ll get the benefit of other people’s bug fixes
• we could contact the author of a component we found in the open source framework and ask (pay?) them to extend it in the ways we needed

There are probably many more possibilities I haven’t thought of yet, since I haven’t worked on an open source project before.

The biggest downside I see is one that Brian Deitte already mentioned: I don’t want this effort to distract the Flex team from their core mission. But I trust those guys a lot and I expect (more) greatness.

Technorati Tags: Flex, Open source