I will first list some of the most common criticisms and disadvantages correctly or incorrectly associated with Flex (and Flash) and then provide brief detail on things that address these issues. I welcome feedback in the comments section on any criticisms or disadvantages that I have missed and any events or methods that reduce the disadvantage or criticism.
Commonly Cited Flex/Flash Criticisms and Disadvantages
1. License Costs
2. Not Open Source
3. Perception: For Movies and Animation Only
4. Application Load Time
5. Development/Productivity Tools
6. Flash Player Dependence
7. No 64-bit Flash Player
8. No URLs, Histories, or Bookmarks
9. Searchability / Search Engine Optimization
10. Adobe Commitment to Flex
11. Flash Player is Single Threaded
12. Flex is Not a Standard
1. License Costs
For a long-time, one of the most significant criticisms of Flex that prevented developers from adopting it was its licensing costs. In fact, in his now well-known article Hybridizing Java, Bruce Eckel (a well-known Flex evangelist featured in Adobe advertisements for a while) even states that Flex's former licensing costs affected how much he used and wrote about Flex. This movement started with Flex being released for free use outside of commercial products and then moved to a fully free Flex SDK. I still occasionally see developers stating in blogs or on comments on blogs that they won't use Flex because of its licensing costs, but for much of Flex this is simply not the case anymore. There are some "extra" Flex features that still do require license fees for commercial use, but Flex applications can be written without these.
2. Not Open Source
While there are advantages to a product, library, or framework being open source, calling something open source does not necessarily make it better than competing alternatives (witness all the dead open source projects out there) and does not necessarily make it free of cost (free speech versus free beer). Still, there are a growing number of developers who desire "open source" as one of the most significant characteristics of the products and frameworks they choose. For them and even for those of us who prefer open source when it is competitive in other aspects as well, it was good news when Adobe announced the open sourcing of Flex. Major components of Flex 3 (SDK, debugger, etc.) were released as open source. Shortly before Flex 3's release, Adobe also released BlazeDS (especially useful for Flex-to-Java communication) as open source.
There are optional portions of Flex that are still not open source and/or still require licensing fees, but these are not necessary to create fully functioning Flex-based applications.
3. Perception: For Movies and Animation Only
With the issues of licensing costs and not being open source mostly resolved, a common concern (or really more of a question) that I hear from many developers is something along the lines of, "Isn't Flash really only for games, movies, and animation?" and "Can you create an HTML-like web form with Flash?" The answer is that Flex really is "Flash brought to the Java (or other programming language) developer." By this, I mean that the Flash applications many people are familiar with are more likely designed by a specific Adobe product by designers rather than by developers or programmers. Flex provides a rich component set out-of-the-box with the free and open source SDK, adds a couple more components with the for-a-fee FlexBuilder, and there are numerous third-party Flex components sprouting up all over the web. These components include many HTML-like components along with many richer components that rival or even exceed the component sets provided by the many fine JavaScript libraries. If one wants to, one can make a Flex-based application look nearly identical to any HTML/JavaScript application. However, Flex is usually desired for "richer" applications and hence is often used with Rich Internet Applications rather than more traditional HTML/web applications.
4. Application Load Time
As part of the RIA experience, Flex-based applications tend to load more than DHTML applications initially, but then often have reduced reloading and server communication after the initial load. However, this means that a Flex-based RIA can often take longer to load initially than a DHTML-based RIA.
Adobe continues to work on improving the performance of the Flash Player to reduce this disadvantage. The relatively recent announcement of the new Flash Player Caching is very welcome in this area.
There are several tactics Flex developers can take as well to reduce the initial load time. For example, the Flex TabNavigator has a creationPolicy attribute that allows all tabs in the navigator to be loaded at load time (
ContainerCreationPolicy.ALL) or have only the initially visible tab loaded (deferred instantiation with ContainerCreationPolicy.AUTO).Links to other ideas for improved Flex performance are available in the article Flex RIA Performance Considerations Part 1: Getting Started. Part 2 in this same series focuses on application startup.
5. Development/Productivity Tools
Another early criticism of Flex was the lack of IDE and tooling support that Java enjoys. This, of course, is just as deserved and just as common complaint for many other highly useful languages as well. However, Adobe has released FlexBuilder, an Eclipse-based Flex IDE. While Adobe does charge a licensing fee for FlexBuilder and while FlexBuilder (like most IDEs) does have room for improvement, it is also true that FlexBuilder comes with many nice features for making Flex development more productive. Because it is Eclipse-based, it is fairly easy for Java developers familiar with Eclipse to learn and use.
The author of the entry Flex 3 Vs Silverlight and JavaFX - Is Adobe Listening? maintains that Flex "may die on the vine" because it charges for FlexBuilder. As outlined above, the making Flex itself available for free did undoubtedly help increase its adoption, but the cost difference is significant. Flex formerly had license fees costing thousands of dollars while FlexBuilder fees are measured in hundreds of dollars. Still, many IDE vendors do offer free IDEs already (Eclipse, NetBeans, and JDeveloper for example). While I agree the licensing fee required for FlexBuilder must have some impact on Flex's adoption rate, I'm not convinced that it has been or will be as great on the long-term adopters of Flex as maintained in this entry.
For those who don't want to purchase FlexBuilder, there are some alternatives. Because both MXML and ActionScript are text-based, even a simple text editor will work at a minimum level of functionality. Because Flex MXML is an XML grammar, any XML-aware tool can be used to provide some advantages to working with MXML. For example, I have blogged previously about using NetBeans XML support and JEdit's XML support with Flex. One can go even beyond simple XML handling with more specific editors like Spket IDE and Aptana.
6. Flash Player Dependence
Some developers have had such negative experiences with Flash-based applications that they have a hard time even considering Flash (and hence Flex) for their web applications. There are many reasons for this resistance to the Flash Player, including wanting to avoid a proprietary runtime and not liking Flash application experiences in others' applications. The latter point can be partially addressed by considering that just because someone else abuses a language or framework doesn't many I need to. If that was the case, no language or framework would be acceptable because they all get abused by someone.
Related to the proprietary nature of Flash, there are some mitigating conditions to consider. The OpenScreen Project was huge news for Flash running on devices because it is intended to remove restrictions on two major Flash-related specifications (SWF and FLV/F4V) and to remove license fees for both AIR and Flash Player. Another interesting development occurred when Adobe and Mozilla partnered in the Tamarin Project to include the ActionScript Virtual Machine (AVM).
7. No 64-bit Flash Player
While the Flash Player is nearly universally available in 32-bit architectures, it is not available for 64-bit architectures. This has been a particularly loud complaint from Linux users, though Microsoft Vista developers are starting to request a 64-bit Flash Player more actively as well.
This concern can be partially addressed by running the 32-bit Flash Player on the platform, such as on a 32-bit browser running on the platform. In Flash 9 on 64-bit Linux in 2 Commands, James Ward covers how to use the Flash Player on 64-bit Linux. Likewise, Darron Schall has written about running Flash Player on 64-bit Linux platform in Installing Flash Player 9 on 64-bit Linux. Interestingly, James Ward points out in Where is 64-bit Linux Support for Flash Player? that one of the major hold-ups on a 64-bit Linux Flash Player is the need to upgrade the Tamarin project discussed briefly in the criticism above.
UPDATE (24 November 2008): Adobe has announced the release of an alpha version of Flash Player 10 for 64-bit Linux. An excellent review of life in Linux without this release is available in Adobe Starts 64-bit Flash Testing with Linux Alpha. The excitement in the Linux community over this is documented in One More Reason for Linux Lovers to Give Thanks.
8. No URLs, Histories, or Bookmarks
A common complaint about Flex-based RIAs that is really common to even many Ajax-based RIAs is the inability or difficultly involved in letting web users use meaningful URLs in histories and bookmarks. This was easy and expected in static web pages and even in more dynamic web sites that completely reloaded the page after each server request. With Ajax and Flash-based RIAs, these things are not quite so easy now. Just as many of the Ajax/DHTML frameworks have begun to provide support to ease the developer's ability to allow users to use URLs for bookmarking and histories, similar approaches have sprung up for Flex. However, the really good news was Flex 3's support for BrowserManager and deep linking. Approaches of use in this area (including the Flex 3 BrowserManager to perform deep linking) are covered in Flex 3 Features: Deep Linking in Flex 3, Flex 3 BrowserManager, and Flex 2 Applications and Bookmarking 101. Deep linking only works on select browsers (the most significantly used ones though) and takes a little extra effort, but does provide benefits associated with changing URLs in a web application.
9. Searchability / Search Engine Optimization
Another commonly discussed disadvantage of the Flash Player is the inability of search engines to index the binary content of a Flash application. A command work-around has been to developer HTML "wrapper" pages for the SWF applications that includes terms that the search engines can find. This tried and proven method works, but there are even more advancements coming. Google, Yahoo!, and Adobe have announced their combined effort to better index the text content in Flash applications. Considering the dominance of Google and Yahoo! in the search engine business, this is a big deal. In addition, it sounds like this approach will be made available to other search engines in the future if it works out well.
10. Adobe Commitment to Flex
Some of have questioned Adobe's commitment to Flex, especially in light of Adobe's early interest in SVG (Scalable Vector Graphics) followed by seemingly significantly reduced interest in SVG. While I don't work for Adobe and have no knowledge of what they may or may not do, I don't worry much about this particular criticism because Adobe's products still continue to support SVG to a large degree. More importantly, however, it appears to me as an outsider that Adobe has placed significantly more emphasis, time, and resources into Flex. Also, it is only anecdotal observations, but it seems to me that Flex is gaining popularity much more rapidly than SVG did. This is not too surprising because, as much as I like SVG, Flex is in many ways appealing to a wider audience of developers than SVG. The fact that Microsoft and Sun are trying to match Flex with their Silverlight and JavaFX products respectively demonstrates to me that all three of these major players believe there is a future in the RIA application development business.
For a series of articles spelling out obstacles and competitive forces that Adobe faces with Flex, see the three-part series Flash Wars.
11. Flash Player is Single Threaded
I won't write much about this here because Matthew Fabb's blog entry Multi-threading is Coming (Sort of) to Flash Player 10 does such a great job of articulating (based on his attendance at Jim Corbett's Flash Player Internals presentation at FITC) the issue and good news in that area. He describes how Flash's single-threaded architecture can be a limitation in Flash-based (and hence Flex-based) applications and how Flash Player 10 will be providing some multi-threading support.
12. Flex is Not a Standard
I saved the common criticism that I think is most overblown for last. Flex is based on the W3C standard XML specification (for Flex's MXML) and the envisioned ECMAScript standard [ECMA-262 Edition 4] (for Flex's ActionScript 3.0), including support for E4X (ECMAScript for XML).
While DHTML/Ajax can be argued to be based on standards [(X)HTML, CSS, JavaScript or JScript (ECMAScript implementations)], practical implementations are seldom if ever truly completely specification compliant because the most popular web browser does not allow them to be! The respective browser DOMs are a huge source of differences. I have stated before that standards and specifications are only as good as their implementations. As long as the dominant web browser requires developers to write non-standard code, it is difficult for me to understand how Flex with its standards-based MXML and ActionScript is so much less standard than writing DHTML/Ajax implementations. In fact, the heart of many Ajax applications is XMLHttpRequest, which itself has not been a standard (though it is now in-work at the W3C).
It Doesn't Need to Be One or the Other
Before concluding, I think it is important to point out that there is no need to necessarily use Flex/Flash instead of DHTML/Ajax or to use DHTML/Ajax instead of Flex/Flash. They both actually complement one another nicely and provide benefits to each other. An example is the discussion above about putting text in HTML wrappers of Flash applications for searchability benefits. On the other side, Flash can provide much easier approaches to rich interaction than via JavaScript. The combination of Flex and DHTML is so powerful and expected to be so popular that Flex 3 folded in the Flex-Ajax Bridge into the standard Flex SDK.
Conclusion and Request for Feedback
In this blog entry, I've attempted to outline common criticisms and cited disadvantages of Flex (and Flash). Some of these were valid but have been overcome by events. Others are still valid, but most of them have been at least partially addressed with modern advances in Flex and Flash. I like forward to additional concerns being addressed in future releases of Flex and Flash.
I also encourage you to add any other drawbacks or criticism you have from using Flex and Flash in the feedback section along with any approaches you may have used to overcome one of the drawbacks listed here or in the feedback section. Thanks in advance for your input.
Other Resources with Flex/Flash Criticisms
* Flex 3 Versus Silverlight and JavaFX: Is Adobe Listening? [FlexBuilder not free] (24 July 2008)
* Flash Wars: Adobe Fights for AIR with Open Screen Project [Part 3 of 3] (7 May 2008)
* Flash Wars: The Many Enemies and Obstacles of Flash [Part 2 of 3] (6 May 2008)
* Flash Wars: Adobe in the History and Future of Flash [Part 1 of 3] (5 May 2008)
* Flex Versus Ajax (9 July 2006)
* Why Flex 2 Isn't (8 March 2006)
* A Look at Rich Internet Applications (July/August 2004)
* Is Flash Good or Bad?
No comments:
Post a Comment