Flash or Flex

As a result, the Player was originally leveraged by developers in order to produce high quality images and animations. Their file sizes were small in comparison to any other available technologies of the time, and so provided faster downloads. The Player took hold quickly, and now it has a larger user base than all the different flavours of Windows put together.

This is because it is cross-platform.

It doesn't matter whether you still use Windows, have branched out and moved over to one of the more popular Linux distributions such as Ubuntu, or you have treated yourself to one of Apple's supreme and powerful beasts.

The Flash Player runs on them all.

As Adobe continued the Player's development, more and more developers found that complete web sites or applications could be built to run in the Flash Player. One of the benefits being that no matter which browser the user has, the site or application would look and function the same - completely removing the need to develop with multiple browser support in mind.

It's much better for users if the site they visit is HTML, leaving Flash to parts of the site where Flash is more suitable - the right tool for the job.

These can be areas such as audio players or video walls - You Tube utilizes the Flash Player to play back video content.

Members areas are candidates for full Flash based applications - if someone takes the step of registering for your services, they are not likely to worry about downloading the latest Flash Player if it is required.

Internal applications, where all workstations will have the required Player, can also be candidates for full Flash Player deployment.

Finally, there is the lesser known world of the Flash Player on the Desktop. There are many tools available to port the Player to a Windows Desktop based application. SWF Studio is my tool of choice.

The software provides a development environment, of sorts. The centre piece of early Flash projects was the timeline. This enabled developers to easily create time-based animations - adding basic scripting to key-frames enabled a modicum of interaction with the user.

However, as the Player evolved with new abilities, and improvements in its' scripting language, developers continued to push the boundaries of what could be done with Flash.

Version 2 of the scripting language introduced a more component based environment. This enabled developers to create re-usable components - vastly increasing productivity. The timeline became less important to serious developers, while managing and maintaining their codebase became more important as projects grew in size and complexity.

Eventually, the scripting language evolved to version 3 (AS3), an Object Oriented language. The improvements in the language provided the ability to write even more complex applications - but in a much more manageable form. The only problem was that the Flash software - the environment designed for building these complex applications - hadn't changed much - it still hasn't.

It just doesn't cut it when writing anything substantial, especially when working as part of a team. Code can go in many places, which can cause a headache for a single developer when hunting down a bug, or revisiting a project after some time. When a team works on a Flash project, unless there is strict control over where code goes, productivity can soon fall away.

Thankfully, the release of AS3 coincided with the release of Flex 3 from Adobe - a much more suitable environment for developing large scale applications for deployment to the Flash Player.

Removing the timeline meant that there was no more code scattered around different key-frames on different timelines in different Flash files.

AS3 meant that the Object Oriented world had reached the Flash Player - making it easier to produce well designed applications.

MXML was introduced. This is a markup language which provides a simple way to describe the view - the part the user interacts with.

The combination of MXML and AS3, meant that there were natural, logical places to put code - immediately improving productivity. Designers and developers were able to focus on their own tasks. The designer could build the view in MXML, while the developer could focus on the layers of the code that bind it all together.

Creating code libraries that can be shared across projects is simple. Creating single use components is trivial.

Creating applications with an MVC (Model, View, Controller) architecture is a breeze.

In short, Flex can be used to display an image in a web page, to build an enterprise level application, or anything in between - it's the skills of the developer that determine where the boundaries lie.