Java Web层的下一个王者是谁？

经过数年的“框架大战”，Java界的各种框架找到了自己应有的位置。

Spring+Hibernate+Struts已成为Java开发的主流体系。在这个体系中，Spring+Hibernate的地位应该说短期内是难以撼动了。除了新兴的Jboss Seam作为挑战者之外，几乎难有劲敌。有趣的是当初Spring、Hibernate作为挑战者，将官方的EJB成功挑落马下；这次反倒是官方的EBJ3成了挑战者，不知结局如何。

Java B/S编程中历来战火最激烈的其实还在Web层，框架的数量最多，争议最大。
一切由Struts而起，而Struts最终也坐稳了第一个时代的王座。在技术层面，Struts 1.x已经被无数人抱怨过、批评过，但终于还是稳坐王位，这充分说明了习惯的力量。“稳定压倒一切”，这句话在IT技术领域仍旧适用。
其实IT应用技术，什么新鲜玩意并不难学。难的是标准化和规范化。每个程序员都有自己的思路和习惯，写出来的代码自然是五花八门。Java何以成为编程界的老大，很重要的一点在于Java的规范化。这种规范化很高的语言适用于多人合作的大型项目，便于沟通和理解，也就便于集成和维护。Java世界为什么会框架横飞，说到底还是规范化的需要。纯JSP和Struts写Web谁快，摆明了是JSP。那撑饱了用Struts？原因在于100个人写出来的JSP，有100种写法；而100个人写出来的Struts，基本相似。Struts之成功，正缘于其在Java Web层的规范化方面所做出的贡献。

然而长江后浪推前浪，Struts 1.x的技术缺陷毕竟是隐患。
Sun力推JSF，打算一雪Web层框架缺失之耻。可惜JSF既要沿用Swing的技术路线，又要学ASP.NET，还要照顾产商的IDE，结果搞了个四不象，弄得里外不是人。当然Sun的技术实力毕竟是超强的，只要别重蹈EJB的覆辙，拿出点专断的精神（像这两年的NetBeans），做出像Swing那样水准的东西，JSF当大有作为。JSF现在比较有优势的是对Ajax的集成，这一点走在了其他框架的前面。

而Struts就更没有志气了，把WebWork换了个标签，凑出个Struts2，Bug多多。说实在话，根本不如原版的WebWork。如果不是靠了原先的fans捧场，根本就没得混。不过Struts原本就不是以技术取胜的，靠的是抢占先机带来的习惯优势。如果原先的fans们在这两年内都能转到Struts2，那么Struts二世仍将雄霸天下。

综上所述，未来两年，JSF与Struts将展开Java Web框架的最终战争。
以笔者愚见，结局有二：一是不论Struts还是JSF获胜，Java Web层都将结束混战的局面，这对Java Web开发的标准化是非常有利的，并有助于巩固Java在B/S界的地位；二是Struts1.x、Struts2、JSF三分天下，必然从整体上削弱Java在B/S界的竞争力，并将进一步被RoR、ASP.NET、PHP所蚕食。

有兴趣者参加讨论。

评论

78 楼 smilelee74 2007-04-30  

要是有个框架能实现JSP的继承就好了。
这个应该是能实现的，本来servlet是可以继承的

77 楼 jinlibing 2007-04-30  

java 的东西很多。公司说了算。

76 楼 dlee 2007-04-30  

libai 写道

简单举几条：

1、IE4的事件模型基本完善，事件种类和可发生事件的元素远多于NN4/5。
2、IE4可以真正的动态改变几乎所有的HTML元素，而NN4/5只是用LAYERs模拟出一些简单的动态效果，并非真正的DHTML。
3、IE4的TextRange可控制性远好于NN4/5。
4、IE4独有数据岛绑定元素，这是早期富客户端实现的重要技术之一。
5、IE4的Filters/Transitions效果和可script操作性都比NN4/5强不少。

例子可能没有直观的说服力，你只要将ie4和nn4/5的API Refrence手册摆在一起，数数它们的页数，就可以将它们分出高下了。

IE4对于DHTML的支持更好，这个我同意你的观点，也同意这个是使得Netscape4退出市场的一个非常重要的因素。不过现在争论这些大约10年前的技术已经没有很大的意义。

我反对你的一个观点是，你似乎认为将来Web表现层无论何时都应该前推到浏览器端来做，由浏览器端的JavaScript来完全控制用户的整个工作流程。这种解决方案其实是一类“one-size-fits-all”的解决方案。

我曾经与朋友讨论过，在什么场合下，事件模型必需要放在服务器端来处理？因为WPF和Apollo等RIA技术可以把事件模型完全放在客户端，与用户相关的状态也完全保存在客户端。我们经过讨论之后，认为其实还是有一些场合需要在服务器端处理事件模型的，当然状态也保存在服务器端。所以还是要具体问题具体分析。

另外你的方案完全用JavaScript来控制用户的整个工作流程，假如用户的浏览器不支持JavaScript，整个应用就会完全失效，或者需要对应用的架构做很大的改动。这种情况确实是存在的，前几天在一个活动上我遇到一位朋友，他们就需要用同一套Web应用同时支持桌面电脑的浏览器和各种手机的浏览器。手机中的浏览器仅支持WML，完全不支持JavaScript，更不用说XMLHttpRequest。他们是在服务器端使用Struts+XSLT来解决的这个问题。另外，一些浏览器的插件（例如Firefox有一个插件叫做“NoScript”）会将浏览器对于JavaScript的支持禁止掉。同时支持各种能力不同的浏览器叫做“Graceful Degradation”，做到这一点，可以提供更好的Web可用性。有一种Ajax应用的开发过程叫做Hijax，可以很好地支持“Graceful Degradation”，开发出来的Ajax应用即使在不支持JavaScript的浏览器中也不会影响到基本的功能，只是退化为一个传统的Web应用。这种技术在即将出版的Bulletproof Ajax中文版中有介绍。

75 楼 JJYAO 2007-04-30  

baccc 写道

JSF是事件驱动的、面向组件的WEB层框架，这个思想非常好。问题在于那些专家学者们没有用正确的行为实现优秀的思想。JSF的致命之处在于实现一个企业自己的HTML组件非常困难，门槛较高。你要写一大堆的代码、要修改Tag Lib的定义等等。如果这个你费了九牛二虎之力实现的组件，仅仅是某个客户的特殊要求，不具有复用的价值，那么是非常不值得的。同时，从哲学角度也能得出一个结论：任何一个JSF的实现，都不可能覆盖所有企业在未来开发中的需求。再同时，JSP和JSF具有完全不同的生命周期和处理过程，无法在一个页面中同时使用两个方案（为什么有这个要求：你可以在一个页面中的某个部分用JSF；另外的部分，也就是JSF无法实现的部分，比如一个需要用JSP代码生成的柱状图，用JSP实现）。综上，如果JSF在下面三个方面有一个方面可行，JSF就有生命力：
    1。开发一个个性化组件并部署到应用中，非常容易
    2。某个JSF的实现覆盖了企业未来开发中所有的UI组件需求（实际上，我觉得完全可以通过Template技术做到，但是目前还没有看到此类实现）
    3。在一个页面中，可以混合JSF和JSP编程。
    但是，遗憾的是，一个也不行。

Good!非常同意
抛开低层的技术实现不谈，一个框架的生命力，或者可接受程度很大程度上也取决与如何与现存的技术能够比较平滑的过度
我本人非常期待
1. JSF能与JSP混合编程(可能几乎不可能，JSF tag和JSP tag的生命周期和完成的功能都有很大区别)，使老系统能够比较平滑的过度到JSF
2. MyFace整合和adface后能够统一开源的JSF实现，将tobargo,tomahawk,adface集成在一个实现中,提供更强大的组件类库

74 楼 jwen 2007-04-30  

个人比较喜欢Spring+Hibernate+Struts

73 楼 lixigua 2007-04-30  

baccc 写道

JSF是事件驱动的、面向组件的WEB层框架，这个思想非常好。问题在于那些专家学者们没有用正确的行为实现优秀的思想。JSF的致命之处在于实现一个企业自己的HTML组件非常困难，门槛较高。你要写一大堆的代码、要修改Tag Lib的定义等等。如果这个你费了九牛二虎之力实现的组件，仅仅是某个客户的特殊要求，不具有复用的价值，那么是非常不值得的。同时，从哲学角度也能得出一个结论：任何一个JSF的实现，都不可能覆盖所有企业在未来开发中的需求。再同时，JSP和JSF具有完全不同的生命周期和处理过程，无法在一个页面中同时使用两个方案（为什么有这个要求：你可以在一个页面中的某个部分用JSF；另外的部分，也就是JSF无法实现的部分，比如一个需要用JSP代码生成的柱状图，用JSP实现）。综上，如果JSF在下面三个方面有一个方面可行，JSF就有生命力：
    1。开发一个个性化组件并部署到应用中，非常容易
    2。某个JSF的实现覆盖了企业未来开发中所有的UI组件需求（实际上，我觉得完全可以通过Template技术做到，但是目前还没有看到此类实现）
    3。在一个页面中，可以混合JSF和JSP编程。
    但是，遗憾的是，一个也不行。

1.部署很麻烦吗？ 我不知道麻烦是指什么？ 需要重启？还是什么？
2.JSF也没要求你要自己开发所有的组件阿？如果一个普通的input组件能满足要求，你就用阿，非要自定义吗？
3.什么叫JSP？怎么不能共存了？ 没搞懂？这点实在听不懂了。

72 楼 林秋枫 2007-04-30  

说到事件驱动的、面向组件技术，JSF远远比不上Tapestry4.0.2。
更加比不上Tapestry5.0。Tapestry5.0的组件可以动态加载的。修改之后也不用重启服务器。

71 楼 baccc 2007-04-30  

JSF是事件驱动的、面向组件的WEB层框架，这个思想非常好。问题在于那些专家学者们没有用正确的行为实现优秀的思想。JSF的致命之处在于实现一个企业自己的HTML组件非常困难，门槛较高。你要写一大堆的代码、要修改Tag Lib的定义等等。如果这个你费了九牛二虎之力实现的组件，仅仅是某个客户的特殊要求，不具有复用的价值，那么是非常不值得的。同时，从哲学角度也能得出一个结论：任何一个JSF的实现，都不可能覆盖所有企业在未来开发中的需求。再同时，JSP和JSF具有完全不同的生命周期和处理过程，无法在一个页面中同时使用两个方案（为什么有这个要求：你可以在一个页面中的某个部分用JSF；另外的部分，也就是JSF无法实现的部分，比如一个需要用JSP代码生成的柱状图，用JSP实现）。综上，如果JSF在下面三个方面有一个方面可行，JSF就有生命力：
    1。开发一个个性化组件并部署到应用中，非常容易
    2。某个JSF的实现覆盖了企业未来开发中所有的UI组件需求（实际上，我觉得完全可以通过Template技术做到，但是目前还没有看到此类实现）
    3。在一个页面中，可以混合JSF和JSP编程。
    但是，遗憾的是，一个也不行。

70 楼 huangyou 2007-04-29  

jsf思想是不错，不过标签跟美工结合不起来
出错时不容易定位

69 楼 xly_971223 2007-04-29  

认识一个新事务的过程是  接受--->学习--->深入--->发现缺点--->排斥
而不是从一开始就排斥

68 楼 lixigua 2007-04-29  

jsf,我经历了强烈排斥到喜爱。
正是他的服务器端模型，给我的开发带来了意想不到的效果。
对于他的事件模型，我以为JSF做的很漂亮，还有他的ManageBean也做的相当不错。很多新人不要被误导了，有大牛说Jsf不好，然后就决定不学了。根据你的项目情况考虑，是否选用JSF。
由于我的产品在研发阶段，在实际使用的时候，所以我只能做未来可能情况考虑：针对如果是业务复杂的问题，充分利用JSF的事件模型处理问题，针对主要问题是复杂界面的问题，在明确用Jsf会带来麻烦的时候不排斥使用Struts2.0等其他MVC框架。

67 楼 leebai 2007-04-29  

stone 写道

我讨厌jsp，taglib，因为它使得web开发变得混乱无序；
我不反对ajax，但是看到那一堆堆的js我就头皮发麻；
我喜欢java，喜欢wicket、tapestry，喜欢html、css

看到js头皮发麻是因为它没有IDE；让你不用IDE而用notepad写java，更会头皮发麻的，呵呵。

66 楼 leebai 2007-04-29  

dlee 写道

leebai 写道

IE4的DHTML第一次以微软的方式实现了DOM，将javascript语言和DOM编程接口彻底分开，IE4也成为第一个完整地实现了基于DOM理念（不是DOM标准，但超越当年的DOM标准）的浏览器，无论是功能性、稳定性、可扩展性、可编程性，都完全超越了Navigator，所以IE4想不挤垮Navigator都不可能。

这个观点是错误的。DHTML的概念是IE4提出来的没有错，但是Navigator4在功能性、可扩展性、可编程性上并不比IE4差。基本上IE4能够实现的动态效果，Navigator4都能够实现。但是它们采用的是完全不同的页面对象模型和事件模型，因此需要开发两套完全不同的代码。至于说到稳定性，它们也是半斤八两，都很不稳定。你可能当时在国内只需要为IE4做开发，我以前做DHTML开发，老板的要求是必需在IE4和Navigator4上实现几乎完全相同的动态效果。

IE4和Navigator4是浏览器大战时代的典型代表，它们都严重偏离了W3C的DOM规范。正是因为它们这样做，才使得DHTML开发被大多数服务器端的开发者看作是一种不登大雅之堂的hack，甚至声名狼藉。而Web前端的JavaScript开发者一直饱受歧视，做了大量的工作却得不到应有的待遇。一直到了2001年IE6和Mozilla1.0（基于几乎完全重新开发的代码）推出后，它们才算真正走上了正路。

IE4在支持DHTML方面，确实比Navigator4更早，并且也因此抢夺到了一些市场份额，但是IE最终战胜Navigator，主要的原因还是M$的捆绑策略和对于桌面领域的垄断。M$钱多，可以跟你拼出血。你拼不过，自然就出局了，事情就是这么简单。

看得出来dlee兄也这方面的老手，呵呵，不过你可能把NN4/5和后来的N6搞混了。

我确实没有专门做过NN4的开发，dlee兄说对了。

但是我曾经认真对比过IE4与NN4/5之间的DHTML差别，其实NN4/5与IE4的差距还是很明显的。IE4的很多可编程特性，NN4/5是不具备的，甚至连N6也只是接近IE4的可编程水平，所以IE4的技术水平至少领先NN4两到三年，从ie4推出到现在的ie7，在DHTML/DOM上，其实核心技术基本没有变化，新增的API很少。

简单举几条：

1、IE4的事件模型基本完善，事件种类和可发生事件的元素远多于NN4/5。
2、IE4可以真正的动态改变几乎所有的HTML元素，而NN4/5只是用LAYERs模拟出一些简单的动态效果，并非真正的DHTML。
3、IE4的TextRange可控制性远好于NN4/5。
4、IE4独有数据岛绑定元素，这是早期富客户端实现的重要技术之一。
5、IE4的Filters/Transitions效果和可script操作性都比NN4/5强不少。


例子可能没有直观的说服力，你只要将ie4和nn4/5的API Refrence手册摆在一起，数数它们的页数，就可以将它们分出高下了。

总而言之，说IE4在10年前就奠定了现在ajax流行的基础，一点都不过份。

windows捆绑浏览器在ie4之前早就开始，但所取得的市场份额很有限，ie4发布前还不到18%；只是到了ie4推出后，不到一年就超越netscape成为霸主，这绝对不单纯是市场手段的原因，我是从Netscape1开始用浏览器的(从来没花钱买)，很清楚自己为什么后来要改用IE;厂家之间的争纷是它们之间的事，作为用户，还微软这个公道还是要的。

65 楼 stone 2007-04-29  

我讨厌jsp，taglib，因为它使得web开发变得混乱无序；
我不反对ajax，但是看到那一堆堆的js我就头皮发麻；
我喜欢java，喜欢wicket、tapestry，喜欢html、css

64 楼 javadev 2007-04-29  

一个框架的发展制约因素颇多，就像JDO和Hibernate一样，一切都难以预料。

63 楼 javadev 2007-04-29  

struts我还是比较看好的，它的子项目shale使用jsf实现的。

62 楼 manmoon 2007-04-28  

晕~~~不用停留在技术层面
如果客户说spring好，我马上就用，都紧紧是个框架而已
这么讨论没什么意思。

61 楼 winterwolf 2007-04-28  

Java Web层的下一个王者是谁？

java web层能当王者吗 ?

理想的搭配
WS --> xquery xslt

cilent ---> xmlhttp xform svg

? ---> cocoon ops xmlpipeline

60 楼 dlee 2007-04-28  

leebai 写道

IE4的DHTML第一次以微软的方式实现了DOM，将javascript语言和DOM编程接口彻底分开，IE4也成为第一个完整地实现了基于DOM理念（不是DOM标准，但超越当年的DOM标准）的浏览器，无论是功能性、稳定性、可扩展性、可编程性，都完全超越了Navigator，所以IE4想不挤垮Navigator都不可能。

这个观点是错误的。DHTML的概念是IE4提出来的没有错，但是Navigator4在功能性、可扩展性、可编程性上并不比IE4差。基本上IE4能够实现的动态效果，Navigator4都能够实现。但是它们采用的是完全不同的页面对象模型和事件模型，因此需要开发两套完全不同的代码。至于说到稳定性，它们也是半斤八两，都很不稳定。你可能当时在国内只需要为IE4做开发，我以前做DHTML开发，老板的要求是必需在IE4和Navigator4上实现几乎完全相同的动态效果。

IE4和Navigator4是浏览器大战时代的典型代表，它们都严重偏离了W3C的DOM规范。正是因为它们这样做，才使得DHTML开发被大多数服务器端的开发者看作是一种不登大雅之堂的hack，甚至声名狼藉。而Web前端的JavaScript开发者一直饱受歧视，做了大量的工作却得不到应有的待遇。一直到了2001年IE6和Mozilla1.0（基于几乎完全重新开发的代码）推出后，它们才算真正走上了正路。

IE4在支持DHTML方面，确实比Navigator4更早，并且也因此抢夺到了一些市场份额，但是IE最终战胜Navigator，主要的原因还是M$的捆绑策略和对于桌面领域的垄断。M$钱多，可以跟你拼出血。你拼不过，自然就出局了，事情就是这么简单。

59 楼 lindongxiao 2007-04-28  

spring 的MVC也不差，至少比struts好