Why is it a bad practice to return generated HTML instead of JSON? Or is it?

Question

It is quite easy to load HTML content from your custom URLs/Web services using JQuery or any other similar framework. I've used this approach many times and till now and found the performance satisfactory.

But all the books, all the experts are trying to get me to use JSON instead of generated HTML. How's it much more superior than HTML?

Is it very much faster?
Does it have a very much lesser load on the server?

On the other side I have some reasons for using generated HTML.

1. It's simple markup, and often just as compact or actually more compact than JSON.
2. It's less error prone cause all you're getting is markup, and no code.
3. It will be faster to program in most cases cause you won't have to write code separately for the client end.

Which side are you on and why?

Answer 1

I'm a bit on both sides, actually :

• When what I need on the javascript side is data, I use JSON
• When what I need on the javascript side is presentation on which I will not do any calculation, I generally use HTML

The main advantage of using HTML is when you want to replace a full portion of your page with what comes back from the Ajax request :

• Re-building a portion of page in JS is (quite) hard
• You probably already have some templating engine on the server side, that was used to generate the page in the first place... Why not reuse it ?

I generally don't really take into consideration the "performance" side of things, at least on the server :

• 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 ;-)

Finally, one thing that definitly matters :

• How long will it take you to develop a new system that will send data as JSON + code the JS required to inject it as HTML into the page ?
• How long will it take to just return HTML ? And how long if you can re-use some of your already existing server-side code ?

And to answer another answer : if you need to update more than one portion of the page, there is still the solution/hack of sending all those parts inside one big string that groups several HTML portions, and extract the relevant parts in JS.

For instance, you could return some string that looks like this :

<!-- 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 -->

That doesn't look really good, but it's definitly useful (I've used it quite a couple of times, mostly when the HTML data were too big to be encapsulated into JSON) : you are sending HTML for the portions of the page that need presentation, and you are sending JSON for the situation you need data...

... And to extract those, the JS substring method will do the trick, I suppose ;-)

Answer 2

I mainly agree with the opinions stated here. I just wanted to summarize them as:

• It is bad practice to send HTML if you end up parsing it client-side to do some calculations over it.

• It is bad practice to send JSON if all you'll end up doing is to incorporate it into the page's DOM tree.

Answer 3

Well,

I'm one of those rare persons that likes to separate things this way: - The server is responsible for delivering data (model); - The client is responsible for showing (view) and manipulating data (model);

So, the server should focus on delivering the model (in this case JSON is better). This way, you get a flexible approach. If you want to change the view of your model, you keep the server sending the same data and just change the client, javascript components, that change that data into a view. Imagine, you have a server delivering data to mobile devices as well as desktop apps.

Also, this approach increases productivity, since the server and client code can be built at the same time, never losing the focus which is what happens when you keep switching from js to PHP / JAVA / etc.

Generally, I think most people prefer to do as much as possible on the server side because they don't master js, so they try to avoid it as much as possible.

Basically, I have the same opinion as those guys that are working on Angular. In my opinion that is the future of web apps.

Answer 4

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.

Check it out:

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

What is RenderPartialViewToString() you might ask? It is this little nugget of coolness right here:

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();
     }
}

I haven't done any performance testing on this so I'm not sure if it incurs any more or less overhead than calling one action method for the JsonResult and one for the ParticalViewResult, but I still thought it was pretty cool. It just serializes a partial view into a string and sends it along with the Json as one of it's parameters. I then use JQuery to take that parameter and slap it into it's appropriate DOM node :)

Let me know what you think of my hybrid!

Answer 5

If the response needs no further client-side processing, HTML is OK in my opinion. Sending JSON will only force you to do that client-side processing.

On the other hand, I use JSON when I don't want to use all the response data at once. For example, I have a series of three chained selects, where the selected value of one determines which values are going to be used for populating the second, and so on.

Answer 6

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.

Answer 7

If you want a clean decoupled client, which in my opinion is best practice, then it makes sense to have 100% of the DOM created by javascript. If you build an MVC based client that has all the know how to build the UI then your users download one javascript file one time and it's cached on the client. All requests after that initial load are Ajax based and only return data. This approach is the cleanest I have found and provides for a clean independent encapsulation of the presentation.

The server side then just focuses on delivering data.

So tomorrow when product asks you to change the design of a page completely all you change is the source JS that creates the DOM, but likely get to reuse your already existing event handlers and the server is oblivious because it 100% decoupled from presentation

Answer 8

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.

On another hand, sending pure data from server you abstract it from presentation so, if tomorrow you want to change it or integrate your data into another service you can do it much easier.

Just my 2 cents.

Answer 9

Depending on your UI, you may need to update two (or more) different elements in your DOM. If your response is in HTML, are you going to parse that to figure out what goes where? Or you can just use a JSON hash.

You can even combine it, return a JSON w/ html data :)

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

Answer 10

HTML has many redundant and not displayed data i.e. tags, style sheets etc.. So HTML size compared to JSON data will be bigger leading to more download and render time also it will cause browser to be busy rendering the new data.

Answer 11

Sending json is generally done when you have a javascript widget requesting information from the server, such as a list or a tree view or an autocomplete. This is when I would send JSON as it is data that will be parsed and used raw. However if your just gonna show HTML then its a lot less work to generate it server side and just show it on the browser. Browsers are optimized for inserting HTML directly into the dom with innerHTML = "" so you can't go wrong with that.

Answer 12

Html response is enough in most of the cases unless you have to perform some calculation at the client side.

Answer 13

I think it depends on the structure of the design, it's just more sexy to use JSON than HTML but the question is how would one handle it so it can be easily to maintain.

For example, say I have the listing page that utilize the same html/style of the entire site, I would write the global function to format those portions of HTML and all I have to do is passing the JSON object into the function.

Answer 14

Depends on the circumstances.

Sometimes it is essential to avoid JSON. When our programmers have trouble programming in js, for example.

My experience tells me that: better use ajax service than inline JSON.

Sooner or later the js becomes a problem