web层框架分为rich client和thin client两类思路，下面分别分析：

一、rich client

rich client的关注者有很多，例如dlee、gigix、quake。

dlee支持xmlhttp，gigix的blog上看到他准备写一个“return of rich client”，似乎有支持的倾向，quake比较关注flex。

当前rich client框架解决方案主要有几类，一类是xmlhttp的解决方案，一类是基于javascript的解决方案，例如bindow，一类是flex之 类的方案，还有一些用java web start的。我可以这样断定，当前的这些rich client没有一个有希望成为主流web解决方案！

当前的rich client方案具有如下的缺点：

1、技术过于复杂，实现很不容易

2、不能单独构成一个完整的解决方案，还需要其他很多技术配合完成

这样就算你掌握了这种技术，仍然不能够把整个web层做出来，还需要掌握其他很多相配合的技术，然后整合一个web层的完整框架出来。

dlee公司做了那么久积累，自己公司已经形成了完善的围绕xmlhttp的web层框架了，但是其他公司没有办法模仿出来，现在也没有人做一个完 善的xmlhttp框架出来给大家用，不是每一个公司都肯下功夫自己去钻研和围绕xmlhttp去建立一个框架，并且这种框架也可能并不完全通用。

综上所述，当前的rich client框架更适合于特定的公司围绕该技术形成了自己独特的web层解决方案，而没有可能成为行业的主流web框架。

这里有一个例外，有人提到longhorn的xaml，我承认我也看好这个东西，不过longhorn要2006年才出来，普及还需要至少两年(不 要忘记2001年windowsxp出来，到现在windowsxp的普及率只有30%)，最乐观估计，xaml的普及也要到4-5年之后了。至于那个时 候xaml是否真的成功，还是未知数，不要忘记ms的hailstorm失败之惨。

二、thin client

thin client中流派也特别多，各种各样的框架，我都眼花缭乱了。有struts，webwork2，velocity，jsf，jstl， turbine，tapestry，。。。。。。这许多thin client框架中，我没有一个熟悉的，除了struts之外，全部没有用过。所以且容忍我的厥辞和错误。

首先谈谈我唯一用过的struts。我非常反感struts，反感struts僵化的actionform，反感struts的死板的mvc结构，当然最反感的是struts的taglib！特别是html tag，这东西一用上，dw里面打开什么都看不到。

接着说webwork2，这东西现在很多人对它好评，我简单看了看介绍，看起来似乎是和struts一类的框架，只不过各个方面都全面的改良。

其他的我就更加不熟悉了，不过他们有一个共同的地方，就是统统喜欢用taglib，而taglib是我最讨厌，最反感的东西。

我认为jsp里面使用tag，就是一个错误！我反对在jsp里面使用tag，我推荐大家在jsp里面写java代码，没错，就是在jsp里面写java代码，我就是一直这么干！

很多人可能要跳起来批评我的反动了，我承认我的观点是让太多人不可思议，仿佛是历史潮流的倒退。但是我请大家想想看，jsp本质上是什么东西？

jsp是嵌入式脚本，是服务器端页面编程语言，没错，就是脚本语言，是页面编程，就是要你嵌入代码的。jsp为什么要出现，php为什么要出现，就是因为在页面里面嵌入代码很方便，开发方便，调试方便，连美工做页面都方便。

为什么php这么流行？就是因为在页面里面嵌入代码简单，开发非常简单！而且在dw里面，你写代码完全不影响美工调整页面，可以很好的分工。美工也不会吃饱了撑的去动你用<>括起来的代码段。虽然在一个文件里面，大家分工良好，合作愉快。

而且调试还很方便， 你随便一个out.println(..)，然后刷一下页面，看看浏览器页面上有什么结果，多方便。

然后看看jsp的tag给我们带来了什么，nightmare ！美工mm用dw打开页面，看到的是一片空白，或者支离破碎的页面，她就纳闷为什么看起来好好的页面怎么就这样子呢？不应该啊！而我们的程序员gg也很努力的写着让美工mm看起来似乎很亲切的仿佛想html一样的tag，而不得不努力在后台做着tag的映射xml文件和编写麻烦的tag程序，极大的增加了jsp页面的调试难度，结果却是被mm扁。

有人说了，很多页面显示的重复性工作，你用tag可以节省页面代码量，那我写java class不一样吗，然后你在jsp里面调用java class好了，tag本质上就是java class，有什么区别，就是调用形式不同而已。还生搬硬造了一套既不讨好美工mm的，又让程序员gg别扭的tag语法，此语法还四不像，好像像 html，又不像，好像像java bean，可也不对味。最过分的是每个web框架还自己搞一套taglib，jsp2.0还增加更多的taglib，我看除了把我们的程序员gg当猴耍之 外，没有任何好处。

如果taglib真能实现页面和代码分离的话，他还总算有点可取之处，然而它根本没有做到，你仍然不得不在jsp里面去写点java代码，你仍然不 得不在tag程序里面写点out.println(...)，来输出页面内容，既然你做不到分离，那么藕断丝连的，何必矫揉造作的分开呢？增加了我们程序 员gg的负担不说，还让我们的美工mm在dw里面面对一些支离破碎的页面无从下手。taglib，你罪莫大焉！

从sun在jsp里面引入taglib，我就认为他是一个谎言！我认为大家都被sun欺骗了，我做jsp编程，但凡我写过的jsp，我从来不用 tag，我觉得写java代码让我很舒服，我不需要再去学习那别扭而无意义的tag语法，来增加我的工作量，来增加我的jsp页面调试难度。

因此，一切采用taglib的web框架，被我毫不留情的排除！然后我的目光落在了一个叫做tapestry的东东上。然后我发现这东东有点像去年 的此时的hibernate，仿佛一个地下幽灵，很多人都开始悄悄的讨论他了，并且得到了广泛的好评，但是还没有真正走上台面来被广泛的应用。据说 tapestry真正实现了页面和代码的分离，并且把oo编程执著的贯彻到了web层。

dotnet的webforms一出来，让我们大家见识到页面的事件驱动编程模型，算了开阔了思路了，然而webforms频繁的服务端交互也让人 很烦躁，webforms也是用tag方式来定义服务器端组件，通过hidden 域和服务器交互，不适合internet，只不过ms自己的工具frontpage自家可以读出来这样的tag，所以webforms还是在用tag，但 是他向我们证明了一点，oo是可以贯彻到web层的。

我想要的就是一个可以页面和代码完全分离，不需要使用tag的web框架，能够oo当然最好，我似乎隐约的预感到tapestry是我心目当中真正要的web框架，他有成为web框架主流的可能性吗？我不知道，但我已经对它产生了兴趣，我要研究研究它了。

噢，对了，还有一个jsf，sun的jsf，不过我眼中已经没有sun了，这几年来，sun都干了些什么？就像我们不能指望jdo2.0一样，我们同样不能指望jsf。