这是一个非常有趣的话题,我想很多开发人员都在问自己同样的问题。
首先,它真的取决于手头的项目。但这里有一些要点可以帮助您做出决定。
用户界面
如果您的应用程序将具有复杂的用户界面和大量用户交互(单击、拖动等),并且应该“感觉响应”并且更像桌面应用程序,我认为客户端方法是正确的选择。
然而你说:
前端相当简单,根本不需要复杂的 UI,所以我不打算在那里有太多的客户端代码。
Rails 和开发经验
看起来像 DHH,因此通过扩展 Rails 对重客户端的方法并不感兴趣。
您必须记住,Rails 起源于 Basecamp,并且最近的功能(在 Rails 4 中引入:如俄罗斯娃娃缓存和 turbo 链接)是为 Basecamp 开发的。如果您查看新版本的 UI,您可以了解这些功能背后的原因,但并非每个应用程序和用户界面都适合这种以文档为中心的模型。因此,从 37signals(以及所有与性能相关的数据)中获得令人印象深刻的结果,并保留一粒盐(例如,他们使用的缓存硬件令人难以置信,并不是每个人都能负担得起这样的设置)。
还要记住,angular 和 ember 是相当年轻的项目,并且(尤其是 ember)正在经历很多(可能是破坏性的)变化,这可能会导致令人沮丧的 api 修复。
还要问自己,你更喜欢什么开发环境?
与在浏览器中调试和编写 Javascript 相比,具有 TDD 和 RSpec 以及快速反馈循环的 Ruby/Serverside 开发风格。(尽管像 Ember Inspector 这样的项目正在取得很大进展并改善了体验。)不要低估这一点,因为您将在这些环境中花费大量时间。
速度
就像 DHH 在他的文章中提到的那样,他们能够使用更传统的服务器端方法获得出色的结果。
我认为如果不为两种架构编写相同的应用程序并为每种架构进行一些性能测试,您将无法获得科学结果。
这当然是一个理想且不切实际的场景,但我也认为它甚至不需要:它归结为 UI 和应用程序的感知速度/性能。如果您有一个“单页”用户界面,而用户大多忙于一页:) 客户端方法可能会被视为“更快捷”,并且下载 javascript 的初始性能损失将得到弥补。
api
如果您计划为您的应用程序编写一个好的 json API,那么对于客户端方法有一个很好的论据。邪恶的鳟鱼:
富客户端应用程序的一个惊人副作用是您最终会获得经过实战考验的 API。从第一天开始,我们的应用程序就使用了我们自己的 API,所以我们知道它可以工作。
参考/阅读/观看
您可以关注的人员/项目:
同样,这取决于您正在进行什么样的项目。如果它是一个不太严肃的应用程序,并且您对新技术和客户端框架(如 ember 和 Angular)感到好奇,并且您想修补它们:我完全愿意。
目前这是一个非常“热门”的话题,在未来的几年里,我对这一切将如何运作非常感兴趣。希望这有所帮助。