Web Application Strategy

August 2006

• Informational and Operational Web Applications
• Traditional Web Application Technologies
• New Web Applications and Their Technologies
• GUI Paradigm Comparison
• The Web Application Development Strategy
• Move Now!

Abstract  Web applications can be categorized as informational and operational. The traditional, server page technologies have been used to build both kinds of web applications. With the advent of DHTML and new technologies such as Adobe® Flex™, the era of Rich Internet Applications (RIAs) has come. For informational web applications, traditional server page technologies should suffice. For new operational web applications, the counter-intuitive server page technique should be tossed out as soon as possible and move on to RIA technologies.

Among new RIA technologies, what to choose? There are many factors in a decison. Technolgy-wise, currently there are two major technologies: (1) DHTML, exemplified by the Dojo Toolkit, and (2) Adobe® Flex™. Dojo is an incredible effort to achieve many desktop GUI features in browsers. There are two major concerns: (a) the difficulty of working with DHTML, and (b) Dojo's choice of JavaScript (what else?) for large-scale development. Dojo can be used in limited scope or isolated situations as an advanced AJAX technology. For full-blown application development, it will likely entail high stress level for developers and projects, quality issues, and higher development and maintenance costs. In contrast, Flex™ is free from these issues.

---

 

Today, we are at the crossroad for web application development, between the traditional page-based, thin-client web applications and Rich-client Internet Applications (RIAs). For your new web applications, which approach to adopt? For RIAs, what technology to use? We need some sure answers to make a decision that is not only right for the near term but also for the foreseeable future.

Informational and Operational Web Applications

Based on usage, web applications can be partitioned into two categories: informational and operational.

Informational web sites are the very reason why web came into being and why HTML and HTTP were invented. In addition to just hosting static articles (e.g. www.irs.gov and cnn.com), informational web applications can serve dynamic, read-only content based on user inqueries; they include search engines (e.g. google.com and hotjobs.com), portal sites (e.g. groups.yaoo.com and wikipedia.com) and various weblog sites.

Operational web applications are applications in the traditional sense, that is, they provide services and process user information. Sites like etrade.com and web mails are classic examples. Many software products employ web-based user interfaces (e.g. Interwoven's TeamSite); they are usually pure operational web applications.

Most general public web sites are a hybrid of both informational content and operational web applications, such as e-commerce sites and portal sites (e.g., eBay, amazon.com, Yahoo!, etc.)

Traditional Web Application Technologies

The traditional server page technologies such as JSP, ASH, PHP, ColdFusion, ..., are perfect for building informational web applications.

For operational web applications, however, the server-page-based web application architecture is a hack and a huge anti-pattern. In this paradigm, the server mistakenly assumes the roles of rendering views and handling user interactions. In the Model-View-Control (MVC) paradigm of client-server applications, the server provides the model, while the view and control reside within the UI itself. In the traditional web applications, however, all three roles are handled by the server. The user experience is interruptive, and the development experience is grinding because it is counter-intuitive and inflexible. (Frameworks such as Struts try to partition the server-side code as MVC; this is different from the architectural MVC of client-server applications.)

For hybrid web sites with both informational web content and limited operations, a server page technology can be a preferred choice because user experience is consistent. For pure operational web applications, server page technologies result in poor user experience and stressful development process.

New Web Applications and Their Technologies

AJAX

In 1997, Microsoft Internet Explorer (IE) 4.0 introduced DOM and Dynamic HTML (DHTML). In 1998, IE 5.0 was released with enhanced DHTML and an XMLHTTP ActiveX control that allows JavaScript code to initiate HTTP requests on its own.

In June, 2002, Mozilla 1.0, the first open sourced version of the Netscape browser, came out. It introduced a native JavaScript object, XMLHttpRequest, that is the counterpart to IE's XMLHTTP. In November, 2004, Mozilla Firefox 1.0 browser was released. Finally we have two mainstream browsers that share a largely consistent visual rendition of HTML and DHTML.

In 2005, the term AJAX, which stands for Asynchronous JavaScript And XML, was coined. It has been the hottest buzz up until now. AJAX is a technique, not a technology. The AJAX technique is: in response to user actions and other events, JavaScript code uses XMLHttpRequest to initiate a HTTP request to the server, downloads some data (which are typically XML or plain text) and uses DHTML to update portions of the page without refreshing the whole page like traditional web applications normally do. Such behavior was popularized by Google's Gmail and Google Map. The fundamental technologies for AJAX has been in IE since 1998 and in Mozilla since 2002; this technique was hampered only by the inconsistent browser renditions, which greatly limited DHTML's usefulness. After Firefox 1.0 made its DHTML rendition consistent with IE, the AJAX technique became practical for wide-spread uses.

In Adopting AJAX Means Choosing From Four Levels of AJAX Technology, Ray Valdes listed four levels of using AJAX:

Level 1	SNIPPET	Code fragments folded into HTML to add data access
Level 2	WIDGET	Self-contained user intrface components that can be bolted on to existing HTML applications.
Level 3	FRAMEWORK, OPEN SOURCE	Comprehensive Framework that is free from open source project.
Level 4	FRAMEWORK, COMMERCIAL	Comprehensive Framework backed by a vendor.

First off, AJAX is not a "technoloy" but a methodology. Yet Mr. Valdes did correctly point out the styles and trend of using AJAX, especially at Levels 1 and 2. Levels 3 and 4 refer to the same thing, framework.

The funny thing is that, when "AJAX frameworks" are materialized, AJAX would not be an interesting concept any more. Instead, those frameworks foster a whole new breed of web application technologies, and web applications reach a new era – the Rich Internet Applications (RIAs). This is evidenced by the Dojo Toolkit and Flex™, where RPC mechanism is an important but small portion of the overall frameworks. AJAX is a technique fated to create embelishments for the traditional web applications built with server page techologies.

Rich Internet Applications and Technologies

RIAs are rich-client programs. Their architecture is radically different from that of traditional web applications but similar to that of desktop applications. The RIA architecture partitions the application logic according to the architectural MVC model; the server provides services and data, that is, the model; the client contains logic for both view rendition and user action handling.

RIAs are not necessarily limited to running in web browsers. The very basic requirement of RIAs is cross-platform. Amongst different cross-platform technologies available, DHTML and Flash player stand out. To date, there are three major contending technologies for RIA development: Dojo Toolkit, Adobe® Flex™ and OpenLaszlo.

Dojo Toolkit

The Dojo Toolkit is one of the few DHTML technologies that qualify for building full-fledged RIAs. See Dojo Explained for more detailed explanation and discussion.

Aside from all the good ideas that it implements, there are two major concerns regarding developing with Dojo:

1. Dojo is written in JavaScript 1.x, which is a highly dynamic language with little declarative assistance for programmers. It is a very weak language for large-scale software development. This inevitably leads to hightened stress level and development and maintenance costs.
2. Dojo relies on the disparate DOM implementations (IE, Mozilla and others) to implement UIs. DOM lacks capabilities; a simple resize handling may involve a lot of energy, for instance. Frameworks would never provide all of what is needed; it is clear that developers will have to deal with browser DOMs coupled with Dojo Markups. This won't be easy, even with the availability of superb documentation. Stress level is high not only for Dojo Toolkit developers themselves but also application developers.

Despite these concerns, the Dojo Toolkit has packed and continues to pack more and more desktop-like GUI features. Dojo can be used in limited scopes or isolated situations as an advanced AJAX technology.

OpenLaszlo

Laszlo Systems, Inc. is the company that pioneered the idea to formally use Macromedia's Flash player to create business applications, in addition to Flash's original purpose of delivering rich content. Prototyping began in 2000; in 2003, the Laszlo Presentation Server (LPS) 1.0 was released. LPS 2.0 was released and open sourced in 2004. In 2005, version 3.0 was released and its name was changed to OpenLaszlo.

Laszlo defines its LZX language in XML format for building RIAs atop the Flash player, which is used to declare UI elements, data binding and event handling. It uses JavaScript to define event handlers.

Aside from all the good ideas that it implements, there are two major concerns regarding developing with OpenLaszlo:

1. OpenLaszlo uses JavaScript 1.x as its fundamental programming language. This presents the same concerns as Dojo.
2. The OpenLaszlo development suite produces Flash executables, swf files; but the Flash player is controlled by Macromedia®, now a part of Adobe®. When Adobe® decides to provide a similar mechanism, it is very difficult for Laszlo to compete. For instance, Adobe® is able to enhance the Flash player for its development tools can take advantage of; Adobe® did just that for Flex™. Also, Adobe® is a much bigger company.

Facing the pressure from Adobe® Flex™, OpenLaszlo is now under way to generate applications in DHTML as well. That is why Laszlo now endorses Dojo for its widget collection, because vanilla DHTML simply does not have useful GUI facilities. At this writing, Dojo is at early stages of development, thus OpenLaszlo/DHTML has a long way to go, too.

Adobe® Flex™ and Flex Builder™

Macromedia is the maker of Flash player. In March 2004, it released Flex™ 1.0, a development suite similar in concept to Laszlo. It used JavaScript as its programming language. Flex™ 1.5 was released in October 2004. In December 2005, Adobe completed its acquisition of Macromedia. The Flex™ 2.0 project started in October 2005, and released Flex™ 2 on June 28, 2006. With its stablized features and quality and rationalized price model, Flex™ has become a viable and attractive solution for the industry and development community.

Flex™ defines MXML language in XML format, which is used to declare UI elements, data binding and event handling. It uses ActionScript 3 language (AS3) for the logic. AS3 is a successor of JavaScript 1.x; it is an implementation of the JavaScript 2.0 Draft Specification. AS3 supports static typing, declarative OOP and package and namespace mechanisms. It is similar to Java but is backward compatible with JavaScript; therefore AS3 also enjoys JavaScript's dynamic features. AS3 is a potent language for large-scale software development. In fact, the UI elements specified in MXML are all compiled into AS3 objects.

An important part of the Flex™ development experience is its IDE, Eclipse-based Flex Builder™. It includes a WYSIWYG (What You See Is What You Get) round-trip designer, a code editor that can point out basic syntactic and semantic errors and a reliable debugger. The debugger, working hand-in-hand with the AVM3 (ActionScript Virtual Machine 3) embedded in the required Flash 9 player, offers a development experience just like Java. See Adobe® Flex™, the Right Way for RIAs for more details.

Unlike Flex™ 1, Flex™ 2 SDK is free and Flex™ Build 2 is only US$500/seat. Adobe® is hoping to sell some server solutions along with Flex™, which are highly priced; but they are not required.

GUI Paradigm Comparison

Now that we are talking about building real Graphical User Interfaces (GUI), it would be beneficial to compare various GUI paradigms, and see where each stands in the following table. (Move mouse over italic values to see annotations.)

From this table, it is clear that HTML-based paradigms are poor for both user experience and development experience. This is no accident; the fundamental reason is that, HTML was invented as a text format for sharing static information, not for application development. It is no match for mechanisms like C++, Java and Flex™ that are designed for building applications.

The Web Application Development Strategy

Web Technologies of Yesterday and Tomorrow

The web application development strategy can be clearly delineated by this table:

The Requirements for Good RIAs 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 improvments never end.

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

1. A capable, cross-platform 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.

The Choice Between Dojo and Flex™ 2 for RIAs

It helps to understand RIAs better by looking at the history of network computing.

The RIA technologies for operational web applications include Dojo, OpenLaszlo and Adobe Flex™. All three have demonstrated desktop-like GUI features, with Flex™ and OpenLaszlo having an edge because of the capabilities of Flash player.

But the development experiences among these three are quite different. One huge factor is the programming language. The weaknesses of the JavaScript language present serious concerns over software quality and development cost management; it is all too often to see the ominous "broken code" icon in the bottom-left corner of the browser, indicating JavaScript failures. JavaScript's dynamic nature makes its code very difficult to organize and read. The same feature also hampers tools to function effectively. In contrast, code in languages like Java and ActionScript 3 is well organized and highly modular both logically and visually. Sophisticated tools are available to detect a lot of problems before runtime.

All three technologies are young. Flex™ was just released. Dojo is not even in its infancy yet, but has managed to attract a lot of attention. Flex™ is an attractive technology that seems to do everything right, and is clearly taking over the leadership role from Laszlo for building Flash-based RIAs, even though Laszlo pioneered this idea.

For large-scale RIA development, Adobe® Flex™, the Right Way for RIAs while DHTML develoment naturally presents serious concerns (see Dojo Explained.)

Move Now!

If you are to upgrade an existing operational web application or design a new one, you are at a crossroad. Shall you fall back to the old, familiar server page technologies with improvements of AJAXing up? Or should you take a bolder move and develop the application as a RIA? In six to 12 months's time, your decision will show the effect. The clock has already started ticking with the advent of Adobe® Flex™ and Dojo.

Having experienced desktop applications, using HTML pages to conduct business operations is truly a setback to user experience. The "Web 2.0" wave shows that people are eager to abandon that odd phenomenon; the question for developers is, how?

Over the short calendar years of World-Wide Web, huge amount of resources have been established on the internet. This creates enormous burden to maintain backward compatibility, and project managers like to adopt evolutionary approaches for safety to the running businesses. This leaves developers in the dilemma of whether to keep hacking and improvising on the current web technologies, i.e., HTML, CSS and Javascript, or to embrace a brand new paradigm that is good for users and right for developers? It has taken the smartest collection of people 10 long years to reach the concept of "Web 2.0", the right client-server architecture; it remains to be seen how many more years to get its implementation right.

---

Related Articles:

• Adobe® Flex™, the Right Way for RIAs
• Dojo Explained