Digital Earth Weblog

The terms “thin client” and “thick client” are often used to distinguish between any application accessed via a web browser and native desktop applications respectively. This binary classification often results in all web applications being considered as “thin clients”, which is not the case.

This issue came up while trying to describe how different web client technologies can be used for applications deployed inside the corporate firewall — on the intranet. Some arbitrary classifications were needed to help explain that just because an application is accessed via a browser doesn’t make it “thin”. This was the first draft…

The client component of a web application can range from “thin” to “thick”, so there is a continuum of overlapping technology options that provide different levels of capability.

Each class of web application client can provide a simple user interface with basic levels of interactivity. However, the choice of technology used to create the web client application should be driven by the business and technical requirements of the application. The technology set that should be chosen is the one with the lightest footprint, which can meet the application requirements, and which is practical to implement.

Pure Web Client

A pure web client uses only web technologies that are natively understood by common web browsers to provide the user interface (HTML, CSS and simple JavaScript). The web browser is the only runtime used (no plug-ins or applets) so the application is easily deployed to any modern desktop computer.

These applications use a page metaphor. All communication with the server component is via HTTP GET or POST. When the user clicks on a link or a button a request is sent to the server, and a new page being delivered to their browser (“click and wait”). Some Dynamic HTML may be used for simple visual effects like showing and hiding content.

Page-based web applications are also easier to test using tools like HTTPUnit, HTMLUnit, and Canoo Web Test.

AJAX Client

An Asynchronous JavaScript and XML (AJAX) client uses the web browser as the sole runtime environment, but it makes more extensive use of JavaScript. AJAX applications use the XMLHttpRequest object found in most common web browsers to communicate with the server via HTTP using the GET, POST, PUT and DELETE operations.

The key characteristic that separates an AJAX application from a pure web application is that AJAX dynamically update sections of the web page in the background without the user seeing a page refresh. This can provide a more interactive experience without having the reload the entire page. The user perceives a more interactive application, but the page metaphor begins to erode as each page responds to multiple user actions.

Use of the Back or Refresh button can cause the user a lot of rework, or result in loss of data. The more complex AJAX applications like Google Mail and Google Maps are single page applications. Using the Back button will remove the user entirely from the application.

Implementation Notes:

• JavaScript is an interpreted language. Use of lengthy JavaScript execution paths, or execution of JavaScript on a slow desktop computer, can result in the application being perceived as sluggish (which defeats the purpose of AJAX).
• AJAX applications are “chatty”. Network latency can impact on performance. The user should be able to continue their work without waiting for asynchronous requests to complete.

Use of the XMLHttpRequest object for synchronous requests should be carefully considered. Network latency can significantly impact on the user experience.

Rich Internet Application Client

A rich internet application (RIA) relies on a plug-in to extend the runtime capabilities of the web browser. e.g. Java Runtime Environment, Flash, Silverlight, ActiveX controls, etc. Mobile code is embedded in HTML pages. That code is downloaded and executed by the plug-in as a component that is separate from the HTML page itself. The embedded code can usually communicate with the browser using JavaScript.

The reasons for relying on a browser plug-in are to gain additional user interface capabilities and/or improve performance. The embedded component can communicate with a server component via HTTP, SOAP, distributed objects (RMI, DCOM, etc), custom TCP/IP sockets, or any other supported network protocol.

Rich internet applications can be written to fit the page metaphor, but they often don’t. They also usually look somewhat like a web page – links for navigation, button for submitting forms.

Use of the Back or Refresh button can cause the user a lot of rework, or result in loss of data. Many are single page applications. Using the Back button will remove the user entirely from the application.

Note: Unlike a pure web application or AJAX application that relies only on a web browser, some rich client applications can communicate with processes outside the browser. E.g. A Java applet can be given permission to breach the applet security sandbox. By default, ActiveX controls have full access to the local operating system.

Web Delivered Native Client

A web delivered native client is accessed via a browser, but looks and behaves like a native desktop application. It opens new windows to display modal forms, and has almost no HTML content. It has a user interface that follows native operating system look and feel rather than a web browser look and feel.

Note: This class of application does not include the use of Java Web Start technology.

The application can communicate with a server component via HTTP, SOAP, distributed objects technologies (RMI, DCOM, etc), custom TCP/IP sockets, or any other supported network protocol.

Like Rich Internet Applications, these applications rely on browser plug-ins for their runtime environment. The canonical example is a large Java applet containing multiple forms.