One of the most important concepts to understand about Flex is the relationship between the Flex framework and Flash Player. Flash Player is a runtime environment for Flash and Flex applications. It can run .swf files, which contain bytecode that can communicate with Flash Player, instructing it to perform operations such as loading images, drawing graphics, making HTTP requests, and so on. Flash and Flex applications can do only what Flash Player allows them to do. Flash Player provides an API for all the operations it can perform.
Flex applications run in the same Flash Player as Flash applications. That means the .swf files for Flex applications cannot contain anything that a standard Flash application can’t contain, and therefore, both applications have the same behaviors. This is because the applications contain only the instructions, and Flash Player is what runs the instructions. Therefore, what differentiates Flash and Flex applications is not the content, but how you create that content.
Flex consists of a compiler that is capable of compiling MXML and ActionScript. The entire Flex framework is written in ActionScript and MXML. It provides a layer of abstraction. The Flex framework consists of many thousands of lines of code, all of which ultimately run instructions that Flash Player can understand. This means that when you utilize the Flex framework, the compiler will include the necessary libraries in the .swf files. As a result, you can much more rapidly develop applications. For example, although you could write your own custom grid layout container or combo box UI control, doing so takes a lot longer than simply using the components that are part of the Flex framework.
The trade-off of using the framework is that the file size of the .swf increases over an .swf created without the use of the framework. This is in contrast to ActionScript 3.0-only projects that use none of the Flex framework. If you don’t use the framework, increases in .swf file size are in pace with the amount of code you write (or libraries you use) and the assets you compile into the file. Native Flash Player ActionScript classes already exist within Flash Player itself; they don’t have to be compiled into the .swf. Yet, when you work with the Flex framework, a single line of code that adds a framework component can add a nontrivial amount to the file size because it requires the compiler to include a class or a library of classes that aren’t part of Flash Player.
You must determine on a case-by-case basis whether the trade-off in added file size is worth the benefits of using the Flex framework. This is a very subjective issue. However, noting that Flex applications are rich Internet applications (RIAs) targeted at broadband audiences, the few hundred kilobytes added by the framework in the typical application are often viewed as inconsequential.
Note
You can also leverage the Flash Player caching feature to cache the Flex framework in order to reduce .swf file size. This feature is discussed in more detail shortly, in Caching the Framework.ˮ
You can easily differentiate between Flash Player and Flex framework classes using these guidelines:
If the class is in a package starting with the word flash (e.g.,
flash.net.URLLoader), it is part of Flash Player.If the class is in a package starting with the letters mx (e.g.,
mx.controls.Button), it is part of the Flex framework.MXML tags almost always (with few exceptions) correspond to Flex framework classes.