Client Programming Tutorial Notes

Frederick J. Hirsch
The Open Group Research Institute
11 Cambridge Center, Cambridge MA 02142, USA

Last modified: Fri Apr 18 11:09:12 EDT

I. Moving Beyond Static HTML

The first thing people do with the web is put up simple HTML web pages which contain text, embedded images, and links to other pages. This is easy, powerful, yet static. This model may be extended by using HTML forms and writing server-side CGI scripts. This allow users to interact with a server application by submitting forms and getting a reply which depends on the form contents.

Before the web, people used desktop applications to perform tasks. If the task involved access and retrieval of information from a remote machine it was called client-server, three-tiered architecture, or something similar. People still want to do that, but now they want to do it using the web; they want it to be easy, and they want it to be cheap. The trend of client-side web programming is to provide services which make a web browser act more like a familiar desktop application, and to provide services which are more like distributed computing.

Desktop applications commonly use a Graphical User Interface (GUI) which handles mouse events. They also use networking and local processing power. Web browsers are beginning to offer these capabilities as their use changes from the display of static pages to more active content. The original paradigm used in the web is that pages are displayed on the browser, but all processing occurs on the server. This does not scale well with a large number of clients, makes pages static and not very much like applications. Moving processing into the client makes it easier to write pages which respond to events, perform local validation, scale well with the number of clients, and reduce network load and round-trip delays. Client programming with the web offers the potential to offer the best of both desktop applications and the web.

There are a number of different approaches to client-side programming offering differing degrees of user interface richness, complexity, security, distributed computing power, and ease of installation and use. They may be grouped into categories based on functionality as follows:

  1. Handle New Types of Information

  2. Provide Local Processing

  3. Integrate with Objects or Applications

II. Techniques For Client-Side Programming

1. Handle New Types of Information

When the user requests a page, either by following a link, or typing a URL, the request is sent to a server which interprets the request and returns content. The server determines the type of the content, and returns this information in the HTTP Content-Type header. Content types are defined using MIME (Multi-purpose Internet Mail Extensions) types, which include a type and a subtype. Types include categories like text or image, subtypes include the format. Thus text types include text/html, and text/plain, and image types include image/gif and image/jpg. Although browsers are designed to interpret and display many types, they cannot process every type which exists or may exist in the future. When a browser receives a type it is not prepared to handle, its behavior will depend on user selected options. If a helper application has been defined for the type, then the content will be saved to a file and the helper application run with that file as input. If a plugin has been installed for the type, it may be called. Otherwise the user may have the option of saving the content to a file, or running an arbitrary application on it.

Helper applications and plugins have many similarities. Both are compiled to run on a specific operating system and hardware platform. Both have full access to files, the network, and other operating system resources. Both must be installed by the user, which requires downloading the correct version from a known site (or installing from a CD-ROM or other media), installing in the correct location, and setting the appropriate browser options so that the helper or plugin is used.

The inherent security in this approach is minimal, and basically is the same as the security of an application. This requires trust of the vendor, which for something loaded over the network may not be that high. Once helper applications and plugins are signed using digital signatures, trust may be increased. Some plugins and helper applications may run hidden, with no visible window to the user, making trust even more important. Writing an application native to a machine is fairly complex, although the complexity depends greatly on the features required by the content type. The ability to write arbitrary code makes for very rich possibilities, using whatever features the machine provides, including the native windowing system. An example of a very useful content type which has both a helper application and plugin is the Adobe PDF format which allows page display.

a. Helper Applications

A helper application is an application which is built to display and process a specific content type. Once the compiled helper application is installed on a machine, a browser on that machine must have its viewer or helper option set so that the helper application is called for content of the correct MIME type. This is done by associating the path of the application with the MIME type.

Navigator Helpers Preference associates Mime
type with applcations

Once registered, when content of the specified type is received, the browser will call the helper application with a file, containing the content which was received from the server.

b. Plugins

A Netscape plugin is a dynamic library which is installed in the browser's Plugins directory, usually located where the browser was installed on the machine. As long as the plugin is installed in the correct directory, and no helper application is configured for the MIME type, then the plugin will be called when that content type is received. If a helper application is configured then it will be called instead.

A plugin is not an independent application, but is written to conform to a specific API. This API allows the browser to call methods in the plugin, and for the plugin to access information in the browser, about the browser and the current page. This is useful because plugins may share the browser display window with other page content when the plugin content.

Plugin content may be placed on an HTML page using the embed tag. This tag causes the browser to download the content, and reserves a portion of the browser window for that content:

<EMBED SRC=data.kind WIDTH=200 HEIGHT=400></EMBED>

The EMBED tag is not part of the HTML 3.2 specification, but is interpreted by Netscape 3.0 and Internet Explorer 3.0. It is similar to the IMG tag for images, but it supports the following additional attributes:

Additional embed Tag Attributes
typespecify mime type, allowing plugin to be used without data from the server
hiddenIf hidden, the plugin will not be visible
unitsspecify units for height and width (default is pixels, ens also possible)
pluginspagespecify url which enables user to download plugin
palettespecify color palette (Windows only)

All attributes of the embed statement are passed to the plugin, so a plugin may also define additional attributes specific to itself for passing additional parameters.

2. Provide Local Processing

a. HTML 3.2 Client-Side Features

HTML 3.2 introduces some new features which move more processing to the client side, reducing round trip delays and improving performance. Client-Side image maps are new to HTML 3.2. An image map is used to associate specific locations on an image ("hot spots") with URLs. When the user clicks on a hot spot in the image, the corresponding page is loaded. This is done by sending the coordinates to the server when a server-side image map is used. The server must then map the coordinates to the URL. Client-Side image maps are more efficient, since the mapping from coordinates to URL is done on the client, and the server simply receives a request for a URL. Client side image maps also make it possible for the browser to display feedback to the user as the mouse moves over the image map, such as displaying URL information in the status line when the mouse is over a hot spot. Client-Side image maps are also simpler to create and easier to maintain, since both the image and the mapping information are located on the client and do not require writing a CGI script to process the image location.

Cascading Style Sheets (CSS) are a proposed W3C standard which allow customizations of the presentation of HTML to be stored in a definition file, and used by documents which specify the style. Apart from the advantages of allowing control over presentation, and the ability to share style sheets, they permit style information to be loaded from the server once and then cached, improving performance if multiple documents share the same style.

b. Browser Scripts (e.g. JavaScript, VisualBasic)

Browsers which support client-side scripting allow a script to be embedded in an HTML page. The most common scripting languages are JavaScript and Visual Basic, and PerlScript. Not all scripting languages work on all platforms or browsers, so choice also leads to a lack of portability.

Scripting is powerful because it can associate event handlers with Graphic User Interface elements created using HTML forms. Without event processing a form may either be submitted in its entirety to the server, or reset to the default state. With JavaScript, clicking on an element such as a button, or focusing on an element can cause a script to execute. This allows the page to be more interactive, and also provides a faster response time since the page is not submitted to the server when local processing is performed.

This also greatly reduces the complexity of processing a form, because the a server CGI script need not validate every field element if each field is validated locally. Simplifying server-side CGI processing is valuable, even if the page itself becomes more complicated. An advantage is that the script is located with the page, rather than CGI where it is in a different file which must be maintained consistently with the page.

The use of client-side scripting makes a page less portable, since the browser must support the language and the user must have it enabled in the browser to use it. One reason a user may have it disabled is because of possible security risks, both due to bugs in the browser scripting implementation, and because use of a script may cause security problems. JavaScript has had a history of security holes, which have been fixed as they are found. It is still possible to create simple denial of service attacks, such as disabling the user's back button.

Scripts are embedded in HTML with the script tag:

<SCRIPT LANGUAGE="JavaScript"> scripting language elements </SCRIPT>

HTML tags may have script elements associated with them. Using JavaScript, HTML form buttons may have an onClick method associated with them, which causes the method to be called when the button is pressed:

onclick="getValue(form.x.value, form.y.value, form.result)">

The onclick attribute specifies the function to be called when the mouse button is pressed. Named elements of the HTML form (e.g. x, and y) may be accessed as shown.

JavaScript Example
This tutorial will use JavaScript as an example. JavaScript is unrelated to Java, apart from the name. A good example of the use of scripting is for form field validation. This example is presented in JavaScript which is supported by both Netscape and Internet Explorer (VisualBasic is not portable, since it is not supported by Netscape). Validation may occur as each field is entered. A check may also be performed when the form is submitted. If the form is not valid then nothing is sent to the server.

Form with validation JavaScript alert

For this example we define a form field which should contain a part number between 1 and 10, a function which checks the value, and a method which is called when the field is changed. The method definition follows:

<title>JavaScript Validation Example</TITLE>

<SCRIPT LANGUAGE="JavaScript1.1">

function part_fail(msg, myform)
     myform.part.value = "";
     return false;

function validate_part()
   // access the form named "entryform" in this page
   var myform = document.entryform;

   // access the value of the "part" field in the "entry" form
   var number  = myform.part.value;

   // try to convert it to a number. 
   var value = parseInt(number, 10);

   // NaN: Not a number, always returns false on IE 3.0!
   if( isNaN(value) ) 
	  return part_fail("Please enter a number 1 - 10.", myform);

   // make sure there was no trailing text or other conversion failure
   // (numeric value should be same as what was entered.

   var str = value.toString(10);
   if(str != number) {
	return part_fail("Please enter a number 1 - 10.", myform);
   if((value < 1) || (value > 10)) 
	return part_fail("Part numbers must be in range 1 - 10.", myform);

   alert(value + " is ok.");
   return true;

function checkForm()
   alert("Submit is disabled.");
   return false;


<H1>JavaScript Validation Example</H1>

<FORM ACTION="" NAME="entryform"
onSubmit="return checkForm()">
<TR><TD>Part Number:</font></TD>
<TD> <INPUT TYPE=text NAME="part" SIZE=2 onChange="validate_part()"></TD></TR>
<TD><INPUT TYPE=text NAME="reason" SIZE=20></TD></TR>
<INPUT TYPE=submit>
This JavaScript only works with Netscape 3.0 and does not work with 
Internet Explorer 3.0 due to differences in JavaScript implementations.
This demo shows validation of the part field upon entry
(must be number 1-10).
<HR COLOR=purple>

c. Java Applets

Java is an interpreted, object-oriented programming language which includes the ability to run on all platforms which have a Java virtual machine. It supports multi-threading, easier networking, and graphics support through the Abstract Windowing Toolkit (AWT). The Java language is safer than other languages such as C because the language does not support pointers, explicit memory allocation, and enforces bounds checking on arrays.

Java Applets are instances of a Java class derived from the Applet class, which run in browsers, and are constrained to reduce security concerns. Java Applets are unable to use the native operating system calls directly, may not use native (e.g. C) methods, may not access the file system, and may only open network connections to the machine from which they came. Applets offer much of the power of application programs, without any need for installation on the users part, and without any of the security risks. Although Applets on a page may interact with each other, it is not possible to have them interact directly with other programs on the local machine.

Like images or embedded plugins, applets are allowed to use a portion of the browser window:

<APPLET CODE="MyApplet.class" WIDTH=200 HEIGHT=100>
<PARAM NAME=reason VALUE="because">
This text only appears for a browser which is not Java capable (or has Java turned off).

The applet tag is part of the HTML 3.2 specification. Applets are allowed to call the public methods of other applets on the same page, if they know their name.

An example of two applets communicating on a single web page demonstrates a few features of applets:

Two applets on same page may communicate

This may be extended with applets which communicate back to a server, allowing a "chat" room to be created.

d. LiveConnect

Netscape's LiveConnect allows programmers to integrate JavaScript, Java Applets, and Java-enabled plugins to create client-programs which are more powerful than programs which could be created with any one of these techniques alone. JavaScript scripts may access the standard Java classes built into the browser, read and write public fields of Java Applets, and invoke applet public methods. Java applets may also read and write the JavaScript object properties, and invoke JavaScript functions.

A simple example is that of an HTML form which is used to control a Java Applet on the page, and which also contains a field which is updated by the applet. This approach allows the creation of a simple HTML interface for control of an applet which provides graphics unavailable in HTML.

HTML Form with JavaScript and Applet

The HTML page which displays the applet is:

<TITLE>Form, JavaScript, Java Example</TITLE>

	 function set_level()
	     var value = document.levelForm.Level.value;
 	     var i = parseInt(value, 10);

	     if( isNaN(i) || i < 0 || i > 100) {
	         alert("Level must be between 0 and 100 (these are interpreted as percent)");
	         document.levelForm.Level.value = document.LevelApplet.getlevel();
	     } else {
	     return false;

<FORM ACTION="http://www.nowhere.bad/" NAME="levelForm">
<INPUT TYPE=button VALUE="Set Level"  onClick="set_level()">

<APPLET NAME="LevelApplet" CODE="LevelApplet.class"a width=50 height=100>
<PARAM NAME=color VALUE=blue>
This example demonstrates JavaScript being used to send form contents to
an Java applet, and a Java applet using JavaScript to send values to a form.

The applet source itself is:

import java.util.*;
import java.applet.*;
import java.awt.*;

public class LevelApplet extends Applet {
  public void init() {
    String w = getParameter("width");

    if(w != null) {
      width = Integer.parseInt(w);

    String h = getParameter("height");

    if(h != null) {
      height = Integer.parseInt(h);

    _color_map = new ColorMap();
    String color = getParameter("color");    
    _the_color = _color_map.getColorParameter(color,;	    

    String level_str = getParameter("level");    
    if(level_str != null) {
      _level = Integer.parseInt(level_str);


  public void paint(Graphics g) {

    g.drawRect(0, 0, width - 1 , height - 1);

    float _factor = (100 - _level)/100;

    int yval = (int) (_factor * height);
    int ywidth = (int) (_level * height/100);

    g.fillRect(0 , yval, width, ywidth);

  public void setlevel(int level) {
      _level = level;
      repaint(0, 0, width, height);

  public int getlevel() {
   return (int) _level;

  int width = 200;
  int height= 300;
  ColorMap _color_map;
  Color _the_color;

  float _level = 100;

e. Dynamic HTML

Dynamic HTML is the name given to new HTML extensions announced by both Netscape and Microsoft, although these extensions may be different and are not yet standardized. In either case, the key is to use Cascading Style Sheets (CSS1) to identify HTML elements in a document, (e.g. headings, elements of a class or with an id) and extend the scripting object model to allow properties of these elements to be read and modified dynamically. This is an extension of the object model provided by JavaScript in Netscape Navigator 3.0.

Dynamic HTML allows greater dynamic interaction, including the ability to change the size or font properties of text dynamically, the ability to show or hide elements, and the ability to position elements on the page (using a proposed extension of CSS). The ability to position elements allows precise control over presentation, at the cost of portability issues:

Example of controlled text presentation

In addition to positioning, dynamic html allows elements to be layered in front or in back of each other. Combined with JavaScript, this provides for opportunities in animation, such as having fish move in front and behind of pillars.

Fish swimming in front and behind of HTML

There is also a new Netscape plugin API (4.0) which allows plugins to be transparent and integrated with HTML rendering.

3. Integrate with Objects or Applications

The ability to provide local processing in the context of a browser by extending HTML with scripting and applets is powerful, but the ability to integrate a web client with existing applications on the native machine and elsewhere is still valuable and important. One way is to define a browser API which allows applications to communicate with it. Another is to extend the browser to participate in an object model and component architecture. The following section discusses these approaches.

a. Peer-to-Peer Client APIs

One of the earlier approaches to extending browser functionality was to write an application native to the machine running the browser, and use interprocess communication (IPC) techniques to control and receive information from the browser. A major difficulty with this approach is that the implementations were different for browsers as well as for platforms, and in some cases functionality was not available at all.

The Spyglass Software Development Interface (SDI) is a specification which defines how an application may register with a browser to receive event notifications, as well as to send events to the browser to request that it perform actions. On Windows NT, DDE and OLE are used to to provide this interface to the Netscape browser. On Unix, Mosaic supports CCI, but Netscape does not (it does not support sending events to the application). On the Mac, AppleEvents may be used with Netscape.

A useful example of this interface is when an application registers with the browser to receive notification of each URL requested by the browser, as well as a copy of each page received by the browser. This allows the application to observe browsing activity and act upon it. The ability to request the browser to load pages allows an application to control the browser.

This approach shares the disadvantages of helper applications, in that it requires a user to trust and install a machine-dependent application on their machine. It also only works with specific browsers, and the protocol robustness is dependent on the browser implementation. The primary advantage is that it provides more integration than a helper application, and was available in early browsers.

b. ActiveX

ActiveX is the name of a set of technologies from Microsoft, including an compound document model, component, and object model. Components may send messages to each other and perform remote method invocations. At present, only Internet Explorer supports this model. The next section of this tutorial discusses ActiveX in detail.

III. Selected References

Helper Applications and Plugins
[Mime] MIME Overview, Mark Grand, 1993.
RFC 1521: MIME (Mulipurpose Internet Mail Extensions 1993
comp.mail.mime FAQ (Frequently Asked Questions)
[Plugins] The LiveConnect/Plug-in Developer's Guide
Browser Scripting
[Flanagan97] David Flanagan
JavaScript, The Definitive Guide, 2nd Edition.
O'Reilly, 1997.
[JavaScript] Netscape JavaScript Guide
Java Applets
[Cornell97] Gary Cornell, Cay S. Horstmann
Core Java, 2nd Edition.
SunSoft Press: Prentice Hall, 1997.
[JavaTutorial] Mary Campione, Kathy Walrath
The Java Tutorial.
Addison Wesley
Dynamic HTML
[Dynamic] Dynamic HTML
[Netscape Communicator] Netscape Communicator
Peer to Peer Client APIs
[SpyglassSDI] Software Development Interface, Version 1.0, Spyglass, Inc. , 1995