The Web development community is polarized over the issue of using frames, with a majority speaking out against them. Web developers dislike frames for several reasons. For one thing, they cause a navigation nightmare and older browsers don’t support them. For another, some Web sites have historically imposed their framesets onto another site’s content.

Despite these valid concerns, I think that in the right situation, frames can be useful—especially for reducing server traffic. I will start with a brief explanation of how various frame types are used and then look at how they can ease server traffic.

Types of frames
One type of frame is part of a frameset. It divides the browser window into subwindows. Each subwindow displays a different HTML document, which enables the developer to update only selected frames instead of the entire page. A navigation problem arises when the client clicks the browser’s Back button, but that can be handled by coding the JavaScript statement window.history.forward(1) on each page to disable the Back button.

An example of this type of frame is:
<frameset rows=”50%,*”
      <frame src=”page1.asp” name=”Bob”>
      <frame src=”page2.asp” name=”Paul”>

This example shows a frameset with two frames named Bob and Paul. Even though the document.location of Bob is page1.asp and the document.location of Paul is page2.asp, these pages can affect each other and communicate with each other. For example, the JavaScript statement top.Paul.readyState allows the frame Bob to determine whether the frame Paul has completed loading.

The second type of frame is the inline frame, or iframe. Introduced in Microsoft’s Internet Explorer 3.0, inline frames can be embedded in an HTML document in much the same manner that an image is embedded. Inline frames let the developer embed an HTML document within an HTML document. Here’s the syntax for an inline frame:
<iframe name=”Nan” src=”page3.asp” width=90 height=50></iframe>

On the surface, inline frames seem about as useful as a Commodore VIC-20 is in today’s business environment. But they do have some uses. One possible use would be to embed a code example in the middle of an article.

Reducing traffic with hidden frames
Now imagine a frame with a size of zero. The frame would in effect be hidden from the client. It sounds pretty useless, doesn’t it? On the contrary, when you’re trying to reduce server traffic, a hidden frame can be a most useful thing.

One use of a hidden frame is to store information for later processing. For example, I once created an intranet-based technical request system for an insurance company. This system allowed internal customers to enter various requests that required the assistance of system support. There were about a dozen types of technical requests, which could be as simple as “Run the fuzzy report” to “Take this input file, convert it to our internal format, and load it to the insured database.”

The client was required to enter one or more pages of information depending on the type of request. Instead of sending this information directly from the client to the server and storing it in session variables on the server side, I chose to store it on the client side in a form on a hidden frame. This allowed the user to click the Back button and have the previous page populated from the hidden frame instead of from the server, which reduced traffic. When the input was complete and the user clicked Submit, the form on the hidden frame was submitted.

As with most things, of course, this technique can be taken too far. I once saw an intranet application that had more than 50 hidden frames, containing every conceivable object that could possibly be displayed at some future time when navigating the application. These objects consisted of items like list boxes, images, and Swing applets that were loaded when the application was first entered. The idea was that after the initial load was completed, the application would be fast because it would be unnecessary to build a list box containing products, for example, each time one was needed. Instead, the list box would be copied from the hidden frame, thus reducing server traffic. I thought this was one of the most brilliant concepts I had ever seen. The problem was that the execution left something to be desired.

Imagine trying to concurrently load 50 ASP pages, most requiring information retrieved from a database. Other pages required large images or absolutely tremendous Java Swing applets. In all fairness, I will say that once everything loaded, it was amazingly fast, but it took five minutes to load at Ethernet speed. I can’t even imagine how long it would take at 56K. Although this implementation of the technique of loading objects to hidden frames left something to be desired, the idea was a sound one.

Frame of mind
Frames, like any tool, are neither inherently good nor evil. Most of the problems developers have with them result from the way frames have been misused in the past. As we’ve seen, when used correctly, HTML frames provide a way to reduce server traffic. In my next article, I will show you a workable way—that doesn’t take five minutes—to load objects in hidden frames.

Client-side tricks to share?

Want to share some client-side coding tricks? Post a comment below.