Question

使用JQuery或任何其他类似框架从您的自定义URL / Web服务加载HTML内容非常容易。我已经多次使用这种方法，直到现在，发现性能令人满意。

但所有的书籍，所有专家都试图让我使用JSON而不是生成HTML。它是如何比HTML更优越的？

它快得多吗？它在服务器上的负载是否很小？

另一方面，我有一些使用生成HTML的原因。

这是一个简单的标记，通常与JSON一样紧凑或实际上更紧凑。
它不易出错，因为你得到的只是标记，而且没有代码。
在大多数情况下编程会更快，因为您不必为客户端单独编写代码。

你在哪一边，为什么？

Answer 1

我有点双方，实际上：

当我在javascript方面需要的是数据时，我使用的是JSON
当我在javascript方面需要的是演示文稿时我不会做任何计算，我通常会使用HTML

使用HTML的主要优点是，当您想要使用Ajax请求中的内容替换页面的完整部分时：

在JS中重新构建页面的一部分（非常）很难
你可能已经在服务器端有一些模板引擎，它首先用于生成页面...为什么不重用它？

我通常不会考虑事物的“性能”方面，至少在服务器上是这样的：

在服务器上，生成一部分HTML或一些JSON可能不会产生太大的影响
关于通过网络的东西的大小：好吧，你可能不会使用数百KB的数据/ html ...在你传输的任何内容上使用gzip将会产生最大的差异（不在HTML和JSON之间选择）
可以考虑的一件事是，客户端需要从JSON数据重新创建HTML （或DOM结构）的资源...比较将部分HTML推入页面; - ）

最后，有一点非常重要：

开发一个新系统需要多长时间才能将数据作为JSON +代码发送给JS，并将其作为HTML注入页面？
返回HTML需要多长时间？如果您可以重用一些已有的服务器端代码，可以使用多长时间？

并回答另一个答案：如果你需要更新页面的多个部分，仍然有解决方案/ hack将所有这些部分发送到一个大字符串中，该字符串将几个HTML部分组合在一起，并在JS中提取相关部分。 / p>

例如，您可以返回一些如下所示的字符串：

<!-- MARKER_BEGIN_PART1 -->
here goes the html
code for part 1
<!-- MARKER_END_PART1 -->
<!-- MARKER_BEGIN_PART2 -->
here goes the html
code for part 2
<!-- MARKER_END_PART2 -->
<!-- MARKER_BEGIN_PART3 -->
here goes the json data
that will be used to build part 3
from the JS code
<!-- MARKER_END_PART3 -->

这看起来并不是很好，但它确实非常有用（我已经使用了很多次，主要是当HTML数据太大而无法封装到JSON中时）：你正在为需要演示的页面部分发送HTML，并且您正在为需要数据的情况发送JSON ...

...为了提取这些，我猜想JS子串方法可以解决问题; - ）

Answer 2

我主要同意这里所说的意见。我只是想把它们总结为：

如果您最终解析客户端以对其进行一些计算，那么发送HTML是不好的做法。
如果您最终要做的就是将其合并到页面的DOM树中，那么发送JSON是不好的做法。

Answer 3

那么，

我是那些喜欢以这种方式分开事物的少数人之一： - 服务器负责提供数据（模型）; - 客户负责显示（查看）和操纵数据（模型）;

因此，服务器应该专注于交付模型（在这种情况下，JSON更好）。这样您就可以获得灵活的方法。如果要更改模型的视图，可以让服务器发送相同的数据，只需更改将数据更改为视图的客户端javascript组件即可。想象一下，您有一台服务器向移动设备和桌面应用程序提供数据。

此外，这种方法可以提高工作效率，因为服务器和客户端代码可以同时构建，永远不会失去焦点，这是当你从js切换到PHP / JAVA /等时会发生的事情。

一般来说，我认为大多数人更喜欢在服务器端尽可能多地做，因为他们不掌握js，所以他们尽量避免使用它。

基本上，我和那些正在研究Angular的人有同样的看法。在我看来，这是网络应用的未来。

Answer 4

我觉得我可能会添加一些有趣的东西。我开发了一个只能一次加载完整视图的应用程序。从那时起，它只用ajax传回服务器。它只需要加载一个页面（我的理由在这里不重要）。有趣的部分是我特别需要返回一些要在javascript中操作的数据和要显示的局部视图。我可以把它分成两个调用两个单独的动作方法，但我决定采用一些更有趣的东西。

检查出来：

public JsonResult MyJsonObject(string someData)
{
     return Json(new { SomeData = someData, PartialView = RenderPartialViewToString("JsonPartialView", null) }, JsonRequestBehavior.AllowGet);
}

你可能会问什么是RenderPartialViewToString（）？这就是这个凉爽的小块子：

protected string RenderPartialViewToString(string viewName, object model)
{
     ViewData.Model = model;

     using (StringWriter sw = new StringWriter())
     {
          ViewEngineResult viewResult = ViewEngines.Engines.FindPartialView(ControllerContext, viewName);
          ViewContext viewContext = new ViewContext(ControllerContext, viewResult.View, ViewData, TempData, sw);
          viewResult.View.Render(viewContext, sw);

          return sw.GetStringBuilder().ToString();
     }
}

我没有对此进行过任何性能测试，所以我不确定它是否比为JsonResult调用一个动作方法和为ParticalViewResult调用一个动作方法或者更少或更少，但我仍然觉得它很酷。它只是将部分视图序列化为字符串，并将其与Json一起作为其中一个参数发送。然后我使用JQuery获取该参数并将其打入其适当的DOM节点：）

让我知道您对我的混合动力的看法！

Answer 5

如果响应不需要进一步的客户端处理，我认为HTML是可以的。发送JSON只会强制您进行客户端处理。

另一方面，当我不想一次使用所有响应数据时，我使用JSON。例如，我有一系列三个链式选择，其中所选的值1确定将使用哪些值来填充第二个，依此类推。

Answer 6

IMV，它是关于将数据与数据表示分离，但我使用的是Pascal，它不一定表示分离只能跨越客户端/服务器边界。如果您已经（在服务器上）有这种分离并且只想向客户端显示某些内容，无论是发送回JSON并在客户端上对其进行后处理，还是只发送回HTML，完全取决于您的需求。说一般情况下你发回HTML的“错误”只是IMV的声明。

Answer 7

JSON是非常通用且轻量级的格式。当我开始将它用作客户端模板解析器数据时，我发现了它的美感。让我解释一下，在我使用smarty和服务器端的视图（生成高服务器负载）之前，现在我使用一些自定义jquery函数，所有数据都在客户端呈现，使用客户端浏览器作为模板解析器。它节省了服务器资源，另一方面浏览器每天都在改进他们的JS引擎。因此，客户端解析的速度现在不是一个重要问题，更重要的是，JSON对象通常非常小，因此它们不会消耗大量的客户端资源。由于服务器非常负载，我宁愿为一些浏览器速度慢的用户设置一个网站，而不是慢速网站。

另一方面，从服务器发送纯数据，您可以从演示文稿中抽象出来，如果明天要更改它或将数据集成到另一个服务中，您可以更轻松地完成。

只需2美分。

Answer 8

如果你想要一个干净的解耦客户端，在我看来这是最好的做法，那么通过javascript创建100％的DOM是有意义的。如果您构建了一个基于MVC的客户端，该客户端知道如何构建UI，那么您的用户一次下载一个javascript文件并将其缓存在客户端上。初始加载后的所有请求都是基于Ajax的，只返回数据。这种方法是我发现的最干净的方法，并提供了一个干净的独立封装演示文稿。

然后服务器端专注于提供数据。

所以明天当产品要求你完全改变页面的设计时，所有你改变的是创建DOM的源JS，但可能会重用你已经存在的事件处理程序，而服务器是遗忘的，因为它100％脱离介绍

Answer 9

根据您的UI，您可能需要更新DOM中的两个（或更多）不同元素。如果您的回复是HTML格式，那么您是否要解析它以确定哪些内容在哪里？或者你可以使用JSON哈希。

你甚至可以组合它，返回带有JSON w / html数据：）

{ 'dom_ele_1' : '<p>My HTML part 1</p>', 'dome_ele_2' : '<div>Your payment has been received</div>' }

Answer 10

HTML有许多冗余且未显示的数据，即标签，样式表等。因此，与JSON数据相比，HTML大小会更大，导致更多的下载和渲染时间，这也会导致浏览器忙于呈现新数据。

Answer 11

当你有一个javascript小部件从服务器请求信息时，通常会发送json，例如列表或树视图或自动完成。这是我发送JSON的时候，因为它是将被解析和原始使用的数据。但是，如果您只是要显示HTML，那么生成服务器端并将其显示在浏览器上的工作要少得多。浏览器已经过优化，可以使用innerHTML =“”将HTML直接插入到dom中，因此您不会出错。

Answer 12

我认为这取决于设计的结构，使用JSON比使用HTML更加性感，但问题是如何处理它以便可以轻松维护。

例如，假设我的列表页面使用整个站点的相同html /样式，我会编写全局函数来格式化HTML的这些部分，而我所要做的就是将JSON对象传递给函数

Answer 13

在大多数情况下，Html响应就足够了，除非你必须在客户端进行一些计算。

Answer 14

视情况而定。

有时，避免JSON是必不可少的。例如，当我们的程序员在js编程时遇到麻烦时。

我的经验告诉我：与内联JSON相比，更好地使用ajax服务。

迟早js成为问题

为什么返回生成的HTML而不是JSON是一种不好的做法？或者是吗？

14 个答案: