As we said earlier, the GUI Layer (sometimes called the "frontend") balances upon the tenuous border between the world of computers and the world of people. As such, it must perform the often-complex task of translating between human and computer languages.

In its role as translator, the GUI is responsible for two things.

First, the GUI must translate the desires, intentions, needs, and wants of people into executable, logical machine instructions. At the same time, the GUI must also translate computer-generated data into meaningful human-readable information.

This translation, as you might imagine, is no mean feat. In fact, in creating web applications, web developers will spend just as much time building a solid frontend as they will spend developing a dependable backend.

As a web application developer, when concerning yourself with the GUI Layer, you will most likely be concerned primarily with the use and manipulation of "UI Widgets" or "controls". Widgets are interface tools that clients can use to make their intentions, desires, and wants known to the program. Widgets could include buttons, scroll bars, grids, or even clickable images. Widgets should be almost intuitive to you as this is the bit of software we humans most often work with.

Because the communication between the browser and server is better discussed as a function of the communication layer, we'll discuss it in the next section. For now, we concern ourselves mainly with the document display that is more classically a GUI Layer issue.

Typically, the document that is returned from the web server is formatted (according to some formatting instructions) by the browser so that when it is displayed, the document will look pretty (rather than just being displayed as plain text) or have some special functionality. All readers will certainly be familiar with HTML, the most ubiquitous web-formatting languages around today.

Most web browsers know how to take HTML-encoded text and display it according to the HTML formatting instructions. Thus, a web browser will take <CENTER><B>Hello Cyberspace</B></CENTER> and turn it into

LYNX is a simple text-based web browser primarily accessed via UNIX shell accounts that displays formatted HTML text (but not images). A sample of what you might see in a LYNX browser is seen below:

Though revolutionary when it was released, LYNX does not brag about its user-friendly design. As you can see, though LYNX is perhaps the fastest browser on the market because it does not need to worry about graphical display, it is also the ugliest for the exact same reason. LYNX's text-based interface is actually quite clumsy (unless you are a blind user in which case LYNX rocks for its speed and text-based simplicity where other browsers tend to be useless).

In fact, soon after the development of LYNX, as the concept of web browsing took off, web browsers would quickly evolve into the graphical web browser species beginning with Mosaic, Mozilla, and finally browsers such as Navigator and Explorer (there are dozens of other browsers of course, we just name the biggies). These browsers offered a truly user-friendly graphical interface that turned bland library-like document archives into an exciting electronic frontier.

Consider the same page as above, viewed in Netscape and Internet Explorer!

The ability to create forms is really the beginning of a true, traditional web application. HTML forms allow web application developers to design standard input forms with widgets such as drop downs, text boxes and buttons. Users can enter in data dynamically using these widgets.

Behind the scenes, once the user enters in their data and hits a submit button, the web browser will collate the user defined values for the form widgets and submit them to the web server using the POST or GET methods of the HTTP protocol. Again, we will discuss the HTTP communication layer aspects in the next section.

What you should do at this point is get comfortable with the idea that HTML provides the syntax for defining forms and that browsers will help you process those forms.

Why can't we drag and drop excel files into our browsers? Why can't we have more powerful form widgets like grids and trees? Why can't we have more powerful animation, font, and layout tools? These were the questions being asked of the browser manufacturers daily.

Unfortunately, browser manufacturers realized that in order to keep their applications quick and manageable they would need to keep their applications simple and lean.

As a result, browser manufacturers were unwilling to add all the features desired by the web application development community.

However, all was not lost. Early, innovative pioneers discovered that they could extend browsers not by building bigger browsers, but by plugging in smaller components into the browser as needed. In response, browser manufacturers provided an interface so that plug-in developers could get to work.

Plug-ins appeared right and left. Some of the most notable plug-in packages included Real Audio, Real Video, Shockwave, and Acrobat

These plug-ins were proprietary software tools that were browser aware and of which the browser was aware. Thus they could be executed by the browser when needed and could take advantage of the HTTP pipeline that the browser maintained. In the beginning, plug-ins appeared as separate applications to the user with their own windows. However, over time, plug-ins became encapsulated by the browsers so that they appeared more cohesive to the web surfer using them.

In fact, the browser became a sort've worldwide desktop upon which application developers could distribute their own full featured applications with high performance scalable widgets such as trees, grids, tables, image buttons, etc.... Consider the following screen shot of an embedded applet that looks to be a fancy looking HTML page but which is much, much more.

Java was originally developed at Sun Microsystems in 1991 to provide a platform-independent programming language and operating system for consumer electronics (TV sets, toasters and VCRs).

In syntax and execution, Java is a lot like a simplified version of C++. ("simplified" should be read in the previous sentence as "an improved"). It is a highly robust, distributed, high performance, object-oriented, multi-threaded language with all of the usual features. As such, it builds upon years of C++ development, taking the good and dispensing with the bad.

As it so happened however, Java did not make it into the consumer electronics market. Instead it wound up in our web browsers.

Java seemed to be a perfect fit for the web. The language itself was extremely small (as it was built to go inside toasters and alarm clocks with tiny amounts of memory). Thus it could quickly be transferred over the web.

Further, Java was platform independent. That is, any computer with a Java virtual machine can run a Java program. Programs can be written anywhere and be run anywhere. This is crucial because if a language can not run on any machine, it cannot be used on the web that must service every machine, language, and environment imaginable.

Platform independence works because Java is an interpreted rather than a compiled language. Unlike C or C++ code, when Java is compiled, it is not compiled into platform specific machine code, but into platform independent byte code. This byte code is distributed over the web and interpreted by a virtual machine (typically built right into a web browser these days) on whichever platform it is being run.

Thus, as a programmer, you need only concern yourself with the generic Java programming language and compile your applications into bytecode on whatever system you are using. You can then be assured that your bytecode will be executed correctly whether your clients are using Macs, Pcs, Unix boxes or anything else.

What's more, Java was a full-featured programming language complete with a more complete collection of user interface widgets in its AWT library, networking capabilities, database connectivity, internationalization features, and much, much more.

Though Java was sadly reduced to tickers and bouncing balls for the first few years of its life, by now, many high quality, production applications have been completed and are running happily with java served through web pages.

NOTE: To a certain degree, I also like to think of client-side Active-X components as plug-ins. Active-X technology allows web browsers on Microsoft systems to leverage the vast resource of Windows. Like Java applets, Active-X components can be instantiated within the context of the web browser itself making it appear that the web browser is providing the functionality when in fact the Active-X component is simply piggy- backing off the browser. Since any COM object in Windows can be an Active-X control, almost every Windows resource can thus be embedded in the browser window. Controls can be as simple as a custom stock ticker or as complex as an application like Microsoft Excel. Consider the following screen shot of an Excel spreadsheet embedded directly into Windows Internet Explorer. Of course, beware that Active-X is a Microsoft-specific technology so it may not ever work on Netscape or on Macintosh.

In some cases, users would be willing to wait. Specifically, if the applications they required demanded the rich texture provided by plug in technologies, users would accommodate download times.

However, in other cases, users wanted a less complex solution. Granted, the solution should be more complex than HTML forms, but not necessarily as complex as Java.

Enter JavaScript.

Netscape 2.0 introduced JavaScript (initially LiveScript), a distant cousin of the Java language, as a means for achieving some special effects in the web browser without actually having to resort to a plug-in technology.

Actually, to tell you the truth, JavaScript is a bit of a misnomer (or a marketing ploy) because though JavaScript is indeed a scripting language (browsers include a JavaScript interpreter), it actually is very different from Java. Whereas Java is a self contained programming language capable of full featured application development on its own, JavaScript is built as a programming glue that developers can use to tie other technologies (HTML or the browser itself) together within the scope of the web browser. That is, you would rarely say that you had finished work on a JavaScript application, but you might say that you had added some JavaScript functionality to your web page.

JavaScript is not so much about adding new functionality as it is about tweaking existing functionality to make it seem more cool.

The most important thing to understand about JavaScript is that it exposed much of the browser API to developers. Specifically, the browser and many of the widgets inside the browser could be talked to, listened to and controlled.

Developers quickly began to use JavaScript for such purposes as animation, accessing the bookmarks and history, event handling (like mouse over effects such as when a graphical image button lights up when the mouse crosses over it), form field validation (such as when you make sure the user has entered in data for all the required fields before you let them submit the HTML form to a web server), and the spawning of event dialogs and new windows.

What was nice was that JavaScript was written for the common person and required little programming background to master. Web designers could add a great deal more functionality and bells and whistles to their existing HTML pages without needing to resort to server-side programming like CGI.

JavaScript has gone through several iterations of versioning and though there are still compatibility problems between IE and Netscape, the standard features of the language have been nailed down pretty well.

Yet, almost as soon as it was released, developers realized that exposing the browser API was not enough. Client-side scripting languages, they realized, had the potential to be incredibly powerful if they were only given a bit more umph. Specifically, they need to have the document API exposed.

Like we'd seen with JavaScript and VBScript, dHTML exposes GUI widgets to the programmer so that she can manipulate them. However, unlike what we'd seen before with JavaScript and VBScript, developers had much more available to them beyond the browser and the form widgets. In fact dHTML has a much more diverse universe of widgets available to it.

This is because of the use of the Document Object Model (DOM) and style sheets (like Cascading Style Sheets [CSS])

The DOM is used to create virtual widgets out of the components of an HTML document. Using the DOM, for example, not only are the Netscape menu bar, bookmark list, and window accessible GUI widgets, but so are every paragraph in an HTML document, a table cell, and even an individual character of text. Each element in a document becomes a virtual widget.

Style sheets are used to apply style attributes to each of the elements in the DOM. Thus, a style sheet might define the margin, color, and size of a paragraph of text.

Since document components become widgets, they also become exposed to a scripting language like JavaScript or VBScript that can modify the attributes of their style just as they would modify the attributes of any other widget.

As such, a client-side scripting language can be used to modify any element on the page. Perhaps you want to make a word flash through a cycle of colors, perhaps you want to change the colors in a table depending on the data entered. Perhaps you want to generate a slide show. All this can be done on the client side using dHTML.

As you can see, dHTML is not so much as a technology itself as a synthesis of many technologies.

Unfortunately, dHTML is still very new and as such, has not been standardized between browsers. In fact, Netscape and Internet Explorer use almost completely different models such that many dHTML features will simply not work on both browsers.

However, at some point in the life of most web applications, the developer must send the information collected by the user from the GUI widgets, to the more powerful backend web server for processing. To do this, the developer must access the web server using the communication technologies provided by the web browser and web server. This involves passing through the Communications Layer.

This Communication Layer is the focus of the next section.....