Adobe® Flex™, the Right Way for RIAs
Article Library

Adobe® Flex™, the Right Way for RIAs

August, 2006

Abstract  This article examines the phenomenon of Rich Internet Applications (RIAs) and the related history, lists the requirements for RIA development, and explains what Adobe® Flex™ is and why it is the right way for building RIAs.

This article introduces Flex™ at a high-level, giving developers a quick technical review of what Flex™ is and how to develop Flex™ applications.

 

The release of Flex™ 2 in mid-2006 is a good news for web application developers and users, because Flex™ provides a right way for building Rich Internet Applications (RIAs). It can produce applications of rich and smooth user experience in a relatively painless and enjoyable development process.


Understanding Rich Internet Applications (RIAs)

To understand the Rich Internet Application phenomenon, it helps to look back in the history of network computing.

Period Key Event Major Technology Key Idea Description
beginning - 1990 IBM, Unix, VAX/VMS Centralized Computing Machines running multi-tasking operating systems shared by large number of dumb terminals. At first, computers were expensive. Multi-tasking operating systems allowed expensive computer hardware to be shared by many users, working at the relatively cheaper dumb terminals, where computations and business were highly centralized on the host machine.
1990 - 1996 Microsoft Windows 3.1 and successors Distributed Computing Computing is distributed across servers and desktop PCs.

Windows PCs swept dumb terminals out of corporate desktops. The idea was to distribute computation across different machines to take advantage of the computing power of the client machines. Distributed computing was a loose term. It entailed many different architectures, such as peer-to-peer and client-server.

The client-server computing leaves servers to handle business logic and data persistence and have client programs to handle information rendering and user interactions.
1995 - 2005

Netscape and Microsoft Internet Explorer Browsers

JSP, ASP, PHP, ...

Web Application

The Server Page Anti-Pattern

 Servers processes both business and UI logic; clients (i.e., browsers) merely render the UI and take rudimentary user input. This is an era of dumb GUI terminals.

With the excitement of the World Wide Web, people pushed the limit and made HTML an application platform, resulting in the anti-pattern of server page templating technologies.

Server pages constitute a huge anti-pattern because the servers not only handle business logic but also generates UI screens, page by page; they result in poor user experience and cause unnecessarily heavy server load and wasted network bandwidth.
2005 - future

AJAX, Laszlo, Adobe® Flex™

 Rich Internet Application (RIA) Servers only handle business logic; rich client programs render the UI and handle user interactions over the internet.

This is going back to client-server computing. The only differences are that, client-server communications are now distinctly across internet; the OS- and browser-agnostic rich clients provide desktop user experience.

It takes the smartest collection of people 10 long years to get this right. Now, we are on the right track.


The Requirements for Good RIA Technologies

RIAs are full-blown distributed applications. They are both client- and server-heavy. As we all know well, UI development takes a large amount of work to start, and their improvements never end.

In order to develop RIAs, at least these prerequisites are needed:

  1. A capable, cross-OS and cross-browser GUI rendering platform.
  2. A well-crafted GUI programming model.
  3. A powerful programming language.
  4. Versatile RPC mechanisms to communicate with the server.
  5. Necessary development tools.

What is Adobe® Flex™ and Why It is Right for RIAs

The current web client technologies, from HTML → CSS → JavaScript → JavaScript prototype → XMLHttpRequest → AJAX, are an aggregation and accumulation of after-thoughts. Building RIAs off those is a shaky practice at best.

In contrast, Flex™ is a fresh GUI technology based on the popular rendering engine, the Adobe Flash Player. With all the lessons the industry has learned about GUI building, and with resources and commitment from a company like Adobe, common sense tells that it cannot go too wrong, can it?

Indeed Adobe did not disappoint us. The Flex™ SDK is first and foremost a collection of client software libraries and development tools for building GUI applications that run on the near-ubiquitous Flash player. It meets the requirements perfectly for building RIAs.

Flash Player, a Perfect GUI Platform for RIAs

The Flash player is widely used by web sites to show flashy contents, such as advertisements, and play games. It can be launched from within most popular browsers, providing capablities that browsers are not designed for. Using Flash player to run business application is only a natural extension of its uses.

A Modern GUI Programming Model in Flex™

Flex™ defines a component-based, event-driven and CSS-enabled GUI paradigm. It uses a declarative GUI programming model with its MXML language, an XML dialect, for declaring the construction of GUI elements and event handling. The Flex™ client library contains a large collection of well-documented, rich functional components of all kinds. The MXML code is eventually compiled into ActionScript and linked with other libraries and code.

ActionScript 3, A Potent Language for Large-Scale Development

Flex™ does not use an existing language for its framework; rather, it uses its own, ActionScript 3. There are two compelling reasons for this: (a) Data binding requires extensions to the language, whatever the language may be, and (b) JavaScript and any other scripting languages are too weak for serious development while other "good" languages are either too protective or too heavy.

ActionScript 3 is an implementation of the draft JavaScript 2.0 Specification plus E4X and some proprietary extensions. It supports statically typed variables, functions and parameters, package and namespaces, and declarative class definitions for familiar object-oriented programming. It is (largely) backward compatible with JavaScript 1.5, maintaining the prototype-based dynamic object construction and inheritance. It is a language that you can discipline yourself most of the time but leaves backdoors to more dynamic and dangerous operations when they are truly necessary. It is a great language.

Flex™ Has Many Remote Call Mechanisms

Flex™ client library includes at least these remote call mechanisms:

You have the liberty to choose the best mechanisms for interacting with remote resources.

Flex Builder™, A Powerful IDE for Truly Rich Application Development

The Flex Builder™ is a powerful IDE for building Flex™ GUI programs. The WYSIWYG (What You See Is What You Get) GUI component editor feature is good for new developers to quickly design UI with MXML. For experienced developers, its auto-complete editing for MXML is probably more helpful. The syntax-sensitive ActionScript 3 editing is also a great help; the IDE points out syntax errors and gives warnings on inappropriate code.

The ActionScript 3 debugger is similar to Java's remote debugging; the IDE connects to the running Flash player for you to debug. Tracing into the code and objects at runtime is crucial for GUI development; it not only quickly reveal your code defects, but allow developers to inspect the object chains at runtime to figure out the right objects (in the DOM tree) to use.

Flex™ is a Complete Solution for Building RIAs

Flex™ SDK contains compilers and other tools for application development and deployment. The Flex™ applications can be deployed as a single SWF file or as a congremoration of multiple Runtime Shared Libraries (RSLs). It is a good practice to use Cascade StyleSheets as much as possible to segregate UI logic from its look. You can either embed or reference multimedia content. Flex™ is a complete solution for building RIAs.


Other Good Choices for RIAs?

Are there other good choices for RIAs? There must be more options.

Java applet was first introduced to the world to demonstrate Java. Today, the Sun's Java plugin also provides a cross-OS, cross-browser GUI platform. Yet, Java plugin is not as popular as Flash (perhaps due to Microsoft's fierce resistance?) Java is a powerful general-purpose language. It is not fine-tuned towards GUI building as MXLM and ActionScript 3. For instance, it does not have GUI declarative programming, automatic data binding and UI CSS support. Nevertheless, Java applet is still a viable options for RIAs.

Another option for RIA would be the Dojo Toolkit. However, being a DHTML solution, the Dojo Toolkit suffers from two critical concerns: a) its reliance on disparate DOM implementations (Internet Explore and Mozilla) and b) its use of the JavaScript language. Being a DHTML solution, it does not have much choice. Nevertheless, these two issues ensure a very stressful development process and unpredictable quality and costs. Learn more from Dojo Explained.

Imagine that you were to be the architect for "Dojo NG", the next-generation Dojo; what would you do? You would probably like to do these:

  1. Create a common render engine free from the IE and Mozilla DOMs.
  2. Formalize the Dojo Markup Language and rule out HTML markups altogether.
  3. Enhanced the JavaScript language to include static typing and declarative class support. Or simply use a stronger language such as Java.

These are exactly what Flex™ has done; the Flex™ counterparts are:

  1. The Flash player,
  2. The declarative GUI XML language of MXML and
  3. The potent programming language of ActionScript 3.

This proves, from a different angle, that Flex™ has done it right.


Myths About Flex™


Myth 1. Flex™ is Only for Flashy Applications

Flex™ applications are like any enterprise applications with list boxes, buttons, grids, trees, etc. You can have Flash animations in your application, but that is not the focus of Flex™. Flash and Flex™ are two different concepts.


Myth 2. Flex™ Applications Are Slow and Big

The slowness concern stems from two aspects: slow to download and slow responsiveness of the application. The first concern is related to the size of the generated SWF file.

The Flex™ compiler tries hard to reduce the size of the generated SWF executable files. It only links in the used code, not whole libraries. For an empty Flex™ application, the SWF file is about 100K bytes. With loads of functionality built into the application, the file size typically grows to a few hundred kilobytes. There are other ways to reduce the SWF file size, such as not to embed less frequently used resources and leave less important contents (e.g., text) to be downloaded separately.

It would take a lot more JavaScript code to provide the same capabilities as Flex™, along with a lot of complexity. Flex™ applications are inherently big because they are big applications, not simple page embelishments.

Flex™ applications may behave sluggishly from time to time. When server interactions occur, this sluggishness is caused by the network latency and is totally legitimate. Other times, the Flash engine may respond reluctantly to local user actions; depending on your programming, this may happen more or less. Most of the time, it is not unbearable for users. Like Java, Flex™ programs run in Virtual Machines, so expectedly they do not respond as smoothly as native executables such as Windows programs.


Myth 3. Flex™ Applications Are Not Customizable

Not true at all. Flex™ GUI programs are constructed as DOM trees. You can manipulate the DOM tree almost as freely as you wish. Suppose you are shipping a Flex™ product, and allow your customers to customize it. First, package the program into RSLs (Runtime Shared Libraries) with one main module and several others. The customization happens when the customer writes their own main module, where they can instantiate components from your other RSLs and manipulate the DOM tree to produce their own customized program.


Myth 4. Flex™ Is Not Open Source

The Flex™ client library is open source. The source code is included in the SDK (and subsequently, Flex Builder™). The Flex™ compilers as well as the ActionScript 3 Virtual Machine are being open-sourced.



Seeing is Believing

No matter how great a technology is told to be, only you can tell by using it. Download the Flex™ and Flex Builder™, buy a book or two, and try it out. It is easy to get started, because the whole Flex™ is built on top of common sense that you can easily relate to your past experiences.

Related Articles:



Copyright 2007,2008 RiaOne Company. All Rights Reserved.