Thought I'd offset my love-related etching from yesterday with a Flex rant...

Using Apple's UI development tools has helped to clarify the benefits of a template-based approach to UI development. Under that mantel I include things like Flex, .NET, Java Struts and Tiles - anything where you use a parameterised components to build a user interface. There are two benefits to a system like this:

1. initial speed of development
2. consistency of look and feel between applications

I say initial speed of development because I have always found that as time goes on, these 'easy, fast' systems tend to result in code that is difficult to maintain as the complexity grows (although you could say that about anything really... I'm really saying that the 'easyness' fosters a certain 'bricklaying' style of programming that is tedious to change due to excessive copy-pasting of details instead of OOP centralisation).

The Apple stuff brought point 2 home - it's very important for an operating system to maintain a look and feel between applications. That's where this sort of thing belongs. The good thing about the Apple implementation is that there are lots of very high quality components and integration hooks that can be used to rapidly build a fancy looking application. Also, since Apple themselves use these tools, their construction is optimised for real world use.

Here's the rub: Consistent look and feel is a no-no for Flash applications. The whole point of using Flash is differentiation of UI concepts, creating branded experiences, creating something unique every time. So Flex is generally more of a hinderance than a help when it comes to building RIAs for the web.

Flex MXML source code looks like bad HTML. As a sometime HTML developer, seeing X and Y coordinates hard coded into my view structure makes my blood itch. Seeing visual implementation details randomly mixed in with structural details scares me. I am deeply concerned that the templating language of Flex has learned nothing from all the progress that has been made cleaning up HTML over the years.

I hate the 'data provider' paradigm. It never works. It was never enough for a .NET app, and it won't be enough for a Flex app. There's always something you need to change that the component API doesn't let you change, so you end up jumping through artificial hoops imposed by the incomplete component implementation.

When you develop parameterised components, you are adding redundant functionality to your code. You try to second-guess future implementations, but you never think of everything. The more flexible a component, the fatter it is. Which is why a Flex application takes so long to download. Watching a progress bar on a website before I can do anything makes me want to leave straight away.

The other facet of this sort of encapsulation is the inevitable event maelstrom. To make a component flexible enough for use in a real world app, it needs to be dispatching events all over the place. And in my experience, the one you need is always missing. It's okay if you have the source code - you can add in an event at the point you need it, but it's never quite right.

Another problem with component encapsulation is that when you have a lot of classes going into your component's implementation, you end up having to override a whole inheritance chain to change a small detail. Um... that is, say you want to change the font on a button inside a combo box - you have to override the combo box to use a different list item class that uses a different button component which creates a differently styled textfield. Unless the developer happens to have implemented that all-important 'kerning' parameter that your designer is insisting you perfect...


So yeah. I don't like Flex because it
1) encourages lazy development practices by purporting to be 'fast' and 'easy'
2) mixes view with model with controller in XML files that can only get bigger
3) creates artificial barriers to the level of customisation necessary for any Flash app with the flawed 'state' model
4) has an ugly default look and feel
5) has components that don't quite do everything you'd expect (try using the keyboard or mouse wheel on some things and you'll see what I mean)
6) results in a lot of tangled up event listeners

I see all of these problems as coming from the parameterised component paradigm, although if the implementation was as good as Apple's then I might be a bit more interested. However, even with Apple's implementation I quickly found myself wanting to return to a code-based UI construction process, cos, you know - why hard code x and y coordinates all over the place when you could have a couple of static constants in your source and work everything else out at runtime?