实际上，我在这两方面都有点偏袒:

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

使用HTML的主要优势是当你想用Ajax请求返回的内容替换页面的完整部分时:

用JS重新构建页面的一部分(相当)困难 您可能已经在服务器端有了一些模板引擎，用于首先生成页面……为什么不重复使用呢?

我通常不考虑“性能”方面的事情，至少在服务器上:

On the server, generating a portion of HTML or some JSON won't probably make that much of a difference About the size of the stuff that goes through the network : well, you probably don't use hundreds of KB of data/html... Using gzip on whatever you are transferring is what's going to make the biggest difference (not choosing between HTML and JSON) One thing that could be taken into consideration, though, is what resources you'll need on the client to recreate the HTML (or the DOM structure) from the JSON data... compare that to pushing a portion of HTML into the page ;-)

最后，有一件事肯定很重要:

开发一个新系统需要多长时间，该系统将以JSON +代码的形式发送数据，并将其作为HTML注入到页面中? 返回HTML需要多长时间?重用一些已经存在的服务器端代码需要多长时间?

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

例如，你可以返回一些字符串，看起来像这样:

<!-- 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的substring方法将会做的技巧，我想;-)

如果响应不需要进一步的客户端处理，在我看来，HTML是可以的。发送JSON只会迫使您执行客户端处理。

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

根据您的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>' }

IMV, it's all about separating the data from the presentation of the data, but I'm with Pascal, it doesn't necessarily follow that that separation can only be across the client/server boundary. If you have that separation already (on the server) and just want to show something to the client, whether you send back JSON and post-process it on the client, or just send back HTML, depends entirely on your needs. To say you're "wrong" to send back HTML in the general case is just far too blanket a statement IMV.

我主要同意这里的观点。我想总结一下:

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

发送json通常是在javascript小部件从服务器请求信息时完成的，比如列表、树视图或自动补全。这是当我将发送JSON，因为它是数据，将被解析和使用原始。然而，如果你只是要显示HTML，那么在服务器端生成它并在浏览器上显示它就会少很多工作。浏览器在使用innerHTML = ""直接将HTML插入dom时进行了优化，所以这样做不会出错。

JSON is very versatil and lightweight format. I have discovered its beauty when I have started to use it as a client side template parser data. Let me explain, while before I was using smarty and views on server side (generating high server load), now I use some custom jquery functions and all the data is rendered on client side, using clients browser as template parser. it saves server resourses and on another hand browsers improve their JS engines every day. So the speed of client parsing is not an important issue right now, even more, JSON objects are ususally very small so they don't consume a lot of client side resourses. I prefer to have a slow website for some users with slow browser rather than slow site for everyone because of very loaded server.

另一方面，从服务器发送纯数据，你可以从表示中抽象它，所以如果明天你想改变它或将你的数据集成到另一个服务中，你可以更容易地做到这一点。

这只是我的个人意见。

我认为这取决于设计的结构，使用JSON比使用HTML更吸引人，但问题是如何处理它，使其易于维护。

例如，假设我有一个使用整个网站相同html/风格的列表页面，我将编写全局函数来格式化html的这些部分，我所要做的就是将JSON对象传递到函数中。

I have something interesting I thought I might add. I developed an application that only ever loaded a full view one time. From that point forward it communicated back to the server with ajax only. It only ever needed to load one page (my reason for this is unimportant here). The interesting part comes in that I had a special need to return some data to be operated on in the javascript AND a partial view to be displayed. I could have split this up into two calls to two separate action methods but I decided to go with something a little more fun.

看看吧:

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节点:)

告诉我你对我的混血儿有什么看法!

好吧,

我是极少数喜欢这样区分事物的人之一: -服务器负责传递数据(模型); -客户端负责显示(视图)和操作数据(模型);

因此，服务器应该专注于交付模型(在这种情况下JSON更好)。 通过这种方式，您可以获得灵活的方法。如果你想改变你的模型的视图，你让服务器发送相同的数据，只改变客户端，javascript组件，将数据改变为视图。想象一下，你有一个服务器向移动设备和桌面应用程序传递数据。

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

一般来说，我认为大多数人更喜欢在服务器端做尽可能多的事情，因为他们不精通js，所以他们尽量避免它。

基本上，我和那些致力于Angular的人有着相同的观点。在我看来，这就是网络应用的未来。

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

如果你想要一个干净的解耦客户端(在我看来这是最佳实践)，那么100%的DOM由javascript创建是有意义的。如果你构建了一个基于MVC的客户端，它拥有如何构建UI的所有知识，那么你的用户一次下载一个javascript文件，它就会缓存在客户端上。初始加载之后的所有请求都是基于Ajax的，并且只返回数据。这种方法是我发现的最干净的方法，它提供了一个干净独立的表示封装。

然后，服务器端只专注于交付数据。

所以，明天当产品要求你完全改变一个页面的设计时，你所改变的只是创建DOM的源JS，但可能会重用你已经存在的事件处理程序，而服务器是无关的，因为它100%与表示分离

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

这取决于具体情况。

有时，避免使用JSON是必要的。 例如，当我们的程序员在用js编程时遇到困难。

我的经验告诉我:使用ajax服务比使用内联JSON更好。

迟早js会成为一个问题