Direct from Web 2.0

Grade "C" for web applications (In other words, the web sucks!)

May 2, 2006 – 7:26 pm by coachwei | Category Main Page | 1 Comment »

(This was written in early 2004 and published here the first time).

 

For a long time, I couldn’t stop thinking how my professor would grade these web-based applications deployed by many companies today. My guess is an “C” for almost every one of them.

 

A few years ago when I was a graduate student, I got a “C” for a software architecture class. My stupidity and laziness at the time led me to use a knowingly flawed architecture for my class programming project. Mathematically, the approach works most of the time but it does fail once in a while. Despite my tireless coding, my professor gave me a “C” because I failed the basic responsibility as a software architect, “choosing a solid and scalable architecture”.

 

Unfortunately, the Web is actually just as flawed: It works most of the time but it does fail once in a while. In the context of enterprise computing where reliability, transaction integrity, scalability and performance are of paramount importance, it is an absolutely flawed architecture that I can only imagine my professor would laugh at the slightest idea of using it for anything that is business critical.

 

First of all, the Web is inherently flawed on reliability and transaction integrity, which is the No.1 requirement for business critical applications. Its communications model does not guarantee message delivery, time of delivery or order of delivery.  For example, the user submits a form and then clicks “logout”. There is nothing wrong with the user’s operations. But there is no guarantee whether any of these two messages will be delivered. Even if they are both delivered, it is likely that the server program may receive the “logout” message before it receives the “submit” message, which would cause the failure of the “submit” transaction. Problems like this do occur and there is no easy way for web developers to write code to handle them.

Secondly, the Web browser can not scale to large data sets and large transaction volumes. Enterprise applications need to deal with large data sets. Fairly commonly, users want to see as much data as possible in a single table, for various reasons such as comparison, searching, printing and so on. When it comes to large data sets, the current Web breaks down. Its limited client functionality requires doing most of the data processing on the server and thus constantly reloading the data set over the network, consuming excessive bandwidth and making the application performance too painful to use.

 

Thirdly, the Web browser does not scale to non-linear work flow. The fundamental web usage model is via hyperlinks navigation: click a hyperlink->load a new page->click a new hyper link->load a new page. This is a linear workflow. Unfortunately (or fortunately), enterprise applications typically involved non-linear workflow. Excel and typical integrated development tools like Microsoft Visual Studio are two examples that require non-linear workflow. For example, when a user is looking at an Excel spreadsheet, he may want to format it (there are hundreds of formatting options), perform a certain calculation, enter new data, edit data, perform charting, etc. Each option can lead to many other options but also quickly go back to the original state. Supporting such complex workflow using hyperlinks is difficult and expensive.

 

Fourthly, the Web does not support time criticality. A lot of enterprise applications are time-sensitive that need to present real-time information to the user. However, the web’s communication model, “request/response”, prevents user from getting new information unless the user refreshes the screen. Such behavior is unacceptable for some applications.

Lastly, the user interface problem. The page-oriented user interface works fine for documents, but does not work well for applications. Retrofitting rich user interface into pages lowers user productivity and increases development costs.

 

In summary, the Web itself would probably receive an “A” for world wide browsing. Using the Web for computing would probably receive a “C”. Using the web for enterprise computing, given its tremendous architectural flaws, should certainly receive an “F”.