如何在ajax密集型应用程序中处理大量HTML数据

呈现代码服务器端(例如，在Rails的AJAX中完成)，然后将视图返回到客户端，在那里它将被放置。
然后分析代码。如果结果太慢，则返回JSON并考虑一种在客户端呈现它的方法。

你的优先级应该是不要让整个事情变得太复杂。

我不喜欢返回生成的HTML。恕我直言，我会返回JSON并使用JQOTE 2之类的东西来处理渲染。让客户端资源处理这项工作。

(旁注:jquote是一个了不起的工具!)

我认为如果您以后不需要这些数据，例如用于过滤、实时搜索等，那么您应该返回HTML。

过早优化是万恶之源。从容易的开始。如果它实在太慢了，那就找一个方法来优化(也许是使用替代方案)。

如果其中一个对您来说不比另一个容易，那么就使用服务器端。我无法想象服务器端脚本语言的操作会比浏览器中的javascript慢。

如果您所要做的只是呈现HTML，那么直接使用服务器(php)可能要容易得多。否则，您必须先用php将其转换为JSON，然后再用JS将其转换回来。这至少是一个额外的步骤和 javascript端额外的工作。

我将投票赞成你提出的第一个方法。

JSON序列化的数据大小比(X)HTML小，你的第一种方法节省了很多CPU周期，网络流量，内存和加速你的客户端，最终在一个响应式的用户界面。

只要发送JSON格式的数据，然后在客户端用JavaScript解析它，这样在服务器上的事情就会更简单，渲染的事情就会委托给客户端web浏览器。

没有唯一的正确答案;这取决于你的期望。

如果您希望应用程序是可访问的(例如:由屏幕阅读器处理)，被搜索引擎机器人拾取，或者希望UI在请求和用户之间可缓存，您将不得不使用服务器生成的HTML，而不是动态加载。如果对生成的HTML使用缓存，就可以节省很多时间，而无需不断地重新呈现。服务器端工具比客户端工具多，但随着JS的发展，这种说法越来越不正确。

OTOH，使用一些JS库生成由客户端呈现的JSON可以真正帮助您的服务器减少负载。您正在将渲染工作分发给客户端，但这确实使您无法控制。如果你有一个JS繁重的解决方案，而客户端不能处理JS(屏幕阅读器，搜索引擎机器人等)，那么网站应该优雅地降级，或者期望有一些受众无法查看它。这些受众对你来说可能微不足道，但这是你需要了解的。只要你很好地管理渲染(设置最小大小的区域，等待图标等)，那么你就可以让客户端渲染和服务器端一样流畅(当比较视觉渲染步骤时)。生成JSOn还为您提供了更多的灵活性，因为定义了更多的接口或其他非ui客户端变得重要。

这取决于你想要达到的目标。如果你正在编写一个移动应用程序，你可能想要节省带宽并使用客户端模板(就像一个例子:John Resig的微模板)。如果带宽对你来说不是那么重要，我会使用服务器端模板来生成你需要的HTML。

在我看来，这都是关于响应。您的服务器总是能够比UA更快地处理数据，但是两者之间的差异可以忽略不计。如果是这种情况，那么我建议将JSON传递给UA，然后使用客户端代码来完成这些繁琐的工作。这样，您就可以在服务器和客户端之间清晰地分离关注点，允许您在将来向不同的客户端端点交付JSON数据，而无需修改服务器端代码。

但是，如果在客户端进行数据处理会对性能造成重大影响，那么直接将HTML交付给客户端可能更有意义。然而我强烈建议您仍然交付JSON，只交付给您的服务器端HTML创建功能(而不是UA)，这样您仍然可以将JSON数据交付给多个端点，而无需在未来更改核心代码。