The change from Fx prefix to namespaces is an EPIC FAIL for Flex opportunity to concentrate on making Flex 3 to Flex 4 migration seamless

Update: OK, so everyone's caught up on the EPIC FAIL title (hey, it got your attention!) so I've changed it — I retract my original statement: it's not an EPIC FAIL, heck, it's probably not even a FAIL. However, it's definitely a FOL, so let's move on to address the real issue here which is that it's in all of our interests to make Flex 3 to Flex 4 migration as easy as possible. As such, please read my follow-up post, The Flex 4 One-Step Migration Challenge and let's try and make a list of the Flex 4 migration challenges for Flex 3 apps and try to address them.

Please also note what I mean by "migration" (from the comments):

I don’t consider simply compiling a Flex 3 app to constitute Flex 4 migration … If you’re migrating to Flex 4, you are most likely doing it in order to take advantage of Flex 4 features and thus you will want to layer in and/or transition to Spark components at some point and that’s when you will require more extensive namespace changes to your entire codebase. (And you real apps have dozens, if not hundreds of source files, libraries, skins, etc., all of which have to be reviewed and possibly updated.) That’s the use case that I feel we must make as painless as possible.

Having an easy migration path from Flex 3 to 4 will benefit all concerned and I cannot see how trying to make that process simpler (via an effort such as the 1-step migration challenge, etc.) is a bad thing.

Original post follows…

Flex Fail Whale (with apologies to Yiying Lu)

I just upgraded a simple app I wrote yesterday from an earlier version of Flex 4 (Gumbo) to the latest SDK and I got hit with the Fx prefix to namespace changes. Needless to say, I'm not impressed at all.

With the Fx prefix, I could easily layer Gumbo functionality into my existing apps and easily mix Spark and Halo without changing existing code or libraries. This ability is now gone.

I had to go through both my code and third-party libraries to add namespaces and I even had to alter the CSS. Previously, I had no such headaches and everything Just Worked (tm). Mixing Flex 3 and 4 was a joy. Not any longer.

This is a huge step backwards for anyone wanting to migrate existing Flex 3 apps to Flex 4 or reuse components. It makes the transition to Flex 4 and the creation of hybrid Flex 3/4 apps a real pain. It’s the triumph of formalism over pragmatism and the platform will suffer as a result.

And this namespace soup is going to make it all the more confusing for people new to the Flex platform to make sense of things.

Flex and similar technologies are commodities and compete in a supply market. The simpler things are, the more people will use them, and the higher the chances of the platform surviving and flourishing. Simplicity, user experience (yeah, even for a framework/platform) are key.

This namespace change adds lots of complexity for very little gain. It may satisfy the formalists who are probably as we speak trying to find a way to incorporate XSLT into the Flex workflow somehow and whose wet dreams would be a shift from ActionScript to Java for the platform but I hope that everyone involved understands the ramifications this move will have on developers who are new to the platform (so is that mx: again? No? fx: ... oh but that tag is s: and oh, that’s the language namespace but that’s a library... what again? huh? Just a sec, I think SilverLight was easier...) as well as for people migrating and transitioning existing Flex 3 applications.

Flex gods, please reconsider.

Update: As some of you have pointed out, my experience was exacerbated because I was porting from a previous version of Flex 4 to the latest Flex 4 SDK. You're right that this made my porting experience more difficult than a straight Flex 3 to Flex 4 port would have been since I had removed namespaces on all mx and Spark (previously Fx) components. However, I stand by my core point which is that the introduction of these language and library namespaces, along with namespaces in CSS makes it more difficult than necessary to port apps and will be more confusing for developers who are new to the platform.

A number of you have pointed out that the Fx prefix was not a long-term solution and that we would be faced with a similar choice for Flex 5. I don't feel that that's accurate. Flex 5 could keep using the Fx prefix for new components as I don't see such a radical overhaul of the component system occurring in the next version.

And while it's true that we already have namespaces, we've now introduced two framework-level namespaces and separated library namespaces and also introduced namespaces into CSS. Basically, we've introduced a lot of complexity for what I would argue is very little gain.

I'm sure tooling will take care of some of this complexity (and that should work in Adobe's favor and translate to more Flex Builder licenses sold even though they were not the ones to instigate this change). However, when you have to rely on tooling perhaps the problem is that the underlying technology is too complex. There is something sublimely beautiful about not needing any tooling whatsoever in Python, for example, that speaks volumes about the elegance of the language. Let's just say that I don't believe Flex would be in this namespace soup if Guido were calling the shots.

That said, Flex is still the most elegant rich-client technology I know. Yes, I love the tools in Cocoa and Objective-C is quite a marvelous achievement when you consider the limitations of C that they had to work with but there are also up-and-coming contenders ranging from Nokia's Qt to Unity 3D that are vying for the limited attentions of developers in a supply market. Simplicity is a key factor in differentiating your platform and wooing developers.

Simplicity is not something to be ashamed of. It does not make your Code Fu any less if you have simple tools and languages to work with. It just makes you all the more productive and lets you concentrate on crafting that most important part of your application: the user experience.

Flex is simple. We should try our utmost to at least preserve this simplicity, if not to take it a step further in each release.

Flex Fail Whale from Twitter Fail Whale by Yiying Lu