在Ruby on Rails中实现Seaside？

Ruby on Rails为什么成为最炙手可热的Web框架？到底是因为它引入了许多全新的革命性理念？或者仅仅是因为它为早已众所周知的设计实践带来更为优秀的实现？这正是Giles Bowkett所问的第一个问题。他通过比较了Rails的视图/控制器模式和Seaside的组件及渲染方法，向大家阐述了自己的想法。将Rails的视图/控制器替换成与Seaside更为相似的方式，是否值得呢？

Giles着重指出这种架构的优点（如集中管理）和缺点（如毫无意义的URL）：

难道你不能模拟Seaside的组件化模式么？你可以把Rails的控制器和视图替换成包含带内建渲染方法（built-in render methods）对象的Builder模板，而那些内建的渲染方法可以调用其它Builder模板。这当然行得通，事实上，你基本能实现除了Continuations之外的所有东西。但问题是，如果你没有Seaside的Session管理，这样做是否值得？而且在除了Smalltalk之外的语言中Session管理会不会变成一场噩梦？这里的观点是，Rails的模板系统是一个又大又臃肿又臭气熏人的大洋葱。最后，事实上我们为Seaside风格的开发提出了一个可能比Rails更好的设计方案，而且保留所有Ruby强于Squeak的优点——更简便的DB/Unix集成，更多开发人员，等等。

文章收到不少评论，其中Assaf Arkin友善地指出如何使用Rails中的capture()方法来实现无模板的解决方案。而Bram法则（Bram's Law）表示担心：如果一个软件越容易编写，那么实际上它会被实现得越糟糕。

……这正是我一直以来担心在Rails上发生的：在五年或者十年以后，你能找到的最差的工作将会是Rails的工作——你在维护一些非程序员写的代码，这些人发现Rails使得编程变得如此之简单，以至于他们根本不用知道他们在做些什么。