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

在 Giles Bowkett 发表质疑“Ruby on Rails 是一种真正的创新技术”的

文章之后，Mike Pence 发表了采访

访谈记录，解释了Avi 是如何在获得

Apple 公司 WebObjects 的丰富体验后，提出关于 Web 开发的状态组件模型方法的。按照 Avi 所述，当前的 Web 开发工具，包括 Ruby on Rails 并没有为未来的类似桌面（Desktop-like）的 Web 应用做好准备。Seaside 框架所做的三个设计选择证明了这种模型提升了模块化特性，也提高了可复用性和可维护性：

只被简单地用作 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 中文站贡献内容，请邮件至 china-editorial@infoq.com 。