1，在frameset里使用iframe来实现常规的一些分栏布局，可以借助一个页面承载多个页面的方式来重用页面代码。
2，一个页面中的iframe之间可以互相实现关联，而且不需要依靠过多的js就可以实现类似“局部”刷新的机制。
3，一些常见的后台管理系统大部分是用这种方式来布局的（追其原因可能是上面2点），所以固定了思维系统布局可能用frameset来实现比较好。

用frameset来布局的缺点：

1，如果要实现不同iframe之间的dom元素产生互动和关联，需要的js复杂程度较高，而且有些根本实现不了（比如拖拽，比如用户自定制页面布局）。
2，一个页面承载多个页面的http请求，而且实现那种类似局部刷新的效果，不是后台运行请求的机制，而也是使用了前台的浏览器刷新机制，会有延迟的响应而且无法对响应进行控制（比如loading或者一些响应状态的监听）。
3， 由于常见的后台系统大部分是管理人员进行一些管理操作的，所以iframe的模式可以很快速的完成开发和迭代，但是目前（我们的系统）不光有管理的任务还 会承担展示和交互的一些功能需求，对页面的可操作要求比较高，iframe的可操作性又比较低。毕竟一个页面装载多个页面，不好调试和控制，在开发上的一 些功能上的不可实现，也会限制UI界面设计和交互的创意思路（比如一些页面特效，动画，dom的及时性改变等）。

使用DIV传统布局与frameset相比的优点：

1，整个页面可以自由操纵，无论是样式还是DOM元素。
2，UI设计与布局，功能上等，不会受到任何技术上的限制和避讳。（比如用户页面的拖拽，自定制页面等）

DIV传统布局与frameset相比的缺点与解决办法：

1，不可能快速的实现“局部”刷新那种效果，要转用ajax方式实现真正意义上的局部刷新。
2，页面代码不能高度重用，但是可以使用服务器动态语言里的include等语句实现。

所以DIV布局方式与frameset相比之下：前者可以完全弥补掉frameset的一些局限和缺点，而且也可以使用其他手段完成frameset的优点，且实现难度较小。

大量的使用ajax的传统DIV局部页面，会遇到的一些开发难点：

1，真正实现局部刷新的复杂的javascript开发工作。因为ajax是基于javascript的。
2，大量使用ajax的系统中客户端状态的保存问题，比如ajax操作过程中的页面状态储存，浏览器的前进功能，后退功能的实现。

解决方法：

1，使用jquery框架简化ajax与javascript的开发量，实现javascript代码的有效开发与管理。
2，使用rsh框架实现ajax系统中的客户端状态保存和模拟浏览器的后退前进功能。（RSH也是比较成熟的js库）。

最后在我们公司前端布局的选择上，决定使用传统的div布局页面代替frameset，主要是基于以下几点原因：

1， 由目前开发的系统的需求所决定，我们现在开发的系统已经不光局限于一些后台管理员的管理功能，更多的是一种展示，客户需要是一个丰富的RIA应用而非前 者，系统需求需要系统实现丰富的交互功能和好的用户体验，使用frameset已经不能很好的实现了。（最简单的例子：校内，开心中的用户界面，也是固定 的三栏布局，那么它为什么不用frameset来实现呢？可以自己思考。）

2，选择div传统布局也可以很好的完成frameset布局的全部优点部分，并且我们还拥有一期成功的项目开发经验。

3，从性能上说，减少了HTTP请求，增加了用户体验，而且把B/S的实现往C/S靠拢也是未来B/S发展的趋势。

4，在UI设计上说，会拥有比frameset更好更多的表现形式与设计形式。

5，针对DIV布局在实现B/S系统，相对于frameset布局的一些不足，完全拥有足够成熟的解决方案。

可能很多地方总结的不到位或者可能根本就是错的，以上均为小爝个人看，仅仅做为参考，希望可以有更多的人一起交流探讨。