ruby-on-rails-3 - Rails vs Backbone：谁应该负责模板和视图？

Question

作为练习，我打算用 Backbone.js 替换 Rails 应用程序的所有前端。该计划的一部分包括重新设计所有内容，直至 CSS。

我正在努力解决的问题是委派模板和视图的责任。

完全在 Backbone 中实现新的前端有什么好处，因此只使用 Rails 作为 API？

在处理应用程序的 HTML 元素时，如何在 Rails 和 Backbone 之间取得适当的平衡？

Answer 1

因为似乎没有人会对此发表答案，所以我将提供我的两分钱作为一个观点（我已经在其他地方写过关于如何让 rails 和backbone.js 一起工作的问题：rails和骨干一起工作）。

在这种情况下，大多数人倾向于完全放弃 rails 视图并将所有内容迁移到backbone.js。

这就是我在我现在正在做的一个项目中所做的。

这是事件的自然过程，特别是一旦您开始习惯使用backbone.js 和结构化javascript 可以做的所有复杂有趣的事情，就很难回头实现标准的无状态HTML 页面。

正如我在上面链接的其他答案中提到的那样；然而，完全放弃 HTML 视图和无状态层是有代价的。就我而言，我打算GET仅在应用程序达到一定功能级别后，才为未启用 js 的浏览器添加纯 HTML 页面。除非用户启用了 javascript（或者除非他们想通过 JSON API），否则我们不会支持POST或请求。PUT

这就是我达成的平衡：用于访问数据的无状态 HTML（无 JS），但需要 JS 来发布/更改数据。您的选择将根据您的用例和目标用户而有所不同。

我要提到的另一件事是，如果您已经在项目中使用 rails HTML 视图已有一段时间了，您可能对切换到backbone.js 所需的初始开销毫无准备。这不仅仅是将 HAML 替换为 ERB：您正在从无状态前端迁移到有状态前端，这可能是一个巨大的变化（取决于应用程序的复杂性）。我自己对这种变化的深度有点措手不及，并且在进行切换后让我们的应用程序回到正轨之前必须做很多事情。而且我们很早就进行了转换，已经具备了最少的功能。

无论如何只是一些想法，希望他们有所帮助。