javascript - Rails : Not ember, 不是 JS 响应，而是介于两者之间的东西

Question

我正在开发一个标准的 Rails 应用程序，到目前为止我还没有使用任何 AJAX，只是使用了很好的 HTML。我的计划是迭代地添加“远程”链接和所有此类内容以及对 JS 响应的支持，因为我知道生成 JS 服务器端是非常非常邪恶的，但我发现它也非常方便，简单，快速并且它使应用程序足够敏捷，并且 i18n 开箱即用。

使用纯 JSON 方法会更轻，但需要大量客户端编码。

现在想象一下，在此应用程序中，用户有一个邮箱，并且由于他们无需重新加载页面就能够执行大部分甚至所有操作，因此邮箱计数器永远不会改变，除非他们手动刷新页面.

那么，问题来了:处理这个问题的最佳方法是什么？

1. 我考虑过使用 Ember(用于数据绑定(bind))，并通过 ruby​​ 的某种 Handlebars 实现与 Rails 共享 View 。这将是非常棒的，但对于开发人员(我)来说不是很透明。虽然我猜我只需要编写 ember 使用的 Handlebars View ，但其余的仍然可以按原来的格式编写，不是吗？

2. 另一种选择可能是使用某种事件系统(可能是 EventSource？)，并使用方便的 JS View 方法，并监听这些事件。我想这些应该是 JSON 对象，并且客户端必须进行编码才能处理它们。这看起来有点麻烦，我需要一个heroku(faye？)的解决方案，这是我的应用程序的托管位置。有什么提示吗？

我认为 ember 方法是更强大的方法，但似乎也相当复杂，我不想在服务器端和客户端重复自己。

编辑:

我见过this ，这或多或少是选项#2。

Answer 1

使用 JavaScript 框架的优点之一是可以将整个应用程序连接并压缩为一个 JavaScript 文件。如果现代浏览器积极缓存 JavaScript，浏览器将不再需要在初始页面加载后请求这些资源。

使用 JavaScript 框架的另一个优点是它要求您成为自己的 API 的使用者。如果移动应用程序或第三方有可能访问它，那么充实应用程序的 API 供您自己使用可能会减少将来的工作量。

如果您不需要应用程序使用等效的 HTML 响应来响应每个请求，我认为使用 JavaScript 框架是一个令人信服的案例。

如果您的应用程序需要使用等效的 HTML 模板响应每个请求，那么许多好处可能会丧失。 Ember 核心相对强烈地反对支持这种渐进增强的方式。考虑到以这种方式使用 JavaScript 框架的工具相对不稳定且不成熟，我可能倾向于使用选项 2 来完成此任务。