Making a Web page is easy. Given a good software package, any beginner can create a Web site in less than a day… sometimes less than an hour! Given a little more time, your average computer user can probably pick up a good understanding of HTML too, giving added control over the look and design of the site.
In this article, I’ll attempt to do just that. I’ll begin this week by drawing a line between the two main categories of advanced Web technologies: client-side and server-side technologies. I’ll talk about what makes them different, and the advantages and disadvantages of each. Then I’ll take a stroll through the client-side technologies, providing a plain-English description of what each of them does and a couple of links to where you can learn more. Finally, I’ll do very much the same thing for each of the server-side technologies.
By the end of this article, you should have a better idea of how it all fits together. And hopefully, you’ll be equipped to decide for yourself what to learn next based on what any given technology can do for you.
Waiters and Customers: Clients and Servers
As I mentioned above, advanced Web design technologies may be divided into two broad categories: server-side and client-side. Understanding the difference between the two requires a basic understanding of what goes on when someone views a Web page on the Internet.
You’ve done it hundreds, if not thousands of times before. You’ve typed a Web address (URL) into your Web browser’s address field and it has loaded and displayed the corresponding Web page. But what’s really going on behind the scenes?
In the simplest sense, there are two computers involved in this process: your computer, where you Web browser is running, and the computer somewhere on the Internet that serves up the Web page in question. In this arrangement, your computer is known as the client and the computer providing the Web page is known as the server. Think of the server as a waiter in a busy restaurant, and the client as one of the customers clamouring for his attention. Just like in the real world, one server (or waiter) is responsible for fulfilling the requests of many clients (or customers).
In our busy restaurant, the waiter takes orders from the customers, and then brings them (hopefully) what they ordered. This is surprisingly similar to what goes on between the client and server computers on the Web. The client computer, as you know, runs a Web browser that allows it to view Web pages. This software, when provided with a Web address, sends a request for that address over the Internet to another software program running on the server computer. This program, known as a Web server, responds to that request by sending back the Web page corresponding to the address. It is then up to the browser to interpret that Web page, converting it into human-readable format and slapping it up on the client computer’s screen.
The retrieval and display of any Web page on the Internet proceeds along the same general lines I have just outlined; however, it’s not always quite as simple. Most advances in Web design lately have come with the cost of additional steps in the above process. Whether the additional steps come before or after the waiter hands the customer his order is the difference between client- and server-side technologies.
In most restaurants, the waiter isn’t the one responsible for preparing the food; that’s the cook’s job. The waiter just takes the order, and relays it to the cook. The cook prepares the order, and then gives it to the waiter to give to the customer. In a way, the cook assists the waiter in his work: giving the customers what they ask for. In the same way, the Web server software running on the server computer can have ‘helpers’ that let it do more than just serve up ready-made meals–err, Web pages. These helpers are server-side technologies for advanced Web design.
Now, when the customer finally gets his order from the waiter, the logical thing for him to do is eat it, right? But sometimes it’s not so simple. Consider, for instance, if the customer ordered French toast. Typically, he will also be given a little cup of maple syrup. If the customer were to just eat his meal as-is, taking a swig of maple syrup after every few bites of French toast, he might get a funny look or two. Instead, the customer is expected to spread the syrup on his toast before eating it â€“ a small part of the task of preparing the meal has been left for the customer to do. By the same token, some Web pages are more complex for the browser to display than simply taking the HTML and converting it into a picture on the screen. Sometimes additional tasks must be completed by the Web browser for the Web page to be displayed. Anything that requires the browser to become a more active participant in determining what to display on the screen is a client-side technology for advanced Web design.
Let’s now take a look at the currently available client-side technologies. Remember, the one thing all of these technologies have in common is that they require the browser to do something other than read pure HTML to display a Web page.
- VBScript Overview on Windows Scripting Technologies
Cascading Style Sheets (CSS)
Cascading Style Sheets sound a lot scarier than they really are. CSS is a language for describing how you want the elements of a Web page to look. Whereas before you would do this with tags like
<FONT>, CSS allows you to use HTML to define just the structure of the information being displayed on a Web page and then tell the browser how you want that information to be presented.
For example, instead of using
<FONT FACE="arial"> all over your site to set text inside of
<P> tags to an Arial font, you can just use bare
<P> tags, and create a CSS file that instructs Web browsers that all
<P> tags should be displayed in an Arial font. Making changes to the look of your site becomes much easier, since you can make a change in one place and have it affect your whole site at once, and your HTML code becomes much less cluttered.
Again, different browsers support CSS to differing extents, and there are in fact entire swaths of the CSS language dealing with how a Web page should sound when it is read by software for the blind that have yet to be supported by any browser at all. Nevertheless, there is enough support available already to save yourself a lot of time typing
<font> tags, and you may actually find that CSS saves you more time than it takes you to learn it!
- Mulder’s Stylesheets Tutorial on WebMonkey
Dynamic HTML (DHTML)
- Beginners Guide to DHTML on WebmasterBase
Java is a full-featured programming language like C++, but simpler and more tightly structured. Java programs, instead of running directly on a computer’s operating system, run on a "Java Virtual Machine", which itself is a program that runs on the computer’s operating system. This means that, in theory, any operating system that has a Java Virtual Machine (pretty much all major operating systems these days) can run any Java program. Since the production of Java Virtual Machines is highly standardized, incompatibilities between the various platforms are minimal. The disadvantage is that Java programs tend to run slower as the Virtual Machine has to convert Java program instructions and pass them to the operating system on which it is running.
What does all this have to do with advanced Web design? Well, modern Web browsers usually have Java Virtual Machines embedded within them. This allows a Web designer to embed small Java applications (called Applets) into Web pages. While learning Java and programming Java applets is far from simple, Java applets can do just about anything a regular program can do, except they can do it in a rectangular area inside a Web page.
Common uses of Java applets include chat programs and online games. For security reasons, however, Java applets cannot access files or other potentially sensitive information on your computer, and they cannot connect to computers other than the Web server that sent them.
- The Java Tutorial from Sun Microsystems
Server-side technologies for advanced Web design are largely the result of users’ desire for Web sites to serve as large, dynamic, interactive, and customizable sources of information that is kept constantly up to date. When these goals fall on your lap as a Web designer, you quickly realize that your trusty HTML editor just isn’t up to the task.
Consider the official Olympics Web site, which at the time of this writing is providing event results and other coverage of the Summer Games in Sydney, Australia. If you live in one of the lucky countries that is getting live TV coverage of the Games and have checked out the site, you were probably impressed by the fact that results on the page are so up-to-date that they often feature headlines such as “At the halfway mark, the race leaders are as follows…” that are as fresh as what you’ll be watching on television!
How is this possible? Does IBM (the company responsible for producing the site) have reporters editing HTML on laptops at each of the events? Of course not! Not only would this be a management nightmare, but it would be impossible to produce results of the quality and reliability that can be found on the site without a lag time of several hours (consider the mess of updating the medal tally pages when several events are occurring concurrently!).
No, plain HTML pages are definitely not up to this kind of task, and neither are any of the client-side technologies we saw last time. With the possible exception of Java, which can do just about anything a software program can do (but then IBM would have been just as well off making people download a full-blown program to view Olympic results), client-side technologies are all either too unreliable (in terms of browser support) or not powerful enough.
As we have mentioned, server-side technologies are the solution here. While basic Web server software simply sends HTML files in response to requests from Web browsers, server-side technologies expand on the capabilities of the Web server to allow it to dynamically generate HTML web pages by running programs, connecting to databases, and doing other fancy stuff in response to a browser request.
Since only the Web server itself needs to support any given server-side technology used to build a site, there are a lot more options out there in this area. In this article, we’ll cover the most widespread of these to give you a good idea of what’s out there.
Common Gateway Interface (CGI)
The Common Gateway Interface, or CGI, is a standard that allows a Web server to execute an external program and send its output to a Web browser that requested it. Thus, a CGI-capable Web server, when receiving a request for, say, “medalstandings.exe”, will not simply send that file to the browser. Instead, it will recognize the file as an executable program and run it. The Web server captures the output (which is usually an HTML document, but could be anything from a GIF image to an Adobe Acrobat document) and sends it to the Web browser in response to the request.
CGI was the original method of creating dynamic Web applications. You can write a program in C/C++, Perl, or whatever language can run on your Web server computer, and tell the Web server to treat it as a CGI program. CGI has become very unpopular lately with the rise of server-side scripting languages (which we’ll look at in a moment), because with CGI the Web server has to launch an external program for every request. A site that gets 10,000 hits an hour will result in a lot of these CGI programs running at once, placing a tremendous strain on the Web server computer and slowing down access times to the site.
- CGI Scripts for Fun and Profit on WebMonkey
Server-Side Scripting Languages
Server-side scripting languages, such as PHP, ASP, and PerlScript, are all intended to fulfill the same role as CGI (allowing the Web server to run a specialized program in response to a browser request) without the burden of launching an external program for every request.
By installing a plug-in, you can “teach” Web server software how to do things like run programs written in Perl or PHP (see below for descriptions of these) all by itself, instead of having to ask the operating system to run them as separate programs. When a Web page containing one of these languages is requested, the Web server uses its internal plug-in to run the code in the page, then send the results to the Web browser.
The distinction here is subtle, but very important. If, for instance, a Web server knows how to interpret Perl code all by itself, it doesn’t have to waste the time and resources involved in launching the code as a separate program to generate a dynamic Web page with it. In addition, the Web server can do smart things like realizing that a particular dynamically-generated page will change at most every 5 minutes, so if it runs some Perl code in response to a request from one Web browser, it’ll keep a copy of the resulting HTML on hand for 5 minutes so that it doesn’t have to re-run that same Perl code if another identical request is received within that time.
- See descriptions of individual scripting languages below
Perl (also: PerlScript)
Perl is a programming language that excels at manipulation of text. As such, it is ideally suited to the development of dynamic Web pages. This isn’t to say that advanced Web design is the only application of Perl â€“ it is heavily used in the automation of administrative tasks on Unix-based systems, for example.
Perl programs (or “scripts”, as they are commonly known) can be installed either as CGI programs or as server-side scripts using the mod_perl plug-in for the Apache Web server (in which case they are sometimes said to be written in “PerlScript”).
Personal Home Page, PHP: Hypertext Preprocessor, or simply PHP, is a somewhat less flexible language than Perl, but is more specialized towards the creation of dynamic Web pages. This focus means that you can do pretty much anything you can do with Perl using PHP when it comes to advanced Web design, but with simpler syntax (making PHP easier to learn).