Safari Books Online is a digital library providing on-demand subscription access to thousands of learning resources.
In the mid 1990s, the Internet began to find its way into everyday homes and businesses. Many of the early protocols of the Internet, such as FTP and GOPHER, were specifically designed for sharing files across distributed networks. This had a number of applicable business uses, but it was the introduction of the Hypertext Transfer Protocol (HTTP) that allowed for development of Internet applications. The idea of applications housed on a central web server and accessed through ultra-thin clients (web browsers) was very appealing to businesses in solving the distribution problem. Each time a user sought to use an application, the most up-to-date application downloaded from the server, so that the only maintenance needed for the desktop was updating the web browser.
The early Internet applications adequately solved the problem for which they were designed; companies’ IT staffs were free from the pains of constant software installations and could focus on other IT needs for the business. Throughout the last decade, more and more business applications migrated from client/server applications to web-based applications. In reality, the web-based applications were similar to mainframe applications: The central server (now a group of several servers, such as web server, application server, database server, and so on) housed all the logic, and the clients merely presented the data, as dictated by the server, and allowed for users to interact with that data.
While the similarities to mainframe applications were great for solving the distribution problems, early browser applications lacked much of the ease of use of client/server applications. The page-based model (that is, each user action sent a request to the server, which responded with a new page to render) frequently made it slower and more difficult for users to do the same work they had previously done with a client/server application.
The transition from client/server to web-based applications allowed businesses to save a tremendous amount of money on the costs of desktop support for their applications. It was no longer necessary to have a large staff move from desktop to desktop, installing the latest updates to each application; instead, the latest version of the application downloaded from the server each time it was needed.
Like most trade-offs, this one too had its cost. While web-based applications without the need to distribute software throughout the company saved money, employee productivity decreased, and users became increasingly frustrated. Web applications traditionally had a page-based model, that is, a user would interact with a web page. Each time a user clicked a link or submitted a form, a new page from the server replaced the current page. Even on very fast networks, it is far less efficient to re-render each page over and over again. Client/server applications were generally capable of updating data on the screen without the need to re-draw the whole screen each time. Even though it often took less than a second for screens to re-draw on web applications, over the course of a 40-hour workweek, those seconds rapidly added up, often costing an hour or more a week in lost productivity.
Looking to regain the loss in productivity, developers attempted several variations of rich Internet clients. The early Internet days saw a number of applications built in Java applets; however, these didn’t catch on as expected, due to a combination of large file size and issues with compatibility of different Java Virtual Machines (JVM) available in varying operating systems and browsers. Developers wrote a number of browser-based applications using Microsoft’s ActiveX technologies; these however suffered from a fierce platform dependency, often only working in the latest version of Internet Explorer on Windows.
Today, there are two main technologies used to create RIAs—AJAX (Asynchronous JavaScript and XML) and Flash.
AJAX is a technique for building interactive web applications. Using the browser’s scripting language (JavaScript), web pages became more responsive by exchanging small amounts of data (via XML) with the server behind the scenes, so that the entire web page does not reload each time the user requests a change. This is meant to increase the web page’s interactivity, speed, and usability.
AJAX recently came into popular use in the Internet community, but in reality, the ideas behind AJAX (using JavaScript to dynamically load data and change the data rendered on a web page) have been around for over a decade.
There are a number of highly successful AJAX applications that are popular on the web today, including Google Maps and the GMail email client. While AJAX development can be difficult because of different levels of support for JavaScript in various browsers and operating systems, a number of worthwhile frameworks are available that greatly ease the process of building applications that work across a variety of browsers.
There are currently dozens of different AJAX frameworks available, including SPRY, a framework released by Adobe, to ease AJAX application development.
The other technology that has been extensively used for building RIAs in recent years is Flash Player. Originally written as a plug-in to run animations, Flash Player has evolved over the years, with each new version adding new capabilities while still maintaining a very small footprint. Over the past decade, Flash Player has gained near ubiquity, with some version of it installed in more than 97 percent of all web browsers on the Internet. Since 2002, Macromedia (now part of Adobe) began focusing on Flash as more than an animation tool. And with the Flash 6 release, Macromedia began to provide more capabilities for building applications. Macromedia found that with the combination of the ubiquity of the player and the power available from its scripting language (ActionScript), developers could build full browser-based applications and get around the limitations of HTML.
By targeting Flash Player, developers could also free themselves from browser and platform incompatibilities. One of the many nice features of Flash Player is that if a browser or platform will run a particular version of Flash Player, then it will run any content and application developed for that Flash Player version. With very few exceptions, it remains true today.
Historically, the biggest drawback of building applications for Flash Player was the authoring environment, which was clearly built as an animation tool for users creating interactive content. Many developers who wanted to build RIAs for Flash Player were thwarted by the unfamiliarity of the tools. This, coupled with the scant materials available in 2002 for learning to use Flash as an application platform, kept many serious developers from successfully building Flash applications.
Although Flash Player remains an excellent platform for RIAs, the introduction of solutions such as Laszlo and Flex have greatly simplified the development process and reduced the number of RIAs developed directly in Flash Studio.