Breaking away from the Page-based Architecture

For experienced web developers, one of the biggest challenges in building RIAs is breaking away from a page-based architecture. Traditional web applications are centered on the concept of a web page. Regardless which server-side technologies (if any) are used, the flow goes something like this:

1.	User opens a browser and requests a page from a web server.
2.	Web server receives request.
3.	(optional) Web server hands request to an application server to dynamically assemble page or
4.	(optional) Web server retrieves static page from file system.
5.	Web server sends page (dynamic or static) back to browser.
6.	Browser draws page in place of whatever was previously displayed.

Even in situations when most of the content of the previous page is identical to the new page, the entire new page needs to be sent to the browser and rendered. This is one of the inefficiencies of traditional web applications: each user interaction requires a new page loading in the browser. One of the key goals of RIAs is to reduce the amount of extra data transmitted with each request. Rather than download an entire page, why not download only the data that changed and update the page the user is viewing? This is the way standard desktop or client/server applications work.

Although this goal seems simple and is readily accepted by developers taking their first plunge into RIA development, often web developers bring a page-based mindset to RIA applications and struggle to understand how to face the challenges from the page-based world, such as, how to "maintain state." For example, after users log in, how do we know who they are and what they are allowed to do as they navigate around the application?

Maintaining state was a challenge introduced by web-based applications. HTTP was designed as a stateless protocol, in which each request to the server was an atomic unit that knew nothing about previous requests. This stateless nature of the web allowed for greater efficiency and redundancy because a connection did not need to be held open between the browser and server. Each new page request lasted only as long as the server spent retrieving and sending the page, allowing a single server to handle far more simultaneous requests.

The stateless nature of the web added challenges for application developers. Usually, applications need to remember information about the user: login permissions, items added to a shopping cart, and so on. Without the capability to remember this data from one request to the next, true application development would not be possible. To help solve this problem, a series of solutions was implemented; revolving around a unique token being sent back to the server with each request (often as cookies, which are small text files containing application specific identifiers for an individual user) and having the server store the user's information.

Unlike traditional web applications, RIAs can bypass many of these problems. Because the application remains in client RAM the entire time it's being used (instead of being loaded and unloaded like a page-based model), variables can be set once and accessed throughout the application's life cycle.

A different approach to handling state is just one of many places in which building applications requires a slightly different mindset than web application development. In reality, web-based RIAs bear more resemblance to client/server applications than they do to web applications.