• All Content
• Articles
• Links
• Books
• Comments
• Tags
• Contact
• OmniFlow

Most Nerd-Its | Nerd Trends | Last Ten

What is OmniNerd?

Voting Booth

Web design has come a long way in the course of the last 10 years. When you look back and consider the pages that were out on the Internet in 1994 and contrast them with those of 2004, the differences are astounding. On a web that was once ruled by simple servers that did nothing more than hand an HTML file to a client directly from their disk storage, dynamic sites now reign supreme. Now, HTML didn’t go anywhere. In fact it’s still the primary medium for web data. It’s the servers that have radically transformed and are now shaping the ways in which the web works. Gone are the days of static web content and in has come dynamic server programs that can generate web content on-the-fly depending on the client’s request.

How the Web Works

Contrary to popular belief, the “World Wide Web”¹, or just “web” for short, is not all that complex. Granted, the actual physical structure of connecting thousands of computers together and implementing routing technology to get data where it needs to go is no small task, but the web itself, the actual process of going to a web page and viewing the content, is quite simple.

It all starts when you open your browser. It doesn’t matter if you’re running Microsoft’s Internet Explorer, Apple’s Safari, or any other of a myriad of browsers because they all speak the same language when making a web page request. They communicate on behalf of your computer (the client) using what is known as HTTP, or Hypertext Transfer Protocol. HTTP versions 1.0 and 1.1 have defined the web as we know it since about 1990. Previous versions existed, but they were used primarily for raw data transfer and did not handle the depth of functionality needed to create the web that we know and love. All of this information and more can be found in RFC 2616.²

You’ve probably seen “http” thousands of times as that little blurb of text just before you type in “www.whatever.com.” As you’ve probably guessed by now, that little blurb tells your browser that you want to talk to the computer (server) known as “www.whatever.com” using HTTP. This implies that your browser, once the request is sent, will be waiting on a hypertext³ data stream from the server. Once the server gets the request, it looks for the file, and if present, sends it to the client as requested. That’s it. Now there is a lot of lower level stuff defined in RFC 2616 concerning exactly how all of that happens, but none of that is important to the scope of this document and therefore will not be considered.

Let’s consider a simple example just to make sure this concept is clear. Let’s say you type in omninerd.com into your browser. Your computer puts a request out on the web asking the server omninerd.com to send it hypertext. On the server side, the computer known as omninerd.com gets your request. Since it is running web server software and is setup to handle such a request, it responds to your computer and sends it the hypertext that it is programmed to send when a request is made. Your computer accepts the hypertext according to the standards laid out in RFC 2616 and begins rendering the web page in your browser’s window. That’s all there is to the actual requesting of a web page. So the question is, now that you’ve got it, what do you do with it?

HTML

Hypertext Markup Language, commonly referred to as HTML, is the most common way to send hypertext on the web.⁴ HTML is nothing more than a bunch of tags that tell your browser what kind of text it is looking at. For example the author of an HTML file may want the title to appear in bold on your screen when you view it. Using what are called tags, the author would write something like this:

<bold>My Book Report</bold>

It’s easy enough to see that every thing between the opening bold tag and the closing bold tag should be presented in bold text. This is all there is to HTML. If you’ve never seen HTML before, right-click on this page and choose the option that says something like, “view source.” From here you will see this document in its HTML form, which is the form it was in when it was received from the server. In the end, your browser, in order to make it look how the author intended it to look, did all of the formatting itself.

HTML brings us to the first major differences in web pages 10 years ago and the pages we see today. It used to be common practice for the author of a web site to simply write a page in HTML and upload it to a server. That’s all there was to it. This technique is still common for small sites because of its simplicity. If I have a personal web page and all I want to do is post a few pictures and list my CD collection, then there’s no reason not to write my page in HTML and be done with it. But what if you’re not writing a personal web page. What if you’re a huge corporation that manages an enormous database that is constantly changing yet you want to have a web interface that accurately reflects the data in the database? Are you going to copy the data over every day and save it as an HTML file? Probably not. This is where scripting, data storage, and the web of today comes into play.

Client-Side vs. Server-Side Scripting

A script is a set of instructions for a computer to carry out. In the realm of web scripts, there are two types: server-side scripts, and client-side scripts. As their names imply, the only difference between the two is where they are executed. Scripts can be used to take a static web page and make the content dynamic.

Client-side scripts are common and simple to write. For example, I could make a page display the current date and time when the user loads it by creating a JavaScript⁵ variable like this:

var dateAndTime = new Date

…and then displaying it. The result would look something like: Wed Jun 30 2004 15:55:37 GMT-0600. Then every time I reload the page, the date and time would update itself automatically. One thing important to keep in mind with client-side scripts is that the data all comes from the client. So, in this case, if the client’s internal clock is set to the wrong time then the wrong time will be displayed on your page when it loads.

Client-side scripting is an easy way to make a page more dynamic. One of the advantages is that it all embeds directly into your HTML code. This is convenient because it saves you the hassle of having to set up and special software on your server to handle your scripts. All of the script processing will be taken care of by the client. On the flip-side, you are totally relying on the client’s browser to handle the script. While this is generally a safe assumption, there are still browsers out there that do not support client-side scripts, and if a user wants to, there is usually an option within the browser to disable client-side scripts. If this happens, your page will not be displayed as you intended it.

Server-side scripting offers a more reliable solution for dynamic content. With a server-side script all of the computing is done on the server before any HTML is sent to the client. This takes the burden off of the client to handle the script. Using the date and time example from before, with a server-side script the date and time would be calculated and put directly into the HTML. When the client receives it, it will simply consider it to be text and display it as it does all of the other text. It doesn’t matter what time the clock on the client is set to because it won’t have to do any calculations.

There are several mainstream ways of doing server-side scripting. One method is known as CGI (Common Gateway Interface).⁶ CGI scripts execute programs on the server and then based on their output, make the page dynamic. The program executed can be anything and therefore poses somewhat of a security risk. If the program being executed isn’t secure, there is a potential to make the server itself vulnerable. CGI scripts are commonly written in Perl.⁷ Perl is useful because it is a very powerful and easy to program language. Perl programs don’t require compilation and therefore are very easy to edit and maintain. Though Perl is probably the most common CGI language, any programming language can be used.

An increasingly more common way of handling server-side scripts is to use an extension to your web server that allows it to read a file that is requested, parse all of the embedded scripts, execute them, and then based on the output, send the client an HTML file that is the product of the script. Three mainstream server-side script extensions for web servers are PHP⁸, ASP⁹, and JSP.¹⁰ These technologies allow the author to do a wide variety of server side tasks prior to sending the client any HTML. For example, if the author was managing a large database and wanted to display the data on the web, he could program the script to query the database, format the values using HTML, and then send the HTML to the user. Using this method, the author would only need to write the script once and as the data in the database changed, the data on the web page would change dynamically as well.

Data Storage

There are a variety of ways in which data can be stored for use on the web. Two common ways are through use of XML data files and Relational Databases. XML documents are just like HTML documents, only less defined. In HTML there are only certain tags you can use. With XML, you can make up whatever tags you want. By making a hierarchy of tags, you can establish a very useful means of storing data.

The other method of using an actual database requires more software. Programs like mySQL can store lots of data and then retrieve it using various queries. This is a common solution for web designers who will be dealing with extremely large quantities of data. Database programs have been around for a long time and are well-suited to handle large amounts of data. The only downside is that you have to be a little database-savvy to really use them to their full potential.¹¹

There are a variety of things to consider when choosing a method of data storage but they are beyond the scope of this document. The important thing to know is that there are ways of storing data for the web outside of an HTML document.

Transformation of Data to HTML

Once the author of a web site has the data stored in a manner that best suits the site, a way to transform it into HTML must be considered. This is done by applying a set of rules to the data depending on how it is stored. For example, let’s say that a person’s name is stored in an XML file like this:

<NAME>John Doe</NAME>

If the server sent the data exactly as it is stored, an HTML browser wouldn’t know what to do with it. In order to remedy this, we write a rule that says, “any time an instance of the <NAME> tag is encountered, take the text within the tag and surround it with <BOLD> tags.” Now obviously that rule would have to be written in some sort of computer code, but it should illustrate the point. Once the rule is applied, the resulting HTML will be:

<BOLD>John Doe</BOLD>

This is HTML and it’s ready to be sent to the client.

These translations can be made with PHP, JSP, ASP, or any other scripting language directly, or rule-based languages like XSLT¹² can be used. Languages like XSLT make your scripts cleaner. In your PHP script, for example, all you would have to do to translate an entire XML document using XSLT rules would be to call one command with the locations of the files. It allows you to keep your scripts, rules, and data separate, and in the end makes your whole site more manageable and maintainable.

OmniNerd.com, An Example of a Server-driven Web Page

A lot of the explanation above might be hard to swallow, so let’s consider this site, OmniNerd.com. We’ll consider the advantages of how it’s set up now using PHP, XSLT, and XML compared to a standard HTML site. Look at the two images below (click to make them bigger). One shows how OmniNerd would look if it only had a news page and no subpages. Notice how simple the HTML page is compared to the PHP version. If OmniNerd.com was never going to be anything more than one page, PHP would have little value and probably not be the best choice.

Now consider OmniNerd.com in its actual form. A page that tracks news updates, links them to articles, and allows people to search for content. Let’s try to imagine doing this with just HTML. Imagine the site a few years down the road when there have been 1000 news posts added. What would you do if you wanted to change the way the site looked? Since you did the site with HTML, all 1000 pages would need to be edited. It would be a nightmare and totally impractical. Now let’s consider the PHP and XML solution. With PHP, the server handles all news posts and no manual editing is required. If I want to edit a part of the site, I only need to change the rule that controls it, which is only one file. The yellow files in the image below depict the files that contain the rules, the green files contain the data, and the red files are the PHP files. To add more content, like another article or news post, I only need to add to the green files, the XML. None of the other files will need to be changed.

As you can see, there is a definite reason why a person or company running a high-end web site with lots of data to present would favor server-side scripting. Now that you know what to look for, go browse the net and see what you find. When you’re paying your bills on-line, or writing something on your favorite message board, look to see what they’re running. I bet you’ll find some with CGI based pages, and a whole lot more with PHP, ASP, or JSP pages. Also be sure to look at pages that deal solely with HTML. You’ll probably notice that page styles within the site aren’t consistent and you probably won’t find a whole lot in the way of dynamic content. Of course there are always exceptions to the rules, but I think after a little looking around, you’ll agree that the web is making use of its servers more than ever before.

¹ Webopedia.com, Definition of World Wide Web, on-line at ___http://www.webopedia.com/TERM/W/World_Wide_Web.html___

² Information Sciences Institute, Request For Comments 2616, HTTP Para 1.1, on-line at _{ftp://ftp.isi.edu/in-notes/rfc2616.txt}

³ Webopedia.com, Definition of Hypertext, on-line at _{http://www.webopedia.com/TERM/h/hypertext.html}

⁴ Webopedia.com, Definition of HTML,, on-line at _{http://www.webopedia.com/TERM/H/HTML.html}

⁵ Sun Microsystems, JavaScript Reference, on-line at _{http://devedge.netscape.com/central/javascript/}

⁶ Webopedia.com, Definition of CGI, on-line at _{http://www.webopedia.com/TERM/C/CGI.html}

⁷ Perl.org, Perl, on-line at _{http://www.perl.org/}

⁸ PHP.net, PHP, on-line at _{http://www.php.net/}

⁹ Microsoft, ASP on-line at _{http://www.asp.net/}

¹⁰ Sun Microsystems, JSP, on-line at _{http://java.sun.com/products/jsp/}

¹¹ If you’re interested in doing database design and don’t know where to start, check out the following book. The author has a good way of breaking down the elements of good database design in a non-mathematically intense way. Hernandez, Michael J., Database Design for Mere Mortals, 2nd ed., (Addison Wesley, 2003).

¹² World Wide Web Consortium, XSLT Recommendation, on-line at _{http://www.w3.org/TR/xslt}