RoR创始人DHH回应状态Web应用之争

只被简单地用作RPC层（不像REST那样有丰富含义的URL）的HTTP放弃以页面为单位的做法，有利于更高级别的组件；

组件比Rails的Partials更加符合DRY（Don't Repeat Yourself，不要重复你自己）原则；

如果CSS 样式单正确，直接写HTML程序的做法比模版文件更灵活，并且不违反神圣的MVC模式。

Avi Bryant 还回答了为什么Seaside采用Smalltalk实现，而不选择Ruby：

对我来说，只有Smalltalk世界能让我振奋、给我力量，在对象技术和动态语言实现上，Smalltalk显然有更深邃和丰富的历史。[……]极限编程、敏捷开发和面向对象编程——所有这些都出自Smalltalk世界。我们如今所使用的重构和IDE的概念，很多也都是出自Smalltalk世界，而且坦白地讲，Smalltalk在这些方面有丰富的经验并且会做得更好。Smalltalk世界的前辈们看起来似乎和这些新技术毫不相关，但如果你向他们询问一个关于ORM的问题，你会发现其实在这方面他们已经研究了20多年。

在这篇访谈中，Mike Pence提到Smalltalk只有有限的用户基础，而且由于Smalltalk语言本身以及开发团体规模较小等原因，都可能导致用户不会涉足Seaside。Avi争辩道：

过去所批评的Strongtalk VM的功能（如垃圾回收或字节码等）现在都在Java VM里发挥作用；

主流面向对象编程语言一年比一年更靠向Smalltalk ；

只要有合适的成员，团体的规模并不是问题。

当被问及Ruby日渐流行的问题时，Avi 指出Ruby缺少一个现代化的虚拟机，并宣称Ruby的虚拟机技术落后Smalltalk虚拟机10到15年以上。但是Avi并没有嘲讽Ruby，而是提倡在Ruby和Smalltalk之间建立一个桥梁：

如果能够看到Ruby使用一些Smalltalk已有的技术来提升性能，使得Ruby更加可用，越来越有进步——那么从Ruby层面来看已经较以往实现了更多的语言特性，所以我也期望Ruby将来能够获得巨大成功。其实我想这也很容易。……Ruby和Smalltalk，在语言层面上其实是一样的，不同的只是类库和语法。如果有人花时间做这件事的话，所有Smalltalk技术将直接可被Ruby所利用。

当然，话题然后转向了JRuby。Avi更加怀疑JRuby的表现，甚至怀疑JRuby是否能长时间运行，因为Java VM对动态语言没有足够的支持。他再次表示了自己对Ruby在针对动态语言设计的虚拟机Strongtalk上运行的支持。作为结论，Avi Bryants重申了他的格言：有其他途径处理这些事情。

为了获得争论中来自Rails一方的观点，InfoQ邀请Ruby on Rails的创始人David Heinemeier Hansson分享了他对Smalltalk、Seaside和Avi Bryant所持观点的看法。

首先，你的Smalltalk 背景如何？你熟悉Avi Bryant所创建的Seaside框架吗？

我只是涉足过Smalltalk，但从来没有用它做过真正的应用。然而我通过阅读一些Smalltalk的著作学习了不少面向对象编程的知识，其中最重要的是Kent Beck 写的最佳实践。

我从一开始就关注Seaside。Avi是一个聪明人，很高兴能够见证他挑战传统的Web 应用方法。但我也没有必要非要以同意Seaside所作的选择来表达对Seaside或是对他的尊敬。

Avi争辩说Smalltalk和Ruby一样丰富且更成熟（如VM）。在你开始打算开发Rails框架时，是不是将Ruby和Smalltalk或其他语言比较之后选用的Ruby？如果是，为什么？

对我来说，Ruby更适合。感觉更像是务实的选择，因为是选择一种已经有的语言而非自己发明一个。从Smalltalk中提取许多好的特性而且不放弃已经掌握的知识，看起来更应该是进化而非变革。

另外，我很喜欢Ruby的美感。我并不是说Smalltalk是一个丑陋的语言。我很尊重Smalltalk。只是它不适合我的大脑，而Ruby正合我意。这也是为什么我们拥有这么多奇妙语言，对不同的人来说某一种语言比其他语言更适合，这也无伤大雅。

在许多方面，我明白Rails与Seaside的关系以及Ruby与Smalltalk的关系。但我仍然认为Rails是一种进化和完善而非变革。

Avi Bryant“放弃”那些含义丰富的URL表达，争辩说HTTP应被用作RPC层，由框架自身来管理。但是他真正的观点是：无状态应用和状态组件模型所提供的模块化特性相比没有优势。很明显在Rails1.2里包含了REST，你认为RoR将会从状态组件模型中受益吗？

我想这取决于你所做应用的类型以及你的期望。我并不期望Web成为现有桌面应用系统的复制品。多数场合我更喜欢Web。因此，我并不认为如果仅仅是把Web做成类似于桌面应用的样子（包括状态组件所关注的），开发Web应用就会变得很快乐。

我对把高层组件看作是很好地应用复用性的说法也不感兴趣。有时高层组件看起来像是开发处于痛苦中时的一种发泄。当无法避免代码复制时，选用Rails就不会让我感到痛苦。

在某些方面这也仅仅是一种不同的构建方法而已，但是这种方法明显地吸引着一些人。这很好。并不是所有人一定要用同样的方式构建Web应用。实际上，如果我们真这样做的话（ 译者注：完全自己构建Web应用）是很愚蠢的。

你是不推荐在高状态应用（highly stateful applications）中使用Rails吗？是否甚至根本不推荐状态，除非考虑性能？

我不认为我们已经有了一个关于什么是“高状态应用”的确切的定义，因此也无法来断定Rails是否适合它。我也经常在Web应用中创建一些有状态的代码片断，但是我选择将状态保存在客户端HTML形式中而非在服务器端Session中。

但是我前面说过，我的理解是Web应用并不次于桌面应用。它们只是不同而已。我并不认为桌面应用是某种理想的解决方案。一旦你停止了这种复杂的自卑情结，你将开始认识到所谓的Web限制只是其本身特性而已。

无疑Rails是Web开发的重大突破，但你是否认为Rails已经为下一个类似桌面的Web用户界面做好了准备？Avi不这么认为，并宣称说应该发生一场革命，以来迎接这些挑战。

再强调一下，这是以如下假设为前提的：所有Web开发者想变为桌面开发者，而且所有Web应用程序只要像桌面系统就是好的应用。我不接受这种假设。我喜欢以Web自身的特点工作。我喜欢HTTP和REST所提供构建模式。

所以在许多方面，我认为把Web雕刻成为类桌面界面是在雕刻过去而非未来。将不同的构建风格区分为过去/将来其实对评估它们的作用并不是非常有帮助。可是它却有助于帮助记者写些大爆料性质的故事，呵呵。

的确，有一些特定类型的应用确实更适合用类似桌面的方式，而且该应用将得益于一个试图将应用带向类似桌面界面的Web应用程序框架。可是，我不认为这是普遍现象。我个人也并不打算为这类应用程序贡献力量。

我只是想通过Rails改进自己开发应用程序的环境。不能保证能适应你的特殊情况。但到目前为止，它看起来似乎适合于相当多的开发者的情况。

然而，我不认为这是个非对即错的问题。Web允许这么多种构建模式已经足够令人惊喜的。尽管我很喜欢HTTP协议和REST方法提供的模式，我并不认为Avi选择另一条途径是错误的做法。他只是用另一种方法将HTTP用作一种底层协议。想不到HTTP居然能被这么用，这是多好的事情啊。

显然David并不担心Rails及当前Web开发模型的未来。他觉得不要怂恿彻底改变。有选择是好事，Avi的观点是受欢迎的。

然而，对于Seaside和Smalltalk来说是否已经太晚了？随着Ruby和Rails很快地流行开来，Ruby得到了像Sun这样大公司的巨大投资和支持。不论Ruby on Smalltalk有多快多好，会有志愿者实现一个SRuby吗？

查看英文原文： DHH Responds to Stateful Web Applications Row 译者简介：宋玮，多年软件开发经验，从2002年开始就使用Java，在各个项目开发过程中先后使用过Struts、Oracle ADF、AspectJ等。最近正在使用Spring及Ruby on Rails，对敏捷方法有比较大的兴趣并做过一些尝试。他的blog为 http://www.donews.net/victorsong。为InfoQ中文站贡献内容，请邮件至 [email protected]。