web框架可以分为基于请求的（request-based）和基于组件的（
component-based）两大阵营。前者的代表有Struts和Spring MVC等，后者的成员则有JSF、
Tapestry等等。
基于请求的框架较早出现，它用以描述一个
web应用程序结构的概念和传统的静态Inter
net站点一样，是将其机制扩展到
动态内容的延伸。对一个提供
HTML和图片等静态内容的网站，网络另一端的浏览器发出以
URI形式指定的资源的请求，
Web服务器解读请求，检查该资源是否存在于本地，如果是则返回该静态内容，否则通知浏览器没有找到。Web应用升级到动态内容领域后，这个模型只需要做一点修改。那就是web服务器收到一个URL请求（相较于静态情况下的资源，动态情况下更接近于对一种服务的请求和调用）后，判断该请求的类型，如果是静态资源，则照上面所述处理；如果是动态内容，则通过某种机制（
CGI、调用
常驻内存的模块、递送给另一个进程如Java容器）运行该动态内容对应的程序，最后由程序给出响应，返回浏览器。在这样一个直接与web底层机制交流的模型中，
服务器端程序要收集客户端籍get或
post方式提交的数据，转换，校验，然后以这些数据作为输入运行
业务逻辑后生成动态的内容（包括HTML、
JavaScript、
CSS、图片等）。
基于组件的框架采取了另一种思路，它把长久以来
软件开发应用的组件思想引入到web开发。服务器返回的原本文档形式的网页被视为由一个个可独立工作、重复使用的组件构成。每个组件都能接受用户的输入，负责自己的显示。上面提到的服务器端程序所做的
数据收集、转换、校验的工作都被下放给各个组件。现代web框架基本上都采用了模型、视图、控制器
相分离的MVC架构，基于请求和基于组件两种类型大都会有一个控制器将用户的请求分派给负责业务逻辑的模型，运算的结果再以某个视图表现出来，所以两大分类框架的区别主要在视图部分，基于请求的框架仍然把视图也就是网页看作是一个文档整体，程序员要用HTML、Javascript和CSS这些底层的代码来写“文档”，而基于组件的框架则把视图看作由积木一样的构件拼成，积木的显示不用程序员操心（当然它们也是由另一些程序员开发出来的），只要设置好它绑定的数据和调整它的属性，把他们大大从编写HTML、Javascript和CSS这些界面的工作中解放出来。
基于请求的和基于组件的两种框架各有优劣。虽然一眼看上去后者有很大的吸引力，普通的web开发人员只要使用专门的公司或开源组织提供的组件就可以轻松开发出好用漂亮的界面，但是有几种因素综合起来不利于这种理想中的方案。要编写一个没有潜在问题的、跨浏览器的、显示美观并且有足够灵活性可以调整的服务器端组件是需要高水平的技能、丰富的经验和较多时间的，即使付出这些成本，也不能完全避免使用者失望的情况。
综合来看，基于请求的框架要程序员
自己动手的地方比较多，但也因此可以更精细地控制HTML、CSS和Javascript这些最终决定
应用程序界面的代码，特别是如果要在界面上有创新，尝试新的视觉效果和用户操作，必然选择基于请求的框架。基于组件的框架可以提高开发界面的效率，前提是选用的组件质量优秀。