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所蚕食。

有兴趣者参加讨论。

评论

58 楼 leebai 2007-04-26  

Web层框架的下一个王者，如果不是纯Ajax，将是业界的悲哀。


不论Struts还是JSF，还是.net，或者此前的任何主流Web程序，都是在服务器上构造用户界面，而客户端只是单纯显示界面，这种技术架构和早期的字符终端模式本质上是一样的，是原始、落后、丑陋、低效率、混杂的。

之所以这么多年的web程序都是这种模式，是因为：最初HTML是作为“带链接的文档”，而非“交互程序界面”而设计的，为了在HTML下实现“交互程序界面”技术，后来HTML中增加了<Form>，可以实现简单“交互”，再后来又有了javascript，“交互”又进了一步，但Form、javascript的可编程性都太差，所以每次交互都必须由服务器代替客户端来构造下一步的用户界面，客户端只是单纯的显示，这就是“瘦客户”的由来。这里大家应该看出来：Web应用的客户端之所以“瘦”，并不是因为“瘦”好，而是因为早期的浏览器是为HTML而生，先天不足。不管是Struts还是JSF，或者.net，本质上都是为这种先天不足的“弱智型”浏览器而设计的，所以问题就出来的：今天的浏览器还是这么“弱智”吗？

答案是否定的，其实自从1997年IE4推出后，答案已经出来了，只是大部分人没有看出来而已。IE4和此前的浏览器到底有何不同呢？NetScape Navigator真的是因为微软的捆绑政策而被挤垮的吗？真正的答案是：IE4提出了DHTML，是DHTML打败了Navigator。

DHTML为什么有这么大能量？在DHTML之前，DOM只是一个抽象的概念，在浏览器端，编程语言（javascript）和其编程接口（API）是混杂在一起，我们分不清、NetScape也没告诉我们document.write()到底是javascript语言本身还是编程接口。直到如今，很多关于javascript编程的书籍也把javascript语言和编程接口混为一谈，很多程序员还会去javascript语言的函数参考中去找document.write()的资料，这就是NetScape留给我们的技术遗产。IE4的DHTML第一次以微软的方式实现了DOM，将javascript语言和DOM编程接口彻底分开，IE4也成为第一个完整地实现了基于DOM理念（不是DOM标准，但超越当年的DOM标准）的浏览器，无论是功能性、稳定性、可扩展性、可编程性，都完全超越了Navigator，所以IE4想不挤垮Navigator都不可能。我从98年开始涉及Web开发，2000年后专职做Web开发，一直到现在，Web前端开发的主要参考文档还是1997版MSDN Lib中的DHTML参考，10年也没觉过时，这就是核心技术的生命力。


回到主题，再谈Web层的架构。如今，DHTML/DOM已经非常成熟，浏览器的可编程性已经非常好，2005年，业界也“良心发现”似地提出并认可了"Ajax"，所谓的“富客户端”系统（我认为用“中客户端”更合适，即界于胖客户与瘦客户之间）也被追捧。问题是，像Struts、JSF、.net这些由服务器端构造界面的框架是否适合“富客户端”系统？是否有必要在这类架构上修修补补来适应“富客户端”系统？在浏览器功能非常强大的今天，服务器的CPU和内存资源是否还要为早期的“弱智”浏览器背书，或者说继续为一个健康的成年人当保姆？未来的Web架构是否应该继续基于“弱智”前端来设计？


答案当然也是否定的。“富客户端系统”已经和原始的“动态网页”不是一个层次的东西，“富客户端系统”界面的强交互性，使用户界面编程空前复杂，这种客户端的复杂如果由服务器端来解决，只能使问题更加复杂。因此理想的Web层模型应该是：

-----------------------------------
浏览器完全负责界面构造和流转（服务器对界面构造和流转只提供HTML服务，即由www服务器提供静态HTML页面，而不是由应用服务器提供动态页面）；而应用服务器只提供业务服务，即只接受业务请求（http Request的含义与传统不同，服务器不参与界面层功能）。
------------------------------------

在这种新的模型中，应用服务器从界面构造和流转控制的繁重任务中解脱出来，专注于业务服务，MVC的控制器被自然废除，后端只需编写业务服务代码，这也刚好与WebService、SOA的概念吻合。这种模型比Struts、JSF、.net,都要漂亮得多。


最后，总结一下：很多人还认为Ajax只是相当于网页的花边装饰，或者是Web程序的局部效果；在我看来，整个应用都应该基于Ajax构造。可以预测，Ajax+SOA将颠覆传统的Web程序结构，Web应用将走出“服务器动态网页”时代，进入“富客户端”+“面向服务编程”的光明未来。


上面的Web架构理念，我已经做了一个初步实现，有兴趣的朋友可以参考：

http://www.xjawa.org/xjawa/kontent/80039.html

57 楼 wangying1983 2007-04-25  

lordhong 写道

chenqj 写道

支持spring mvc

rod johnson 公开说过。。今后spring web flow是重点。
spring mvc只是在维护阶段，不会有新的更新了。

没看过JSF，本来想学，但听你们这样说，还是不看算了！！！

56 楼 lordhong 2007-04-25  

chenqj 写道

支持spring mvc

rod johnson 公开说过。。今后spring web flow是重点。
spring mvc只是在维护阶段，不会有新的更新了。

55 楼 windfan 2007-04-25  

个人感觉webwork的设计是传统MVS框架中最先进的,不知道转到struts后会不会被带的变了味了,AJAX是传统MVS的颠覆者,但目前来看,还没到完全取代的时候.毕竟JAVA语言的习惯者,并不习惯给人感觉蹩脚JS语言

54 楼 cowoo 2007-04-24  

我也觉得Flex非常非常有前途，再加上后台用Rails的REST的话，帅呆了。

53 楼 netnova 2007-04-24  

Struts2+hibernate很好用.

52 楼 chenqj 2007-04-24  

支持spring mvc

51 楼 lordhong 2007-04-24  

zhlmmc 写道

580K是你的个案，平均来说还是很大的！

很大是因为他们不懂FLEX的优化。

有很多优化的方法，最简单的是SWC。用COMPONENT。动态加载。
你的主FLEX程序大概只要20K，其他都动态下载，别说2MB的东西，20M的FLEX APP都很轻松。

50 楼 zhlmmc 2007-04-24  

lordhong 写道

zhlmmc 写道

你做的企业应用软件，在局域网内，用Flex当然没有问题。但是一到公网上，网速的限制是很大的！而且Flash这个东西不能被搜索引擎索引到，Flex要流行还早

为什么网速有限制？？先不说宽带的普及，我的FLEX APP大概是580K，DOWNLOAD一次就可以了。
和现在动辄200K的网页相比，不算什么。如果用HTML和AJAX实现的话，尺寸肯定是大4倍。而且FLEX传输到SERVER的是纯DATA，用BINARY PROTOCOL，没有HTTP HEADER那么烦琐。
搜索引擎索引的话，现在都是自己写SITEMAP，然后在GOOGLE，YAHOO那里指定SITEMAP文件。

不过从RIA的角度来说，一个互动式的软件，干吗要被搜索引擎索引？

比如说你用的WORD，需要被INDEX吗？ 

FLEX的APP现在对公众发布的也不少，前不久看到一个什么妙句网，慢！
580K是你的个案，平均来说还是很大的！
关于索引，如果你是做网页上的Word之类当然不需要，其他应用就不一定了哦~

49 楼 fzfx88 2007-04-23  

强烈支持Struts，也希望Struts尽快赶上发展的步伐！

48 楼 ahuaxuan 2007-04-23  

jsf如果不好好改改肯定流行不起来，tapestry说不定以后会和wicket合并（猜的），将来的情况可能是两大阵营都只有一个产品，事件驱动的是tapestry和wicket的合并物，请求驱动的是struts3.0（或更高），当然如果jsf改改，不用那么麻烦的标签的话它也可能生存下来，分一杯羹，以上纯属猜测，呵呵

47 楼 fourfire 2007-04-23  

flash

46 楼 cherami 2007-04-23  

PS：如果不出现很好的JSF开发工具的话，估计很难发展起来，NETBEANS毕竟使用得不普遍

45 楼 cherami 2007-04-23  

呵呵，我最看重的是可重用性，目前表现层框架好像tapestry和widget好一点，其它的我都不太看好。

44 楼 liangguanhui 2007-04-23  

Java界就是缺乏VS这样的超强IDE！

43 楼 lordhong 2007-04-23  

zhlmmc 写道

你做的企业应用软件，在局域网内，用Flex当然没有问题。但是一到公网上，网速的限制是很大的！而且Flash这个东西不能被搜索引擎索引到，Flex要流行还早

为什么网速有限制？？先不说宽带的普及，我的FLEX APP大概是580K，DOWNLOAD一次就可以了。
和现在动辄200K的网页相比，不算什么。如果用HTML和AJAX实现的话，尺寸肯定是大4倍。而且FLEX传输到SERVER的是纯DATA，用BINARY PROTOCOL，没有HTTP HEADER那么烦琐。
搜索引擎索引的话，现在都是自己写SITEMAP，然后在GOOGLE，YAHOO那里指定SITEMAP文件。

不过从RIA的角度来说，一个互动式的软件，干吗要被搜索引擎索引？

比如说你用的WORD，需要被INDEX吗？ 

42 楼 zhlmmc 2007-04-22  

lordhong 写道

真正的UI，或者说实现RIA的话，就要望前看，WFP和APOLLO。
STRUTS只不过是个MVC的FRAMEWORK，JSF还是老套的TAG。
用FLEX，结合J2EE服务端，客户端只需要FLASH RUNTIME（基本上大家都有，LINUX版的也出了),通过flex data service(免费)，UI你想怎么做就怎么做，速度比ajax快N倍，特别是传输数据的速度。

本人这段时间做了个flex 2的企业应用软件，20天基本做完前台和后台的所有功能，6月份发表后，再给大家详细说说 ：）

你做的企业应用软件，在局域网内，用Flex当然没有问题。但是一到公网上，网速的限制是很大的！而且Flash这个东西不能被搜索引擎索引到，Flex要流行还早

41 楼 zhlmmc 2007-04-22  

charon 写道

曾经买了一本jsf的中译本"巨著"，粗粗看了一遍就把它撂下了。这玩意儿如果没有合适的ide简直不是人干的。

完全不是这回事~我一年前开发JSF的时候纯手工的，我感觉手工写比IDE快。IDE拖东西真的有很大的限制。
不过我现在对JSF持观望态度，并不看好，太复杂了，那个标签的确很恶心。

40 楼 netfishx 2007-04-22  

现阶段我用struts1.x挺好的，由于很多工作已经交给js在客户端完成了，所以其实对web框架的要求并不高。至于下一阶段，java的地位会怎样还不一定，web框架就更不用说了。

39 楼 charon 2007-04-22  

曾经买了一本jsf的中译本"巨著"，粗粗看了一遍就把它撂下了。这玩意儿如果没有合适的ide简直不是人干的。