Intro to the Web Application Development Environment
Table of Contents
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
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
For the most part, if you see a new technology, you can recognize it to
be a GUI technology if it allows you to create interfaces made up of
widgets and allows you to access those widgets as necessary.
Understanding the Web Browser
As you can probably guess, when it comes to the field of web application
development, all discussions of the GUI begin with the
web browser. At
its core, a web browser is a software program that knows how to
contact a web server (using the HTTP protocol), request a given
document from that web server, and display that document returned
by the server to a human user.
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
NOTE: Of course, it is important to note that though the browser
is indeed responsible for creating this framework for communication between the
world of computers and the world of people, it
is often the web application developer who must do the grunt work of
translating actual bits of content between parties.
That is, the web browser's primary task is to provide a communication
framework upon which a web application developer can build. In other
words, though the browser knows how to get HTML pages from a web server
and display them, it is the responsibility of the web application
developer to design a well-navigable site with interesting and useful
A Short History of Web Browsers
In terms of the use of a web browser by the mass public, the history
of web browsers begins with LYNX.
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
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).
NOTE: Why not just code to Internet Explorer? I'm often asked this question.
And I have to say that to a large degree, the question makes alot of
sense. Afterall, IE has all sorts of cool extensions like the XML
parser and perhaps a better implementation of dHTML. And these days, it
is getting to be that IE users are seeming to overwhelm Netscape users,
especially on Intranets.
Well regardless of that, I still say that any serious web developer will
always choose to develop in a cross browser way, even if that means giving up
some functionality. Though this may cause you a
greater degree of pain in the dvelopment process, it has important benefits.
For one, developing for the least common denominator keeps you sharp.
When faced with a lean environment, you end up coding better. With less
resources, you learn to be creative instead of lazy!
Further, the fact
is that there are many clients out there that use other browsers as well
as older versions of those browsers. Even if your applicaiton is speced
out as "intranet-only", if it is a good applicaiton, it won't be long
before it has to go out to external clients as well.
So it is better for you to design with that in mind.
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
As you can see, the basic feature (display of HTML) of the most basic GUI
web application tool (the browser) can have
dramatically different results!
Basic User Interactivity with HTML Forms
However, besides displaying HTML-formatted text to users, web browsers also
provide a means to solicit data from users and send that data to web
servers. They do so by using HTML forms.
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.
NOTE: Besides dealing with HTML form widgets, web browsers also help
you maintain application state. they do so by providing an
interface for "cookies".
As you will see later, because HTTP is a
stateless protocol, most web applications will need help "remembering"
what has happened so far in their work flow.
Consider the example of a web store that might need to keep track of all the items a
client has added to a virtual shopping cart. The web store application must
keep track of the shopping cart items wherever the user goes on the
website, or even whether or not the user leaves the website and returns later!
To help solve this problem of state maintenance, browsers keep a log of all the
application activity locally in a "cookie" (an invisible widget of sorts).
Applications can access the contents of the cookie so that they can
maintain the state.
Extending the Browser with Plug-ins
Though powerful and revolutionary as browsers were with their ability
to display HTML, gather and send user data to a web server, and store
cookies, they were a bit too limited to really drive the net revolution
whose visionaries were demanding more and more resources and freedoms.
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.
Fortunately for everyone,
plug-ins brought functionality to the web browser without forcing web
browser manufacturers to add it themselves. This meant that features could be
added more quickly without the browser developers as a bottleneck and
that the browsers themselves would not become bloated. Object-oriented
design at its best!
One plug-in that was actually integrated into the browsers
almost as soon as it was released, was Java from Sun Microsystems.
Java was a programming language that could be used by anyone
to code add on features that would be executed
within the context of the browser. The browsers added Java Virtual
Machines to interpret the Java code downloaded from web servers.
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
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
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
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
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.
Exposing the Browser API with Client-side Scripting
As you might imagine, adding all these add-on features to the web
browsers began to cause problems. Specifically, distributing
functionality in the form of Active-X controls, plug-ins, or Java applets could
mean unacceptable download times for users.
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.
Java language, as a means for achieving some special effects in the
web browser without actually having to resort to a plug-in technology.
released their own semi-compatible version called JScript in Internet
Explorer 3.0. JScript, however eventually lost much of its appeal after
Microsoft released VBScript that leveraged the Visual Basic programming
VBScript would fast
become Microsoft's preferred Web Language however because most developers
like to keep their applications cross browser compatible, VBScript has receded to
a large degree onto the server side for ASP which we will talk about later.
self contained programming language capable of full featured application development
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
tweaking existing functionality to make it seem more cool.
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.
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.
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.
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.
Enter Dynamic HTML....
Exposing the Document with the DOM and dHTML
Dynamic HTML (dHTML) provides a way to combine plain HTML, cascading
style sheets, and scripting languages into a much richer browsing
experience. In fact, as dHTML becomes a reality, it becomes more honest
to talk about fully client-side web applications that rarely need to
contact the web server.
programmer so that she can manipulate them. However, unlike
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
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
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, like all web technologies, though there will always be cross platform
issues of some kind, they will get more standardized over time. dHTML is one of the most
exciting technologies released to this date, and promises to completely
change the way web applications are created in a few years.
So as you can see, though there are quite a few technologies that fit
into the GUI Layer, they are all tied together by the thread of widgets.
All GUI Layer technologies focus on the presentation and manipulation
of widgets on the client side.
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.....
Table of Contents