我一直在旁观大家对引擎、组件以及更大插件的热情。这是一种喜忧参半的情感。一方面，我很高兴看到人们如此兴奋，并开始憧憬更宏大、更美好的事物。这是充满激情的体现，非常棒。
另一方面，我认为这些发展基本上就是“高级组件”的另一种说法。你们都知道 我对它们的看法。简而言之，高级组件是个海市蜃楼：当它们变得有趣时，为了适配它们所付出的努力，将比从头开始创建东西还要多。
但是，当我听到“一个引擎依赖于另一个引擎，而另一个引擎又可以被另一个引擎替换”时，我的眉头就会真的竖起来。仅仅是插件依赖就非常接近我认为不适合 Rails 的事物。原因很简单，因为它鼓励了一种我认为不健康的开发风格。
所以，这并不是在抨击引擎或任何同类事物的技术优点或实现。我的担忧在于它们会分散人们的注意力，它们会显得“必要”，进而会将曾经的“Salted Hash Login”的失败提升到一个新的标准化水平。
Rails 的核心在于让简单的事情变得如此容易，以至于你不需要去抽象它们。它在于让创建登录、访问控制、内容管理，所有这些业务逻辑组件变得如此容易，以至于你会珍视自己特定的应用程序解决方案，而不是渴望“那一个真正的登录系统”。
那么，我到底在说什么？是应该停止使用引擎吗？当然不是。但我想说的是，Rails 将继续通过其核心包含的内容传递一个信号，表明这只是一个“附加项目”。它能满足一些人的某些需求，这很棒。但 Rails 的目标是创造一个不需要它们、甚至不强烈期望它们的世界。显然，我们离这个目标还有一段距离。
实现这一目标的一种方式是，在常见模式方面做得更好，以教育新来者。回答“如果引擎和组件不是解决之道，那告诉我该怎么做！”这个问题。所以，这是对所有专家们的呼吁。帮助我们传播好的模式。制作视频、撰写教程、在 #rubyonrails 上帮助新手，回答邮件列表上的请求。
如果你有一个很棒的引擎想法，或者一个普遍的高级组件想法，请思考一下：有没有一种方法可以抽象出更小的功能片段，作为一个独立的插件发布，并附带一个描述如何像该组件那样使用它的模式，而这一切都通过软件实现？我猜想，很多时候你都可以找到这样的方法。
注意：引擎方法的创造者 James Adam 在邮件列表中有一篇 很棒的帖子，讲述了他在公司内部如何使用引擎。这完全是一种很酷的使用方式。高级组件的问题仅在于使它们变得通用。