A Flex Frameworks Mud Map

In software development, there are better practices, as well as there are worse ones. The former are probably somewhat less numerous, but what they offer is a reasonable solution to a common problem. Among these practices there is a strong tendency towards abstraction. Some of these reach the framework level where they are no longer able to develop in and of themselves – a downside that in reality keeps maintainability and organization intact. Using a framework is not exactly the only way to efficiently develop solid applications. In an episode at the Flex Show, Francis Lukesh (the person behind HydraMVC) elegantly pinned down the essence of a framework by saying that “frameworks are not created, they are extracted.” There is a certain point in looking at what others have condensed into an organized whole. This may appear the exact thing you are trying to incorporate.

Reflecting on the issues including, if not limited to, abstraction, extraction, interaction and frameworkitis, I thought it would be a moderately good idea to wrap ideas up in some sort of a diagram, and this mud map is what I have whipped up so far (with regard to the MVC architectural pattern):

Disclaimer: the framework landscape reflected by the present mud map may be subject to amendments, which are most welcome.

Perspectives on how things are supposed to work may differ. Opinions on whether these perspectives need to be borrowed and internalized differ as well, which is best illustrated by the ongoing effort aimed at creating yet another implementation. The question, however, is not what framework is the best. The question is what makes a framework work for you, and even better, whether you need a framework at all. However, digging into a framework to see its inner workings is a completely different can of worms, i.e. highly advisable. There’s a great basic framework walkthrough at Insideria, by the way. Oh, and there's going to be a framework session at MAX, too.