视情况而定。

有时，必须避免使用JSON。例如，当我们的程序员在js编程时遇到麻烦时。

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

js迟早会成为问题

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

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

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

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

如果您想要一个干净的解耦客户端（我认为这是最佳实践），那么有100％的javascript创建的DOM是有意义的。如果您构建具有所有知识的基于MVC的客户端，并且会构建UI，则您的用户会一次下载一个javascript文件，并将其缓存在客户端上。初始加载后的所有请求均基于Ajax，并且仅返回数据。这种方法是我发现的最干净的方法，它为演示文稿提供了干净的独立封装。

然后，服务器端仅专注于传递数据。

因此，明天当产品要求您完全更改页面的设计时，您所做的全部更改就是创建DOM的源JS，但是很可能会重用您已经存在的事件处理程序，并且服务器会被忽略，因为它100％与表示分离

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

JSON非常通用且轻巧。当我开始将其用作客户端模板解析器数据时，我发现了它的美。让我解释一下，在我以前在服务器端使用smarty和视图（产生高服务器负载）之前，现在我使用一些自定义的jquery函数，并且所有数据都使用客户端浏览器作为模板解析器在客户端呈现。它节省了服务器资源，另一方面，浏览器每天都在改进其J​​S引擎。因此，客户端解析的速度现在不再是一个重要的问题，而且，JSON对象通常很小，因此它们不会消耗大量客户端资源。对于服务器速度较慢的某些用户，我更喜欢使用慢速网站，而不是对每个人都慢速站点，因为服务器负载很大。

另一方面，从服务器发送纯数据，您可以将其从表示中提取出来，这样，如果明天您要更改它或将数据集成到另一个服务中，则可以轻松得多。

只是我的2美分。

我有一些有趣的东西，我想我可能会补充。我开发了一个只能加载一次完整视图的应用程序。从那时起，它仅使用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节点中：）

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

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

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

IMV，这完全是将数据与数据表示分离开来，但是我支持Pascal，这并不一定意味着这种分离只能跨越客户端/服务器边界。如果已经（在服务器上）具有这种分隔，并且只想向客户端显示某些内容，则是否发送回JSON并在客户端上对其进行后处理，或者只是发送回HTML，完全取决于您的需求。在一般情况下，说您“错误”发送回HTML太笼统了IMV声明。

我主要同意这里所说的观点。我只想将它们总结为：

• 如果最终在客户端解析HTML以对其进行一些计算，则发送HTML是一种不好的做法。

• 如果您最终要做的就是将JSON合并到页面的DOM树中，则发送JSON是不正确的做法。

好，

我是喜欢以这种方式分开事物的稀有人物之一：-服务器负责传递数据（模型）；-客户负责显示（查看）和处理数据（模型）；

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

此外，这种方法还可以提高生产率，因为可以同时构建服务器和客户端代码，而不会失去焦点，而这正是您不断从js切换到PHP / JAVA / etc时发生的情况。

通常，我认为大多数人喜欢在服务器端尽可能多地执行操作，因为他们不掌握js，因此他们尝试尽可能地避免这样做。

基本上，我和那些在Angular上工作的人有相同的看法。我认为这是网络应用程序的未来。