javascript - 服务器端处理与客户端处理+ ajax？

Question

寻找一些一般性建议和/或想法...

我正在创建我认为更像是一个 Web 应用程序而不是网页的东西，因为我希望它像一个 Gmail 应用程序，您可以让页面整天保持打开状态，同时将更新“推送”到页面(对于感兴趣的人，我正在使用 cometd 编程技术)。我以前从未创建过包含如此丰富的 ajax 和 javascript 的网页(我现在是 jquery 的 super 粉丝)。正因为如此，当我一次又一次地实现一个新功能时，需要在服务器需要知道的 UI 中进行动态更改，我面临着同样的问题:

1) 我是否应该使用 javascript 在客户端上完成所有处理并尽可能少地通过 ajax 回发要么2) 我应该通过 ajax 向服务器发送请求，让服务器进行所有处理，然后发回新的 html。然后在 ajax 响应中我用新的 HTML 做了一个简单的赋值

我一直倾向于始终遵循#1。我想这个网络应用程序可能会与所有 ajax 请求变得非常健谈。我的想法是尽可能减少请求和响应的大小，并依靠不断改进的 javascript 引擎来完成尽可能多的处理和 UI 更新。我发现使用 jquery 我可以在客户端做很多以前无法轻松完成的事情。我的 javascript 代码实际上比我的服务器端代码更大更复杂。我还需要执行一些简单的计算，我也已将其推送到客户端。

我想我的主要问题是，我们是否应该始终尽可能争取客户端处理而不是服务器端处理？我一直觉得服务器处理的可扩展性/性能越少越好。让客户端处理器的能力完成所有艰苦的工作(如果可能)。

想法？

Answer 1

在决定应该在服务器端还是客户端构建由 ajax 请求创建的新 HTML 片段时，有几个考虑因素。需要考虑的一些事项:

• 表现。你的服务器要做的工作是你应该关心的。通过在客户端做更多的处理，你可以减少服务器的工作量，并加快速度。例如，如果服务器可以发送一小段 JSON 而不是巨大的 HTML 片段，那么让客户端来做会更有效率。在以任何一种方式发送少量数据的情况下，差异可能可以忽略不计。

• 可读性。在 JavaScript 中生成标记的缺点是代码更难阅读和维护。在语法着色设置为 JavaScript 的文本编辑器中，在带引号的字符串中嵌入 HTML 很难看，而且会增加编辑难度。

• 分离数据、表示和行为。就可读性而言，在 JavaScript 中包含 HTML 片段对于代码组织没有多大意义。 HTML 模板应该处理标记，而 JavaScript 应该单独处理应用程序的行为。插入到页面中的 HTML 片段的内容与您的 JavaScript 代码无关，只与它插入的位置、插入时间有关。

在处理 ajax 响应时，出于我上面提到的可读性和代码组织原因，我倾向于更倾向于从服务器返回 HTML 片段。当然，这完全取决于您的应用程序的工作方式、ajax 响应的处理强度以及应用程序获得的流量。如果服务器必须在生成这些响应时做大量工作并造成瓶颈，那么将工作推给客户端并放弃其他考虑可能更重要。