做一些随机的rails开发，绕过所有那些主干网/下划线javascript的东西…
主干网似乎很有趣，但从功能的角度来看（我的意思是，你可以从数据库中获取数据，并且你的页面可以更新），我看不出有任何真正好的理由可以继续使用主干网。我的意思是，相比于RJS接近轨道带来的。
有了主干网，客户端会发生更多的事情；但除了这个事实之外，看不到任何根本的区别
任何骨干传道者的反馈都赞赏
这肯定是一个偏好问题，但这里有一些关于为什么你可能想使用Backbone之类的东西而不是RJS之类的东西的漫无边际的内容。
当您只需要返回$('#post_#{@post.id}').slideUp()之类的代码时，RJS非常适合。当您希望后端直接控制前端时。当然，这对很多应用程序来说都是有意义的。但当你开始处理更复杂的事情时：更改帖子标题、更改帖子正文、更改帖子标签、更改"最近帖子"侧边栏中的帖子标题等。这可能很难快速维护。如果您巧妙地更改标记，您可以破坏所有的RJS。此外，使用RJS，很难更改整个页面并保持用户的理智（例如，你会打断按钮，通常会在浏览器中踩踏整个状态）。
因此，对于更大/更端到端的应用程序，您可以建立类似Backbone的方法来保持代码的组织，并将处理数据显示的逻辑转移到客户端。一些好处：
- 您将减少服务器上的负载，因为客户端将执行大量渲染工作
- 您更改了客户端模板中的一些标记，如果要进行更改，那么修改相应的
Backbone.View是自然而简单的，而不是在Rails中潜在的几个控制器操作的底部 - 您可以轻松地处理多个页面/状态之间的导航，并将该逻辑保留在客户端上
- 严格地将您的javascript组织成对您的应用程序有意义的东西是非常容易和低门槛的（例如，
collections.js、models.js、views.js，或者对于较小的东西可能是app.js，或者post_view.js、posts_collection.js……无论您需要什么）。。。而不是让javascript在整个Rails中扩展到过程块中
如果你有一个应用程序非常适合在一个页面上（例如，页面之间有很多共享元素，如导航/边栏等），那么它将非常适合像Backbone这样的应用程序。
你的Rails应用程序可以更像一个API，任何数量的前端都可以使用它-用于网络的Backbone应用程序，iPhone应用程序，等等
当然也有负面影响。你必须用Java（/Coffee）Script至少编写一些应用程序的视图/控制器逻辑，当你长时间不重新加载页面时，你必须小心，不要导致内存泄漏和javascript错误，这可能会杀死你的应用程序。什么时候不是关于权衡，对吧？
在这篇关于Basecamp Next的37signals帖子（以及相应的HN讨论）中，可以找到一个引人注目的例子，即某人不使用Backbone，否则可能会被认为是一个好主意。
如果我能为你澄清任何事情，请告诉我。