在网络开发领域中对是否使用框架这一问题出现了分化，大多数人毫不犹豫的加以反对。网络开发者不喜欢网络框架有好几个原因，其中的一个就是框架导致了寻址（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分钟去下载隐含框架所需的对象。
