Rails：不是ember，不是JS响应，而是介于两者之间

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

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

现在想象一下，在这个应用程序中，用户有一个邮箱，并且由于他们可以在不重新加载页面的情况下完成大部分甚至所有操作，因此邮箱计数器永远不会更改，除非他们手动刷新页面。

所以，问题出现了：哪种方法最好？

我想过使用Ember（用于数据绑定），并通过某种用于ruby的把手实现与rails共享视图。这对于开发人员来说非常棒，但不是很透明（我）。虽然我猜我只需要编写将由ember使用的把手视图，其余的仍然可以用原始格式编写，不是吗？
另一个选择可能是使用某种事件系统（可能是EventSource？），并且只是方便地使用JS视图方法，并听取这些事件。我想这些应该是JSON对象，并且必须对客户端进行编码才能处理它们。这看起来有点麻烦，我需要一个heroku（faye？）的解决方案，这是我的应用程序托管的地方。任何提示？

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

编辑：

我已经看到了这个，或多或少是选项＃2。

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

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

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

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