作为一些随机的 Rails 开发人员，并绕过所有那些主干/下划线 javascript 的东西......
Backbone 看起来很有趣，但从功能的角度来看（我的意思是您可以从数据库中获取数据并且可以更新您的页面的方式），我看不出有任何真正好的理由继续前进到骨干网.我是说，相比 RJS 方法 rails 带来的。
有了主干，更多的事情发生在客户端；但除此之外看不出任何根本区别
感谢任何骨干传道者的反馈
【问题讨论】：
标签： ruby-on-rails backbone.js underscore.js rjs
这肯定是一个偏好问题，但这里有一些关于为什么你可能想要使用 Backbone 之类的东西而不是 RJS 之类的东西。
当您只需要返回 $('#post_#{@post.id}').slideUp() 之类的代码时，RJS 非常适合。当您希望后端直接控制前端时。当然，这对许多应用程序来说确实有意义。但是当您开始处理更复杂的内容时：更改帖子标题、更改帖子正文、更改帖子标签、更改“最近发布的帖子”侧边栏中的帖子标题等。这可能很难快速维护。如果您巧妙地更改标记，您可以破坏所有 RJS。此外，使用 RJS，很难更改整个页面 并保持用户理智（例如，您将中断返回按钮并通常踩踏浏览器中的所有状态）。
因此，对于更大/更多的端到端应用程序，您可以使用 Backbone 之类的东西来保持代码井井有条，并将处理数据显示的逻辑移动到客户端。一些好处：
Backbone.View，而不是在 Rails 中可能的多个控制器操作的底部进行更改，这是自然而简单的。collections.js、models.js、views.js，或者对于较小的内容可能是 app.js，或者可能是 @987654329 @, posts_collection.js... 无论您需要什么）... 再次，而不是将 javascript 分散到整个 Rails 中的程序块中。如果您的应用程序非常适合放在单个页面上（例如，页面之间有很多共享元素，例如导航/侧边栏/等），那么它将非常适合 Backbone 之类的应用程序.
您的 Rails 应用可以更像一个 API，任何数量的前端都可以使用 - 用于 Web 的 Backbone 应用程序、iPhone 应用程序等等。
当然也有缺点。您必须至少用 Java(/Coffee)Script 编写应用程序的一些视图/控制器逻辑，并且当您长时间不重新加载页面时，您必须小心，不要导致内存泄漏和 javascript 错误可以杀死你的应用程序。什么时候不是权衡利弊，对吧？
可以在37signals post about Basecamp Next（以及相应的HN discussion）上找到一个使用 Backbone 的高调示例。
如果我可以在这里为您澄清任何事情，请告诉我。
【讨论】：