在網絡開發領域中對是否使用框架這一問題出現了分化，大多數人毫不猶豫的加以反對。網絡開發者不喜歡網絡框架有好幾個原因，其中的一個就是框架導致了尋址（Navigation）特別麻煩，并且一些老的瀏覽器也不支持它們。另一個原因是一些網頁地址過去曾強制框架（framesets）連到別的地址上的內容。

 
盡管這些問題不是空穴來風，我還是認為使用框架是一個正確的方向，框架是有用的，特別是在減少服務器流量方面。我將簡單的介紹一下如何使用各種框架，然后考察它們是怎樣減輕服務器流量的。

框架的類型
第一種框架是關于圖文框的。它把瀏覽器窗口分成好幾個子窗口。每一個子窗口顯示不同的HTML文件，這就是的開發者更新選定的子窗口而不是整個頁面成為可能。當用戶點擊瀏覽器的“后退”按鈕是就會產生尋址的問題，但這可以通過對每一個子窗口的JavaScript語句中加window.history.forward(1)來使得后退按鈕失效來解決這個問題。

下面給出了這類框架的一個例子: 
<frameset rows=”50%,*”
      <frame src=”page1.asp” name=”Bob”>
      <frame src=”page2.asp” name=”Paul”>
</frameset>

上面的例子給出的主框架有兩個分別名為Bob和Paul的框架。盡管框架Bob的document.location是page1.asp而Paul為page2.asp，這兩個頁面還是可以互相影響、互相通信。舉例來說，JavaScript語句top.Paul.readyState允許Bob框架檢測Paul框架是否載入完全。

第二種是內聯框架（inline frame或iframe）。它有微軟Internet Explorer 3.0版本引入的。它把內聯框架嵌入HTML文檔中，就像HTML文檔嵌入圖片一樣。內聯框架可以使開發者把一個HTML文檔嵌入到另一個HTML文檔中。這是嵌入內聯框架的語法：
<iframe name="Nan" src="page3.asp" width=90 height=50></iframe>

從表面上來看，內聯框架的作用與Commodore VIC-20在當今的商業環境的作用是相同的。但是，內聯框架確實有些用處。我們將在一篇文章的中間討論它的一個可能的用處。

用隱含框架（hidden frame）來減少流量
現在設想一個大小為零的框架。這個框架對用戶來說是隱含的。這聽起來似乎毫無用處。然而，當你試圖減少服務器流量時，隱含框架就顯得重要多了。 

隱含框架的一個作用是保存稍后處理所需要的信息。舉例來說，我曾經為一個保險公司建立了一個基于網絡的技術申請系統。該系統允許互聯網用戶提出需要系統支持的申請。這些申請大約有十幾種類型，復雜程度可以從“運行模糊報告”到“接受輸入文件，將它轉化為網絡格式，然后載入安全（insured）數據庫”。

根據不同的申請，客戶需要填寫一到幾頁的資料。我那時把這些資料用客戶端的隱含框架中的一個表來暫存，而不是立即將它們從客戶端發到服務器上，并用一組變量來存儲。當用戶使用后退按鈕時他所瀏覽的以前的頁面是從用戶端的隱含框架恢復出來的，而不是服務器。這就減少了服務器的流量。當用戶填寫完畢并點擊“遞交”按鈕時，隱含框架所保存的信息就遞交給服務器。

像大多數情況那樣，這個技術還可以被進一步推廣。我曾經看到一個網絡開發者使用了多達50個隱含框架，包含了使用該程序所可能用到的所有對象。這些對象包括了諸如下拉列表、圖像、Swing applet等類型。當一開始的載入完成后，該程序的運行速度會很快——因為，例如，它無須建立一個包含產品名字的下拉列表，而僅僅是從隱含列表中拷貝這個下拉列表。我認為這是我所見到的最有才氣的想法。但是還有些問題有待解決。

設想如果同時載入50個動態網頁，其中的大多數還需要訪問數據庫，其余的包含了大幅圖片或者干脆就是大型Java Swing applet。我可以很肯定的說，如果一次載入，該程序會運行的很快，但是在以太網上，載入過程需要5分鐘。如果是以56K（modem），我簡直難以想象需要多少時間了。盡管使用該技術（用隱含框架保存下載的對象）會遺留一些問題，該技術還是不錯的。

智能框架
任何工具——包括框架——本省并沒有好壞之分。開發者在使用它所遇到的大多數問題源于誤用框架。正如我們所看到的，如果使用得當，HTML框架可以提供一種減輕服務器流量的途徑。在我的另一篇文章中，我將提供一種切實可行的方法——它不需要5分鐘去下載隱含框架所需的對象。