OperaMasks：勇敢者的新世界vs失落的记忆

Javaeye论坛又谈到红岗同志了：http://www.iteye.com/topic/110484

我就去看了一下OperaMasks的网站，看到了红岗和张勇的《勇敢者的新世界》。以下是我的comment。

看了前面的历史回顾，写得不错，我本对后面的java web framework部分充满希望，不料，第4节居然就寥寥几句，java世界如此多的开源和商业的web framework，居然作者提都未提，只说了servlet/jsp和古老的struts，连ASP.NET的描述也比它多。难道作者认为所有的读者都还停留在2001年？我看读者没有“审美疲劳”，是作者“记忆疲劳”了。

我不相信红岗和张勇你们没有看到过java世界web framework的欣欣向荣，仅仅列入Apache的就有webworks、tapestry、turbine，还有cocoon。也不用说像gwt、echo、dwr、rife、zk等，哪一个不是名声在外，连你们熟知的Spring都有Spring MVC来插一杠子，你们居然全都视而不见？我只能认为你们是有意略过。这就是所谓“选择性失忆”。其他领域我们不说，但对于技术人员来说，这是很不应该的。

然而不谈这些java领域的web framework，不把OperaMasks放在这样一个大舞台上与其他java web framework做做比较，你们就自夸OperaMasks是“from earth to the moon, and ready for Mars”，号称“在技术和思想上傲视群雄”，这就更未免有些可笑了。有自信是好事，但是不幸的是，我们不止一次看到自信沦为自大狂妄甚或无知。OperaMasks是不是也会如此？我不知道，我也不希望如此。

下面谈谈技术。

说老实话，OperaMasks要自夸，首先你要证明JSF技术的先进性。作为一个有超过8年经验的web开发者，我对于Sun官方的JSF，甚至Java社区众多的MVC框架和一些新兴框架，都有着深深的疑虑。众多企图抹平网络编程与桌面编程的鸿沟，企图让开发者完全不用了解B/S原理，企图服务器端掌控一切的所谓“简化”，实际上真的是web开发的方向吗？B/S的请求响应机制，HTTP作为无状态协议等，都是web编程的固有约束（参见著名的REST论文），而以ASP.NET和JSF为代表的技术方向，实际上是在背离和打破这一约束的道路上越走越远。掩盖web编程“复杂性”的“简化”事实上能真正简化问题吗？实际上为了掩盖复杂性，也许底层付出了更大的复杂性的代价。许多框架的前提是，开发者不需要陷入这些plumbing，可能对于许多应用来说确实如此，但是一旦开发者被迫陷入必须处理一些设计者故意忽略的问题，他可能会发现陷入了巨大的困境中。微软的winforms和ASP.NET就是这样一种模式的典型代表，如果默认提供的那些控件够用，一切ok，但是如果你想稍作改变，extends一下，就会发现陷入大麻烦了，只好去买第三方控件。而你去看看那些第三方控件，全部是自行实现的，没有一个是从默认控件继承出来的。而这些第三方控件与默认控件是否能和平共存互相协调呢，很有可能不行，或者是会产生一些奇怪的bug，这全赖于第三方是否对其底层有足够的经验和能力。也就是说，表面的简单，换回的是开发者对于系统内部复杂性的理解力的丧失和自行扩展系统能力的严重下降，开发者对于第三方控件，最终也只能“以貌取人”，面对的风险是极大的。

JSF或者说OperaMasks会不会这样呢？这很难说，但是我不太乐观。因为我深知web客户端编程的复杂性，直接的客户端Ajax开发框架如prototype、dojo、YUI、ext等尚在努力，而服务器端连这一层都要掩盖。掩盖复杂性不是做不到，但是要把这多层复杂性以优雅的方式隐藏起来，并且还能在需要接触内部的时候，优雅的显露出来，简直是mission impossible，到目前为止，我还没有看到成功的。OperaMasks可以吗？存疑。这里有篇blog：http://canonical.iteye.com/blog/106766，对于JSF有这样的结论：“所有问题的一个集中体现就是增加一个新的JSF组件绝对不是一件平凡的事情。”

我们再看看Render kit。说起来只要更换一套render kit，就可以Ajax enabled。理论上似乎可行，但是这很可能只是具有一点Ajax的皮毛效果而已。实际上，开发者丧失了许多控制，特别是架构上的控制。比如JSF能支持REST架构么？不仅是现实中，在理论上就存在困境。因为JSF的语义可能就与REST架构不匹配。

当然对于偶尔做web开发，以java编程为主的开发者来说，JSF是有吸引力，特别对于企业内部应用来说，也有一定实用性的。但是以web开发为主，特别是做大规模web开发的人来说，应该对JSF抱有警惕。因为，这种类型的开发简化，很可能是以各个部分之间的紧耦合为代价的。

我再摘录一段文字：“同样，这个世界还存在许多Ajax Framework，譬如dojo。我们并不否认这些Ajax开发框架的优秀，但是，与它们的优点同样明显的局限之处是：dodo之类的Ajax开发框架仅仅解决了客户端的问题，对任何服务器端逻辑，dojo无能为力。J2EE是一个整体，它不仅需要解决表现层问题，也要解决数据层和逻辑层的问题，JSF 是JavaEE 5.0的一个重要组成部分，这就使得Apusic OperaMasks不仅可以创建丰富的客户端体验，同时可以和JavaEE应用服务器结合，从而建立强大的服务器端逻辑绑定。”

事实上，你们所认为的局限性恰恰可能是我们认为的优点。为什么JavaEE要解决所有问题呢？会不会所谓解决整体的方案，实际上会把问题搞砸呢（最著名的例子是EJB）？如果把JavaEE限制在数据层和逻辑层，以web services（无论SOAP还是Restful的形式）提供出来，而由纯浏览器端技术来解决表现层，是否可能是一种更好的方案呢？比如REST架构所体现出来的松耦合、语义透明性、极高的可伸缩性，纯浏览器端Ajax框架所体现出来的高交互的用户体验、灵活性、以及不依赖於服务器端的互操作性。

对于JSF的忧虑或质疑，不是我个人，而是社区内普遍的声音，像是 What's wrong with JSF 之类的讨论已经不稀奇了，宣称 JSF is dead 甚至 officially dead 也随处可见。国外如此，国内也是如此。

最后，我赞赏OpearMasks的GPL开源和社区路线（但现在要更换协议，令人有点担忧）。Native Ajax支持确实也略有新意。但是这还远远不够，目前为止，说OperaMasks思想和技术有什么领先处，实在无法令人信服。我所看到的只是令人遗憾的选择性失忆。

评论

6 楼 hax 2007-08-12  

以下是某web framework的开发者对JSF和Portlet的批评，摘自http://blog.araneaframework.org/2006/05/03/where-jsf-and-portlets-went-wrong/

In my mind these specifications share the same trouble as the infamous EJBs:

    * They are designed by a committee
    * They are not standardizing something existing, but creating a new solution on paper
    * They are designed largely by and for tool makers, instead of developers

5 楼 lordhong 2007-08-11  

作为开发者, 我们要有鉴定技术适用性的能力.
不同需求的项目选择不同技术的组合...
扯远了... LZ对JSF的分析非常到位, 掩盖复杂性走不了多远的.
有点类似的是RDF和RSS1.0, 纯粹是为了技术而技术, 反而忽略了用户的基本需求.  ATOM和RSS2.0的简洁易用, 元素定义清晰, 马上被大家接收而成为非常流行的标准.  方便实用才素王道.

4 楼 weiqingfei 2007-08-11  

当初就对asp.net的winforms深恶痛绝,所以看到java社区搞了一个什么jsf,就更没什么好印象了.

3 楼 jianfeng008cn 2007-08-11  

不看好jsf 同意hax的观点，以其掩盖不如实现得精巧点

2 楼 jindw 2007-08-11  

商业行为。掩盖什么突出什么完全是商业需要。

可以说他袁红岗没有义务为自己竞争对手免费宣传。
但是这种做法也有点太露骨了。

1 楼 may_cauc 2007-08-11  

我还是蛮相信jsf的，毕竟方便就是好用，开发速度和维护决定一切。
也许我的眼光比较短浅，我也就这点出息。

整天去评估技术的风险还不如踏踏实实的写两行代码试试。