前文提到 Matt Raible 在比较 Java web framework 的时候有一个重要的指标（他将之排在第一个）：
Ajax Support: Is it built-in and easy to use?
与 JavaScript 有关的指标还有一个：
Validation: How easy is it to use and does it support client-side (JavaScript) validation?
我个人却觉得服务器端的框架不应该对 JavaScript/Ajax 如此高度地集成，它们毕竟是客户端的东西。程序员必须有清晰的概念，什么是服务器，什么是客户端，它们之间是怎么交互的。微软的 ASP.NET 做了一个很不好的表率，将 web 开发用 Windows 桌面程序开发的理念来进行，迷惑了不少程序员——就连官方翻译 “Form” 成中文也是“窗体”，真是不伦不类。而程序员需要深究其运行机制的时候，就不得不折腾 POSTBACK 那一坨屎了。Ajax 开始流行之后，微软又不失时机地在 ASP.NET 加入了 Ajax 的控件，广受那些喜欢拖拖拽拽像搭积木一样“编程”的程序员的欢迎——这就是 “The Microsoft way”.
Ajax 从概念上讲是革命性的，但在技术角度上说，了解 JavaScript 再去掌握 Ajax，就好象学会了 Java 再去学集合类怎么用一样简单。Ajax 技术被炒得神乎其神，以至于大家的简历上不得不再加一条“精通 Ajax”，一部分原因可能就是框架的集成使其神秘化，并且使大批程序员不愿或不敢去看它的真实面目。真要问问 Ajax 异步更新的下面是怎么回事，估计 80% 的人不知道。
在 Tapestry 5 解释其 JavaScript 集成的 wiki 页面中，开头就写：
Modern frameworks, and perhaps none more aggressively than RoR, go a long way in removing the pains of JS from developing web applications. Tapestry 5 is no exception and even though it is currently in the beta stages, it has come along way in making JS transparent to developers (not to mention 3rd party libraries like tapestry5-components).
从这段文字可以看出作者对 JS 的集成多么自豪。然而 making JS transparent, 可能吗？当然你以 demo 一下透明是多么的酷，多么炫。不过做一个框架出来不是 demo 用的，而是要为实际环境中的程序做基础。实际应用的时候，用户不可能像 demo 的那样顺利地完成任务，遇到问题的时候还是得去看 JavaScript 怎么执行的，Ajax 是怎么个机制，所以真正的透明是 100% 不可能的。我认为，本来很小很简单的一个技术被集成到 web 框架中，一定程度上增加了调试、调优的难度，得不偿失。
另外，Tapestry 的表单验证做到了一处配置，客户端、服务器双重验证。这一点本来不错，但它用了一种比较花哨的方式来显示错误信息——在出错的字段上冒泡。而且这种方式在某些情况下会出问题。这一定是作者的个人喜好，demo 起来大家一定觉得很酷。但实际使用的时候，很大的概率是这种 UI 与应用环境的 UI 格格不入，你还得想办法 tweak.
框架的目的应该是总结设计模式，减少重复劳动，而不是集大成于一身就好了。从这一点上说我倒是挺喜欢 struts 1.x 的，你完全可以控制作为响应发送到客户端的 HTML 代码。Tapestry 则不然，默认插入的 CSS，表单页面不可避免的 JavaScript……
Matt Raible 的 presentation 中谈到如何选择框架的时候，有一句话 “Eliminate, Don’t Include“，我觉得不仅仅适用于如何选择框架，同样适用于框架的设计者如何选择 feature set.
Leave a Reply