This post started out as my notes from the Oct. 11, 2007 SilvaFUG user’s group meeting, which included two talks on Flex application frameworks, but by the end I realized it was more of a restatement of (filtered through my opinion) some of the important forward-looking ideas that came out of the audience discussions and the presentations at that meeting. So I think it rambles more than I would normally like, but I was trying to capture my “raw thoughts” while the meeting was progressing.

If you’re interested in a summary of the talks, I’m afraid I didn’t do that. (But I highly recommend viewing the presentations:

• Grant Strake on moving ZoomFlex from a homegrown framework to Cairngorm
• Ali Mills and Luke Bayes comparing various Flex application frameworks

What I’ve written here is primarily just thoughts that I wanted to save for myself; things that maybe I don’t think about as often as I should, or things I want to remember about the audience of Flex and other Adobe developer products. Because I’m interested in the developer community, much of the focus is on points about the developer community that I sometimes need to remind myself of.

Grant Straker

The first speaker was Grant Straker, talking about his company’s choice to use a homegrown framework, and eventual decision to migrate it to Cairngorm instead. His company (Straker Interactive) has a RAD product (“ZoomFlex,” I believe it’s called) that bundles ColdFusion and Flex to create apps quickly – you use wizards to define data structures, and the product generates database structure, backend ColdFusion, and front-end Flex code for apps using that data. (The idea is that developers then take those Flex files and customize the front-end forms, style the app, etc.)

Here are some interesting thoughts/points I picked up:

• Originally they chose not to use Cairngorm for the underlying framework for their generated code. The reason: while there are some developers who build big, fancy, complex enterprise apps, there’s also a group of developers who “just want to know what they need to know to get their job done” – which often means build basic CRUD apps as quickly and easily as possible (e.g. web-enabling existing databases, spreadsheets, etc.). This latter group was/is more in their target audience.
• Code can be written in different ways – they try to generate code so that it’s clear and obvious what it does, and so that it can be easily extended by developers of varying levels of experience (key: don’t assume a high level of experience).
• In retrospect, he wishes they had just stuck with Cairngorm in the beginning. Now, 1.5 years later, there’s a large community, examples, documentation, etc. making it easier for a less-experienced developer to learn enough Cairngorm that they can understand it and use it.
• I was really amazed by how much code they are able to generate for developers. I’ve read some things about code generation tools, but I’ve never tried them out (due to the organizations I’ve worked for, and perhaps due to my personality as a developer who likes to have “control” of the code). However, I’ve definitely seen the down side of that, which is that I end up writing a lot of redundant or very similar code (especially for data access and manipulation). The “alternative” approach certainly has some attractions…
• Part of what they include is a library of pre-built UI components. The process of migrating these components to Cairngorm has been challenging at times. One of the principles of many frameworks including Cairngorm is that the user interface code is separate from the “model” (the underlying data). However, some components by nature lend themselves to having knowledge of their underlying data (e.g. their video player component) so figuring out how to structure those components is complicated.

Luke Bayes and Ali Mills - Evaluating application frameworks for Flex

Luke and Ali came into this presentation with no background in any of the major frameworks (other than the Flex framework). This is good because they didn’t have any biases, but it means they may have some non-best-practices too.

This was a great talk, but there was a lot of info in a short time so again, I’m not going to bother trying to write detailed notes. I highly recommend watching the recording.

However, once again in this presentation (in particular in the discussion afterwards) some of the same ideas came up. Luke in particular expressed a reluctance to have a prescriptive framework, because he doesn’t want to be “told how to code.” That opinion resonated with most of the audience there – but at the same time, everyone also acknowledged that the audience at a user’s group presentation isn’t really an accurate representation of the broad Flex developer community (especially the even broader community of developers who are considering Flex or who will be Flex developers in the future). If the Flex community is going to continue to grow, and be more accessible to new developers, it would be very helpful to have some prescriptive application frameworks that give people a predefined, standard architecture within which they can build their app (in the same way that Flex’s components provide user interface elements and layout elements that give developers a big head-start in building an app, compared to straight ActionScript or Flash).

What is the “next frontier” of Flex developers? Is it the “VB developer”1 (the “behind-the-firewall” corporate developer). If so, then to support that group of developers we’re going to need prescriptive frameworks that are easy to get into (“accessible” in Luke and Ali’s terms), that do as much work for you as they can, but that still don’t get in the way as an app grows in complexity.

At the same time, more advanced Flex developers may not want such a framework, and they certainly aren’t going to want to have to carry along the “baggage” (meaning both prescriptive architecture imposed on them, and literal baggage in download size) that would come along with such a framework if they’re not using it.

Personally, I think that’s an extremely important point for both Adobe and third-party framework developers to keep in mind going into the future.

“VB Developer” is my name for a developer who works in a medium-large corporation or organization, perhaps coding apps for a group within that organization, who doesn’t really want to learn everything there is to know about Flex (or their language of choice), or become a “guru,” but rather just wants to build their app and make it work nicely, but do so as quickly and painlessly as possible. Yes, the name “VB developer” is rather dated, since at this stage in history most such developers are doing web-based apps, probably using ASP.NET or J2EE in a large, standardized org or perhaps PHP or Ruby in a smaller or more independent group.