Adobe Flex First Thoughts: Part I

I was able to sneak into a two day Adobe Flex 3 training session a few weeks ago, and now I've finally had a chance to write down what my impressions are of the language and environment. This is Part 1 in a 3 part series on Flex. Today covers the Flex language, next up is the Flex Builder Eclipse Development Plugin, and last is the Flex Server and Adobe Integrated Runtime (AIR) components.

As a word of warning... these are opinions generated by a mere 16 hours in training. Errors and omissions should be expected (that's what the comments are for).

Flex is Adobe's platform for web applications. To the end user, the application produced looks like any other Flash application running in the browser. But the difference between the Flash and Flex development environments is large.

Unlike the Flash development environment (now called CS3), Flex has no concept of a movie, a stage, or a time line. This is good news for programmers because development no longer feels like it is taking place in an animators studio. Instead, Flex ships as an Eclipse based plugin. The IDE looks great: there is a nice looking UI builder, the Eclipse project wizards seem to work, the IntelliSense works good enough, and the debugger contains all the expected Eclipse options. The compiler is available for free, it is only the Eclipse plugin and the Flex server that requires a purchase

The Basics

Flex applications are written in mxml, which is really just an xml file. The file contains xml based component definitions ("put text box here"), css to determine look and feel ("background is green", and ActionScript 3.0 to handle behavior ("MyTextBox.onClick(Event e)...").

For me mxml was a bit of a turn off because it mixed the xml, ActionScript, and css all in one file. Even with the syntax highlighting, there was a lot of noise to sort through when you wanted to get down to the business of editing ActionScript. It looked like all the naive sample Java Swing applications that Sun published (you know, where every sample is one big class that extends from JFrame). These examples influenced thousands of Java programmers, like myself, into thinking that every Swing app started with subclassing JFrame. Ack! Model, View, Controller anyone? I know this approach of mixing all three layers in one mxml file isn't required, and that css can be externalized to an application level css file. But it's sad to see Adobe implicitly promoting this style the same way Sun did with the Swing examples.

The good part of mxml is that it could drive component driver development. Each mxml file is typically a visual component that extends an existing widget and adds functionality to it. There are currently hundreds of existing components in the base component library, and more are available on the web for free and otherwise. All of the dependencies are located within the component, and the application is simply a shell that assembles these components into a coherent layout. Nice and reusable. Just like COM! Wait... that doesn't sound good. But it is like COM in that the goal is to define reusable components that developers can add to their component library. And it seems like Adobe wants to make it easier for 3rd parties to create and resell components, just like the COM business model. A ramification of this model is that 3rd parties become very important to the success of both Flex and COM. All the components look great today: crisp, well-animated, modern looking. But in 5 years they are going to look old, dated, and clunky. Everyone knows a VB 5 application when they see one; in 5 years will Flex apps be the same? The answer is maybe, depending on what happens with the community and what Adobe contributes.

Working with Widgets

Within the mxml file, Flex visual components are defined and laid out using xml markup. Verbose? Yes. Old Fashioned? Yes. Industry Standard? You betcha. The nice part is that layout and positioning are controlled within the component declaration. Compared with Swing's GridBagLayout, the Flex layout mechanisms were a joy. It was a lot of containers and alignment attributes, but it was all intuitive, especially for someone versed in JPanels and scarred by GridBags. What's more, there was an absolute layout option. Why did Java never include this with Swing? VB has always been easier to prototype with than Java, and my opinion is that the missing absolute layout manager has a lot to do with it. VB UI's were a breeze to throw together, and so are Flex's. The downside here is that resizing doesn't work. For a rich, pretty website designed by a graphic design professional, this might be a non-issue. But most pages I piece together benefit from resizing. As monitors grow in size, a blog column constrained to 600 pixels doesn't make sense.

But wait? Wasn't css part of the mxml? If you lay out the page in XML, then what does the css do? The answer: css only controls looks such as color and fonts, not the size and layout of the components. I love this because I've never graduated beyond html tables. Never once have I gotten css positioning to work. And now I don't have to!

Hopefully, most my time with Flex will be spent with ActionScript 3.0, making the components behave the way I want. I've been told at times that AS 3 is a subset of Javascript 2, a superset of Javascript 2, and that both are based on ECMAScript. It seems to me like both are based on ECMA, AS based on edition 4 and JS based on edition 3. Anyway, you get all the nice features you'd expect like anonymous functions, object prototypes, and the mixins that go along with it. For anyone with a passing knowledge of Javascript, the ActionScript language shouldn't be hard to learn. One cool feature is that the Flex compiler has a command line switch on whether to enforce static/strong typing or to allow dynamic/weak typing. The demonstration I saw was strongly typed, but a little exploring exposed this option. Exciting! In Java, I've been advocating having production code written in Java (static/strong typing), but unit test code written in Groovy (dynamic/weak typing). This allows me to refactor the production code without worrying about compiler errors, which simply serve to slow down many refactorings. I lose the ability to think out loud with code, and find myself thinking for short periods of time and then fixing all the compiler errors I introduced. (Technically, what I want is static typing in production code and dynamic, but strong, typing in unit test code, but getting dynamic is an improvement). (More technically, what I really want is weak, dynamic typing for both lines of code and the good tool support typically associated with static types)! Anyway, it looks like static typing in production and dynamic typing in test is supportable with Flex. It would just take some clever code organization and build scripts. Awesome!

Working with Data

One of the best parts of a dynamic language is the parsing and text processing capabilities. XML creating and parsing is a breeze with Flex. Look how easy it is to create a large XML document:

var employees:XML =
<employees>
<employee ssn="123-123-1234">
  <name first="John" last="Doe"/>
  <address>
    <city>San Francisco</city>
  </address>
</employee>
<employee ssn="789-789-7890">
  <name first="Mary" last="Roe"/>
  <address>
    <city>Newton</city>
  </address>
</employee>
</employees>;

This is more intuitive to me than the equivalent Groovy Builder object that uses closures to build XML. Accessing XML is a snap too. Just take the XML object and reference it without the endless findChild(), findAttribute() method calls associated with Java parsing:

employees.employee[0].address.zip;   // 98765
employees.employee[1].@ssn;          // 789-789-7890

This whole thing makes me happy.

Flex components are tied to data sources, such as web services or files, using a very similar technique to Visual Basic's component bindings. A component itself has a data source attribute which references an ActionScript variable declared as Bindable. This is simple, slick, and makes for a great demo. However, a DAO layer would definitely be needed for large-scale projects. Remember, not only does the mxml file have AS, XML, and CSS in it, it now also contains bindings to the data model. Separation of concerns was not a design principle for the training material. Sure, it could all be separated out, but Adobe does not seem to be leading the way for higher quality Flex designs. One nice thing about this data binding is how simple the Ajax integration becomes. Since everything you need is within the mxml component, the component itself can connect and update itself asynchronously without crossing any layer boundaries. I was similarly impressed with Grails custom tags and the ease with which they could be Ajax-ified. The two aren't that dissimilar to someone without in depth knowledge (me).

The Bad Stuff

One large downside of Flex is the lack of community and support. Try to do anything in Javascript and you can find hundreds of forum posts and articles describing how to do it. Try to do anything in ActionScript and it will be much harder to find examples. Moreover, some of the examples will be AS 2 or earlier. The few edge cases I found myself working with stumped me for quite a while, and lack of online help played a role. Also, there simply aren't as many people with Flex skills, so hiring good people might prove to be tougher (whereas, hiring awful Javascript programmers is pretty easy nowadays!). Flex does have good documentation from Adobe, which is modeled after Javadoc. Overall though I'm hesitant to invest a lot of time into something that may never be mainstream. But last month's Minnesota Flex User's Group had 30 people show up, so maybe this is the next big thing.

The other downside of Flex is the US$400 license you need to buy for the Eclipse development environment. While this isn't needed to develop Flex apps, it sure was nice. It's also the topic of the next part in this series.