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思想和技术有什么领先处，实在无法令人信服。我所看到的只是令人遗憾的选择性失忆。

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

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

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

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

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

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

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

以下是某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

也不要把 jsf 一棒子打死，他还是有很多方便的地方的。至少在理论上还是比较完善的。

我觉得他的主要问题是
1.写个自定义组件太费劲了
2.目前为止没有一个特别完善的 implemetation.

openmasks的视频好吐血，竟然照搬黑客帝国，有版权问题吗？

To lordhong:

RDF和RSS1.0，不能和JSF相提并论。RDF的问题恐怕在于其xml表现过于复杂，另外从学术走向应用的脚步太慢。RSS更是一个复杂的话题。RSS1.0的主要问题在于其用了RDF而不是plain XML。对于RDF的接受度影响了RSS1.0的流行，因为开发者会错误的认为他们必须应付他们不熟悉的RDF。但是RSS1.0本身还是很好的，譬如模块化。RSS2.0从中吸取了不少。Atom的优势在于，它不仅是一个聚合格式，而且也包括API协议。我本人是喜欢Atom和RSS1.0（而不是2.0）的。


顺便再copy一篇对JSF的咆哮：
http://www.theserverside.com/news/thread.tss?thread_id=43899

JSF sucks...and has no hope

Posted by: Leo Lipelis on January 19, 2007 in response to Message #225695

I have some experience with JSF, now using it on my second project.

I will never recommend JSF again.

1. Tremendously and unnecessarily complicated lifecycle. It's required to understand in detail how the lifecycle works to do even relatively simple things (of course you don't need it for an absolutely trivial "hello world" type stuff, but in real life you need to know it for even a moderately easy business app).

2. HORRIBLE, HORRIBLE error messages. Terrible output from the logger. WARNING: blah blah??? what??? What exactly is the problem in human terms? What line of jsp is it happening at? What are suggested fixes? What part of lifecycle is it happening it? What is going???? SEVERE: blah blah can't find row = 0? What is that??? Where? table component? Which one? What line number? Etc.

3. SILENT errors... what the?? If you don't configure h:messages or t:messages, and in some cases even IF you configure them, some errors are subtly and silently swallowed. Is some event listener derailing execution? SHOW ME in the log! What's going on?? Silent validation errors? What is going on?? The default should be SCREAMING LOUD (with line number and suggested fix) error. You should have to configure it to turn it OFF (not to turn it ON).

4. Useless GUI support. We use BEA Workshop and it sucks horribly. All our pages look NOTHING like what we designed them! Tabbed pane renders each tab *below* the next tab. WHAT IS THAT??? That's horrible.

5. verbatim??? subview??? WHAT IS THAT JUNK??? This is 2007 guys, please! WAKE UP. Don't tell me "facelets". I download 1 framework and it should be complete. Don't tell me I need to download 5 other packages from various websites to make it actually useful??? Plus there aren't as many GUI choices for facelets as for JSF.

6. JSP sucks... I've had with JSP ever since 2000, why do I have to come back to it again and again??? (Oh, I know why, because big corps are not always brave enough to jump on something like Wicket or Tapestry...they want the "standard" and something "with a GUI").

7. Implementing a custom component is absurdly complicated. IT SHOULD BE TRIVIAL. GUI should enable and GUI-fy custom components automagically. Welcome to 2007. I shouldn't have to write any additional descriptors, jars, xmls, manifests, and whatnot to make it GUI-fied. That's absurd. Use introspection. Use convention. Use intelligence. Use well thought out design to infer everything that GUI needs to know. Make it trivial to design custom components. I am not saying make it easy. I am saying make it trivial.

8. What is going on with all the magic javascript? I hate it! For example, if I want to submit page on a radio button click, why do I need to use onclick submit() and also use valuechangelistener? What happens if I skip valuechangelistener? What is this not documented? DO NOT GIVE ME A DUMB STEP BY STEP RECIPE on how to do thing... EXPLAIN WHY I NEED TO DO IT LIKE THAT and what will happen if I don't do it exactly like that. Where is all that???

Forget AJAX...the basics are not working in JSF. When JSF can cover the basics, then and only then can we think about AJAX. JSF sucks at its very core. It's poorly designed. It's over-complicated. It's hard or impossible to debug. It has terrible error messages. It's full of magic and weird behaviors (like what the hell is immediate=true? why such a nasty hack is not necessary in any other framework I am aware of?)

I am annoyed. My buddy is constantly pushing me to .NET. I love Java. I want to stay in Java world. But JSF has opened a door for .NET on our team. I detest the developer and user-hostile and arrogant attitude of Microsoft. I can't say I am happy about the whole situation.