Exploring the Deadly Sins of Rich Internet Applications

Let me begin with a story about my friend, a tech lead at a small business company. He was assigned the task of enriching his company's "Expense Claim" application with Ajax technologies. At first, he planned to deliver the application in 3 months, but it wound up taking him 6 months. Here are some "Ajax deadly sins" that delayed his project:

• Browser Incompatibility
  Firstly, he decided to develop in-house JavaScript code for the UI, the 1^st draft of which took his team 2 months to finish. Then he discovered that the layout was a mess on different browsers. Due to a lack of JavaScript knowledge, he then decided to adopt an off-the-shelf Ajax widgets framework along with a Java-to-JavaScriptframework in order to overcome this browser incompatibility issue; that, of course, meant re-building the UI from scratch.


• Tedious Client-Server Communication Coding
  Just when it appeared that his team had escaped from the nightmare of JavaScript, there came an even bigger challenge related to integration between the UI and the backend: the Java-to-JavaScript framework required RPC calls to get data from the server and handle the returned data manually. It produced numerous files to communicate between the client and the server. Though developing in pure Java, his team spent a few more months finishing the integration.


• Slow Performance
  During testing by their users, it was discovered that the performance was unacceptable; users had to wait for more than 10 seconds for 10 thousand records to be loaded. Even worse, some old computers actually stalled. Unfortunately they had to implement load-on-demand to improve the performance issue. But, load-on-demand was never an easy job. It required determining the visible area at the client side, prompting required data from the server side, and the rendering of the data on the browsers. To fulfill this requirement, his team had to delay the project a few additional months.


• Maintenance Headache
  Later in the project cycle, he was informed that extra fields would be added to the data model. This was really a nightmare for his team, since they not only had to modify the backend code, but also the associated client code. They spent another month maintaining the consistency of business logic between client and server code. In the end, his team spent 6 months to deliver the "Expense Claim"application.

 

Trouble Maker: Primitive Programming Model

From my point of view, most of these problems are caused by a primitive programming model which separates the UI and the backend of the applicatio into 2 sides as follows:
A two-sided programming model brings a lot of trouble fordevelopers, since they have to take care of the following process-unrelated issues by themselves:

• Browser incompatibility
  No longer an issue, solved by any modern Ajax frameworks


• Client-server communication
  Displaying data on the client by retrieving data from server


• Slow performance
  Developers tend to put too much data on the client


• Business logic inconsistency between clientand server
  Replication of business logic on the client

The ideal programming model should save developers from these cumbersome tasks. To resolve all of the above issues at once, the UI and the back-end of an application should never be separated. Instead, they should run on the same side, either the server-side or the client-side.

To improve developer productivity, and provide easier access to server resources, the application should run on the server only. The ideal programming model should look as follows:

Developers should simply focus on the business logic of their application, and the rest of the job should be handled by the adopted framework, automatically. As far asI am concerned, the best way to use Ajax is to not even know it exists!

I will refer to this framework as Direct Ajax because the application can access user interfaces, database, and all kinds of resources directly. Direct Ajax provides developers an easier way to create rich internet applications without being bothered by process-unrelated jobs.

Direct Ajax

The architecture of Direct Ajax looks as follows:

The UI and the backend of an application are integrated seamlessly, and Direct Ajax is responsible for rendering the content to the client, and automatically synchronizingthe state between client and server.

Direct Programming

Direct programming should fulfil the following three criteria:

• Direct UI Access
  The application can get and set valuesfrom UI directly. Here is the pseudo code,

   <zscript>
   void draw(int x1, int y1, int x2, int y2) {
    LiveImage li = new LiveImage(400, 300, LiveImage.TYPE_INT_RGB);
    Graphics2D g2d = li.createGraphics();
    Line2D line = new Line2D.Double(x1, y1, x2, y2);  
    g2d.draw(line);
    image.setContent(Images.encode("test.png", li));
   }
   </zscript>
  <image id="image">
  <button onClick='draw(10,10,10,10)'/>

  
  Once the user clicks the button, there appears an image on the browser. It's straightforward. No more XMLHttpRequest, and RPC call. No more pitcher-and-catcher game between client and server.


• Direct Database Access
  Secondly, the application can access the database directly. The following example illustrates a simple scenario to get data from a database.

  Hi. <label id="name"/>
  <button>
    <attribute name="onClick">
    User usr = Database.getUserById(1);
   	  name.setValue(usr.getName());
    </attribute>
  </button>

  Once the user clicks the button, there appears a welcome message. The UI and backend are integrated seamlessly.

• Direct Live Data

  With live data, developers can separa the data from the view. Developers only provide the data by implementing the ListModel interface rather than manipulating the grid directly.

  	
  <zscript>    
      String[] data = new String[1000];            
      for(int j=0; j < data.length; ++j) {            
          data[j] = "option "+j;                    
      }            
      ListModel strset = new SimpleListModel(data);            
  </zscript>    
  <grid width="100px" height="100px" model="${strset}">    
      <columns>            
          <column label="options"/>                    
      </columns>            
  </grid>    

The grid sends the data to the client only if it is visible. It saves a lot of network traffic if the amount of data is huge.

With direct access with UI, database, and live-data, Direct Ajax helps you avoid the following nightmares:

• Slow Performance
• Tedious Client Server Communication Code
• Maintenance Headache

 

Which Framework to Use (How to do Direct Ajax)

After introducing the benefits of Direct Ajax, I would like to examine currently available Ajax frameworks to determine how many of them satisfy the requirements of Direct Ajax.

A Comparison Matrix

In the above matrix, there are four frameworks that support server-side programming, namely: ZK, Backbase, Echo2, and Icefaces. ZK, however, surpasses the others with its full support of other features, markup language, scripting language, load-on-demand, and mobile support.

 

5 Reasons you should use Direct Ajax

Building an enterprise application is never an easy task, not to mention enriching its user experience at the same time. Direct Ajax is designed to help developers deliver the project on time without working over-time. Here are the five reasons you should use Direct Ajax.

• Boost Productivity of Developers. Developers Focus on application itself instead of Ajax stuff.
• Fast Prototyping. The UI, and the backend of an application are no longerseparated.
• Quick and Easy Learning. No more JavaScript, XMLHttpRequest.
• Secure Communication. No danger of exposure of business logic to theclient, and data over the Internet.
• Easy Maintenance. No more client code.

 

Beyond Direct Ajax (Ubiquitous - mobile)

In addition to the above benefits of Direct Ajax, the extensibility of the application is also quite important. ZK demonstrates its extensibility by extending the Web application to Java Phones and to the Android platform with ease. With ZK, you can run your Web applications almost anywhere.

About Author

Robbie Cheng is a senior engineer at the ZK Team. He develops ZK forum, and ZK extension for Google Android. He is experienced in developing Ajax application. He is also the author of, ZK: Ajax without the Javascript Framework.