骨干与RJS

Question

作为一些随机轨开发，并让周围所有的骨干/ JavaScript的强调的东西... ...

骨干看起来有趣，但在功能上来看（我的意思是，您就可以得到您的数据备份从数据库和你的网页可以更新），我看不到有任何真正的理由向骨干迈进。我说的是，与轨道带来的RJS方法相比。

随着骨干，更多的事情发生在客户端;但不能看到，除了这个事实的任何根本区别

任何骨干，传道者的反馈赞赏

Answer 1

这肯定将是偏好的问题，但这里的一些散漫的，为什么你会想要去的东西，如骨干像RJS的东西。

RJS是伟大的，当你只需要像$('#post_#{@post.id}').slideUp()或类似的东西返回代码。当您希望后端直接控制前端时。当然，这确实对很多应用程序都有意义。但是当你开始进入更复杂的东西时：更改帖子标题，更改帖子正文，更改帖子标签，更改“最近的帖子”侧栏中的帖子标题等，这很难保持快速。如果你巧妙地改变标记，你可以打破所有的RJS。此外，使用RJS，这是非常难以改变整页和保持用户理智（例如，你会打破后退按钮一般都踩在状态在浏览器中）。

因此，对于更大/更多的端到端应用程序，您可以创建类似Backbone的东西来保持代码的组织性，并移动逻辑以处理数据向客户端的显示。一些好处：

• 由于客户端将执行大量渲染工作，因此您的服务器负载较轻。
• 您更改客户端模板一些标记，如果有变化，使那里，而不是在Rails中潜在的一些控制措施的底部是自然而简单修改相应的Backbone.View。
• 您可以轻松处理多页/状态之间的导航，并保持该逻辑的客户端上。
• 它很容易和低门槛，严格组织你的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错误可以杀死你的应用。何时不是权衡，对吧？

使用时骨干原本可能被认为是一个好主意，可以在这个37signals post about Basecamp Next发现有人不的高调例子（以及相应的HN discussion）。

让我知道如果我能为你在这里澄清什么。