我正在开发一个具有相当广泛的管理部分的网站。前端非常简单，根本不需要复杂的UI，所以我不打算在那里有太多的客户端代码。
我想在这个阶段弄清楚管理部分在客户端放置了多少逻辑。我正在使用Ruby on Rails - 作为一个极端，我可以完全生成服务器端的管理页面，并使用极轻的客户端代码进行一些基本的增强。在另一个极端，我可以使用像AngularJS这样的框架为admin部分创建单个页面应用程序，通过JSON与服务器通信。
我看到的极端客户端方法的主要缺点是会有一个重要的初始页面加载时间，并且它会在移动设备上感到沉重。我看到的优点是，它在初始加载后响应性更强，并且服务器上的应用程序将纯粹是一个API，并且在需要时可以以其他方式扩展或使用。
我看到this article关于basecamp如何通过最少的客户端代码实现快速响应。当他们谈论他们如何实现速度提升时，他们没有提到他们坚持使用大量服务器端代码的原因。
那么我如何在客户端和服务器端代码之间找到合适的平衡点呢？我真的很感激任何有关这方面的见解，我没有考虑的利弊，以及我可以研究的资源。谢谢！
答案 0 :(得分：5)
这是一个非常有趣的话题，我想很多开发人员都在问自己同样的问题。
首先它真的取决于手头的项目。但是这里有一些可以帮助你做出决定的要点。
如果您的应用程序将具有复杂的用户界面，并且具有大量用户交互（点击，拖动等）并且应该“感觉响应”，更像是桌面应用程序我认为客户端方法是正确的选择。
然而你说：
前端相当简单，根本不需要复杂的UI，所以我不打算在那里有太多的客户端代码。
似乎DHH，因此通过扩展Rails对客户端密集的方法不感兴趣。
你必须记住，Rails起源于Basecamp，最近的功能（在Rails 4中引入：像俄罗斯娃娃缓存和turbo链接）是为Basecamp开发的。如果您查看新版本的UI，可以看到这些功能背后的原因，但并非每个应用程序和用户界面都适合此以文档为中心的模型。因此，从37signals（以及所有与性能相关的数据）中获取令人印象深刻的结果（例如，他们使用的缓存硬件是令人难以置信的，并非每个人都能够负担得起这样的设置）。
还要记住，角度和余烬是相当年轻的项目，并且（特别是ember）正在经历许多（可能破坏）的变化，这可能导致令人沮丧的api修复。
还要问问自己，您更喜欢哪种开发环境？
与在浏览器中调试和编写Javascript相比，具有TDD和RSpec以及快速反馈循环的Ruby / Serverside开发风格。 （尽管像Ember Inspector这样的项目取得了很大的进步并改善了体验。）不要低估这一点，因为你会花很多时间在这些环境中。
就像DHH在他的文章中提到的那样，他们能够通过更传统的服务器端方法获得梦幻般的结果。
我认为如果不为两种体系结构编写相同的应用程序并为每种体系结构执行一些性能测试，就无法获得科学结果。
这当然是一个理想且不切实际的场景，但我也认为它甚至不需要：它归结为用户界面和应用程序的感知速度/性能。如果你有一个“单页”用户界面，用户主要忙于一个页面:)客户端方法可能被认为是“更快”，下载javascript的初始性能将被弥补。< / p>
如果您打算为您的应用程序编写一个好的json API，那么就可以为客户端方法提出一个很好的论据。 eviltrout：
富客户端应用程序的一个惊人的副作用是你最终得到一个经过测试的API。我们的应用程序从第一天开始就使用了我们自己的API，所以我们知道它有效。
您可以关注的人/项目：
David Heinemeier Hansson
http://37signals.com/svn/posts/3090-basecamp-nexts-caching-hardware
Yehuda Katz（Ember / Rails团队）
http://blog.scriptybooks.com/railsconf-2013-keynotes-rails-4-vs-ember-dot-js/
同样，这取决于您正在进行的项目类型。如果它是一个不那么严肃的应用程序，你对新技术和客户端框架如ember和angular很好奇，你想修补它们：我会完全去寻找它。
这是一个非常“热门”的话题，对于未来几年，我对它将如何发挥作用非常感兴趣。希望这有点帮助。