Flex Uncertainty Doubt

If you are evaluating Flex and attempting to pitch it to your management, these are some issues that you are likely to encounter. As with any new technology, you encounter a mix of reality and FUD. This is my attempt at objective analysis of real and perceived issues with Flex that one typically hears.

1. Flex applications are too bulky - An empty Flex 3 application produces a swf file of roughly 150K size. Full-fledged applications can produce swf files of hundreds of kilo-bytes or even mega-bytes. This has historically been a problem. However, with current versions of Flex and the Flash Player, this can be mitigated in 2 ways - modules and framework RSL caching.
   
• A Flex application can be broken down into modules with each module being loaded only when needed e.g. on application startup, only the login module is loaded. This reduces the amount of bytes going across the wire each time, as the application is loaded in pieces depending on user interactions.
  
• Bulk of the size of a swf file is due to the Flex framework code. The Flex framework can be loaded once as a runtime shared library (RSL) across all applications and cached by newer versions of Flash Player 9 even across domains. So your application does not have to statically link in the Flex framework thereby reducing its size.
2. Why not just do everything with Flash Authoring (CS3?) - Flash Authoring is a designer tool while Flex is a developer tool. Flash Authoring is for producing creative, stylized content such as animations and graphics. Flex is the framework for application development. The typical usage is to build graphical assets in Flash Authoring, and bring them into Flex to incorporate into Flex components. Of course, if all you are doing is producing intro-screen Flash movies, stick to Flash Authoring. If you are building applications with re-usable components and business logic, use Flex.
   
3. Flex involves license fees to Adobe - The Flex SDK with its UI component library and command-line compilers is free. Flex Builder Eclipse IDE Plugin has to be licensed (no runtime license involved though). If your application uses server-side Flex Data Services (now called Live Cycle Data Services), that involves a significant runtime license to Adobe although a portion of it has been open sourced as Blaze Data Services.
4. Flex is proprietary - Yes, Flex is proprietary. But Adobe plans to open-source the Flex SDK - see this.
   
5. Flex applications are poor at rendering text/HTML - This is truly one of the big issues with Flex applications (actually this is a Flash Player issue rather than a Flex issue). Text layouts taken for granted in HTML are difficult to do with Flex. Flex has issues with system fonts and font embedding results in very large swfs. Adobe plans to provide better text support in Flash Player 10 - see this. Adobe's acquisition of Buzzword - the Flash-based word processor - shows its commitment to filling this gap.
   
6. Flex is not internationalization friendly - The lack of support for RTL (right-to-left) languages such as Arabic and Hebrew is a huge drawback. This is really a Flash Player issue and Player 10 is supposed to fix this - see this.
7. Flex applications are not skinnable - Flex supports applying CSS-based styling. However the drawback is that style sheets are compiled into swfs and cannot be changed without compilation at runtime by editing a .css text file (See this enhancement request).
   
8. Flex is architecturally inferior to Java Server Faces (JSF) - The comparison to JSF might not be an apples to apples comparison.
• JSF is a server-side framework while Flex is client-side. Flex can take advantage of the power of client-side processing that typical JSF applications cannot.
  
• JSF provides a formalized Model-View-Controller (MVC)-based framework with a component and event model for Web applications. While Flex provides an excellent component and event model, it does not have a full, formalized MVC framework out-of-the-box. One has to use frameworks such as Cairngorm if a rigorous, formalized MVC framework is required.
• In contrast to JSF Web-page type applications, building Flex applications are like building thick desktop applications (that happen to run in a Browser). Unlike JSF, in Flex one does not think in terms of pages rather in terms of application state. Therefore, the JSF notion of a controller that orchestrates page flow does not directly apply to Flex.
  
• JSF render kits for different UI channels is a great concept that works for output channels where there is server-generated markup such as HTML for browsers and WML for phones. Stretching this concept to server-side rendering of full-fledged thick client applications such as Swing, WPF or Flex is practically infeasible beyond a "Hello World" application.
9. Flex applications don't play well with the Browser back button and URL bookmarking - This is a valid concern. As noted earlier, Flex applications are like thick desktop applications where one does not think in terms of pages as in traditional Web applications. However, users are used to Browser Back/Forward functionality and bookmarking pages, and are likely to use it. Hitting the Back button with a Flex application may take the user to the page he was on before navigating to the page that loaded the swf. Bookmarking may not bookmark the state the user was in within the Flex application. The solutions to these issues include Flex's deep-linking and toolkits such as UrlKit. The solutions however require extra coding effort.
   
10. Flex applications are slow - Flex applications may be slow to load initially because of the size of the swf files (see 1. for ways to mitigate this). However, Flex applications allow for client-side processing that can provide superior interactivity on subsequent interactions by reducing server round trips. Using the optimized, binary AMF3 message format that Flash natively understands, one can achieve significant performance improvements over text-based formats. The new ActionScript Virtual Machine (AVM) in Flash Player 9 with JIT-compilation provides an efficient runtime for executing swf byte code. JavaScript in the Browser may some day come close to this performance, but it is not going to be happen anytime soon (see Tamarin).
11. ActionScript is yet another language to learn - ActionScript is very much like JavaScript (both based on ECMAScript). ActionScript 3.0 is based on Edition 4 of ECMAScript which is also the same base for JavaScript 2.0. which is not finalized yet. Adobe is ahead of the game with ActionScript 3.0 but it is likely that in the future ActionScript 3.0 == JavaScript 2.0.
12. With Flex I'm tied to the Flash Player and locked into Adobe - Yes you are tied to Adobe's Flash Player but the Flash Player is ubiquitous and free. As noted earlier, Flex is being open sourced. With the Flash Player, there is of course the issue of being dependent on Adobe for any enhancements you may need to the Player. For example customizing Flash right mouse-click context menus is not possible to the extent an application may desire (see this) and one has no choice but to depend on Adobe to fix it if and when it chooses to.
    

Flex is still relatively new and is likely to improve along with improvements to the Flash Player. But it is part of an emerging and significant change in the Web 2.0 RIA landscape. Flash-Flex/AIR and Silverlight/WPF are ushering in the next revolution in Web and Desktop applications which are easier to build and provide superior user experience. The days of DHTML AJAX applications and the struggle to provide rich user interfaces that work consistently across Browsers are numbered. The Web 2.5 (r)evolution is here.