The Case Against Flex-Based App UIs...Really?

Last week, someone pointed out to me this article from intelligententerprise.com and asked for my thoughts on the author's arguments. In his article the author compares RIAs built with Flex to those built with Java Applets. While there are similarities between the two conceptually, any Flex developers who experienced building an enterprise application with AWT and Java 1.1 will surely agree that they have many differences.

So, here is my take on his "arguments".

"They almost always violate web accessibility guidelines"

No platform for web-based applications gives you accessibility entirely for free. Flash(Flex), AJAX and even web 1.0 HTML applications require effort to make them accessible. Flex gives developers an API to make applications keyboard accessible and able to be used by JAWS. If I am not mistaken, this capability existed with Flex before any AJAX framework had it. One could argue that making a straight HTML application accessible is far easier than making a Flex or AJAX application accessible. However, there are a lot of other user experience benefits that you can't get with plain old HTML.

"They create support nightmares"

He seems to be confusing AIR with Flex. Flex is a technology used to build applications. AIR is a desktop runtime used to run applications. AIR applications could be created with Flex, Flash or AJAX. Like any desktop application, pushing updates is not as simple as web-based ones. However, AIR does provide the ability for automatic updates that is easy to implement. "The potential for trouble remains" sounds to me like "There is no problem now but someday there might be"... you could say that about any technology. Flex applications that run in the browser have very little need to worry about this type of issue. Adobe frequently updates the Flash player but maintains backwards compatibility better than anyone I have ever seen. Applications built for Flash 5 will still run in the Flash Player 10. The only changes that may have caused problems are some security changes. While this is something that could break backwards compatibility, I would argue that it is worth it in those cases.

"They are prone to performance problems"

Memory leaks are just as likely in non-Flex applications. With JavaScript (AJAX) based applications it is very easy to cause memory leaks. Even Microsoft points out some patterns that cause them (http://msdn.microsoft.com/en-us/library/bb250448.aspx). Good developers can watch out for the types of coding patterns that cause memory leaks. FlexBuilder has tools to help developers identify leaks. With AJAX applications, it is more difficult.

"You can't easily modify them"

This is probably the most outrageous claim on here. He clearly doesn't understand how Flex applications are built. Changing the look and feel is one of the key features of Flex. Scalenine.com and fillcolors.com both showcase the ability to change the appearance of Flex applications in some cases very dramatically. The decision to not allow this type of "skinning" is really a business decision not a technology limitation. The demo situation he describes is rather amusing. None of the problems he describes had anything to do with Flex as the technology. Rather, they point out the vendor’s lack of a good interaction designer. He points out that the answer they wanted to hear was "You can modify the UI yourself on a role-by-role basis, and our platform is properly tiered, so we can show you how to customize it in a release-safe way." This is exactly what a well-designed/well-implemented application does allow for…regardless of technology.