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

Question

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

我正在创建我认为更像是一个Web应用程序然后是网页，因为我打算像gmail应用程序一样，让页面全天开放，同时将更新“推送”到页面（感兴趣的是我使用的是彗星编程技术）。我之前从未创建过一个网页，因为它在ajax和javascript中非常丰富（我现在是jquery的忠实粉丝）。因此，一次又一次，当我实现一个需要动态更改服务器需要知道的UI的新功能时，我面临着同样的问题：

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

我一直倾向于遵循＃1。我想这个网络应用程序可能会对所有ajax请求非常健谈。我的想法是尽可能减少请求和响应的大小，并依靠不断改进的javascript引擎来尽可能多地处理和UI更新。我用jquery发现我可以在客户端做很多事情，以前我不可能做到这么多。我的javascript代码实际上比我的服务器代码更大，更复杂。还有我需要执行的简单calulcations，我也在客户端推送它。

我想我的主要问题是，我们是否应该尽可能地争取客户端处理服务器端处理？我一直觉得服务器必须处理的可扩展性/性能越低越好。让客户端处理器的功能完成所有艰苦的工作（如果可能的话）。

想法？

Answer 1

我同意你的看法。尽可能多地推送给用户，但不要太多。如果您的应用程序速度变慢甚至更糟，则会导致浏览器崩溃。

我的建议是在开启一整天时实际测试应用程序的行为方式。检查没有内存泄漏。在使用应用程序一段时间之后检查是否每半秒创建一个ajax请求（JS中的计时器有时会很痛苦）。

除此之外，永远不要使用javascript执行用户输入验证。始终在服务器上复制它。

修改

使用jquery live binding。重新绑定生成的内容时，它将为您节省大量时间，并使您的架构更加清晰。可悲的是，当我使用jQuery进行开发时，它尚未可用;我们使用其他具有相同效果的工具。

过去，当使用ajax生成一个页面部分依赖于其他部分生成时，我也遇到了问题。生成第一部分第一部分和第二部分第二部分将使您的页面按预期更慢。在前面计划这个。开发页面，以便在打开时已经拥有所有内容。

另外（关于简单页面），将一个服务器上引用文件的数量保持在较低水平。将javascript和css库加入服务器端的一个文件中。将图像保存在单独的主机上，更好的单独主机（仅创建第三级域也可以）。虽然这只在生产上是值得的;这将使开发过程更加困难。

Answer 2

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

• 性能。您的服务器必须做的工作是您应该关注的。通过在客户端执行更多处理，您可以减少服务器的工作量并加快速度。例如，如果服务器可以发送一小部分JSON而不是巨大的HTML片段，那么让客户端执行它会更有效率。在以任何方式发送少量数据的情况下，差异可能微不足道。

• 可读性。在JavaScript中生成标记的缺点是读取和维护代码要困难得多。在引用的字符串中嵌入HTML是令人讨厌的，在文本编辑器中查看，语法着色设置为JavaScript，并使编辑更加困难。

• 分离数据，演示和行为。根据可读性，在JavaScript中使用HTML片段对代码组织没有多大意义。 HTML模板应该处理标记，并且应该单独使用JavaScript来处理应用程序的行为。插入到页面中的HTML片段的内容与您的JavaScript代码无关，只是插入它，在何处以及何时插入。

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

Answer 3

我目前正在开发一个计算量很大的应用程序，而且我在客户端渲染几乎所有这些应用程序。我不确切知道你的应用程序将要做什么（更多细节会很棒），但我会说你的应用程序可能会做同样的事情。只需确保所有与安全性和数据库相关的代码都位于服务器端，因为不这样做会在应用程序中打开安全漏洞。以下是我遵循的一些一般准则：

• 不要依赖拥有超高速浏览器或计算机的用户。有些人在旧机器上使用Internet Explore 7，如果它们太慢，那么你将失去很多潜在客户。 在尽可能多的不同浏览器和计算机上进行测试。
• 如果您有一些代码可能会暂时减慢或冻结浏览器，显示反馈机制（在大多数情况下会显示简单的“正在加载”消息）告诉用户某些内容确实在继续，浏览器不只是随机冻结。
• 尝试在初始化期间尽可能多地加载并缓存所有内容。在我的应用程序中，我正在做类似于Gmail的事情：显示一个加载栏，加载应用程序将需要的所有内容，然后从那里为用户提供流畅的体验。是的，他们将不得不等待几秒钟来加载，但之后应该没有问题。
• 最大限度地减少DOM操作。原始数字运算JavaScript性能可能“足够快”，但对DOM的访问仍然很慢。避免创造和破坏元素;如果你现在不需要它们，只需隐藏它们。

Answer 4

我最近遇到了同样的问题并决定采用浏览器端处理，一切都在FF和IE8和IE8中以7种模式运行良好，但随后...我们的客户端，使用Internet Explorer 7遇到问题，应用程序会冻结并出现一个脚本超时框，我在解决方案中放了太多工作就把它扔掉了所以我最后花了一个小时左右优化脚本并尽可能地添加setTimeout。

我的建议？

• 如果可能，请保持客户端的非关键计算。
• 为了保持较低的数据传输，请使用JSON并让客户端整理HTML。
• 使用最小公分母测试您的脚本。
• 如果需要，请使用FireBug中的分析功能。 推论：使用jQuery的未压缩（开发）版本。

Answer 5

当然这取决于数据，但大部分时间如果你可以推送它的客户端，那么。使客户端执行更多处理并使用更少的带宽。 （这又取决于数据，你可以进入需要发送更多数据的情况，以便在客户端进行）。

Answer 6

安全检查等一些事情应该始终在服务器上完成。如果您的计算需要大量数据并产生较少的数据，那么也将它放在服务器上。

顺便说一下，你知道你可以在服务器端运行Javascript，渲染模板和命中数据库吗？查看CommonJS生态系统。

Answer 7

也可能存在跨浏览器支持问题。如果您正在使用跨浏览器，客户端库（例如JQuery）并且它可以处理您需要的所有处理，那么您可以让库来处理它。生成跨浏览器的HTML服务器端可能更难（往往更加手动），具体取决于标记的复杂性。

Answer 8

这是可能的，但是由于繁重的初始页面加载＆amp;＆amp;大量使用缓存。以gmail为例

• 在初始页面加载时，它会下载运行所需的大多数js文件。最重要的是缓存。
• 不要过度使用图像和图形。
• 加载需要在初始加载中显示的所有数据以及随后可预测的用户数据。在gmail＆amp;最新的雅虎邮件收件箱不仅填充了单个邮件会话正文，它在页面加载时提前加载了几封完整的电子邮件。高负责的秘诀来自成本（如果带宽低，gmail要求加载轻型版本。我们大多数人都经历过这种情况）。
• 遵循KISS原则。意思是保持你的设计简单。
• 在任何情况下都不会尝试使用javascript渲染整个页面，您无法使用高配置系统或高带宽系统预测所有最终用户。

智能分割服务器和客户端之间的工作负载。

Answer 9

如果你认为将来你可能想为你的应用程序创建一个API（与iPhone或Android应用程序通信，让其他网站与你的网站集成），你必须为所有这些设备复制一堆代码，如果你使用应用程序的简单服务器实现。