I was talking with a Ryan Knight, a co-worker at Gorilla Logic, about our general impression of Flex.  We are both developing significant functionality with Flex these days, and we quickly agreed that are some real pain points.  I boil most of these down to immaturities, and do expect Flex to overcome most of these as the platform matures.

One of Ryan’s examples was the Flex Date class, which for some odd reason is final.  This is of course problematic, and a bit bizarre to have something like this be final.  This caused Ryan’s projects challenges because the default behavior was causing issues, and they had to override the AMF serialization to overcome the issue, which is overly involved.

A similar pain for me was ArrayCollection (see previous post).  In my previous post, I didn’t discuss our attempts to extend ArrayCollection to control the typing when they are created from our Remote call.  First off, I was quite surprised to realize that ArrayCollection doesn’t have its own interface, as my first attempt was to hold the data in an Array and lazy instance the ArrayCollection by delegating to a private ArrayCollection.  Second, I tried to extend and wanted to not call the super constructor, but this was problematic because the compiler inserts super even if I omit it. Anyhow, as each typical object oriented approach ended in a road block, it seemed to being highlighting a real immaturity.

I won’t bore you with all the issues we banter about, but it is important that Flex evolves in the next 12-18 months.  Also, I do respect how difficult it is to design a good API, and I am not claiming that I would fare any better.  All that said, I am hoping to see the framework take huge steps forward with next year’s Flex 4 release.

I hope you made it this far because I did bury the lead a bit… Ryan and I both agree we still love Flex overall, and that wealth of components still makes it possible to build things simply not possible in many of the popular Java frameworks.