Advantage(s) of JSON over HTML for AJAX response?

I was reading the code and JS used in Google websites via firebug.

In the Google Music website when we click on left navigation links then Google loads the songs in right body via ajax.

Now When i want to load the content via Ajax then i normally get the HTML from get method and replace the HTML of body with new HTML received

But in Google music i see that when i click on nav links then Google gets the JSON data of 1000s of songs with all title , album and then build the html on fly. if i had开发者_运维问答 to do that same thing i would have called the page get the full page HTML and then replace the body

So i want to know what is the advantage of using JSON the way Google did it

JSON will likely be a significantly smaller data response than HTML and so will download to the client faster. However, the browser you are using will strongly affect how quickly the HTML is constructed on the client and loaded into the DOM (with older versions of IE being the slowest). It would be interesting to see if the page behaved differently for browsers with slower javascript engines.

In my own testing I have seen IE 6 take 60x longer than Chrome for building an HTML table from JSON with 150 rows and 5 columns.

HTML is a way to control the way that data looks. When you write an HTML tag like this:

<h1>Your Title</h1>

The text "Your Title" is the data. The h1 tag is the presentation. Most seasoned developers try to separate these two things (data and presentation) as much as possible. The philosophy behind this separation is simple: if the data is always just the data, then you can change the way this data is presented a lot easier. Say Google wants to refresh the way Google Music looks, (which I hope they do soon) then they won't have to touch the data model or the way any of their ajax calls work, the data is still just the Artist name, track title, etc.

On the other hand if they were sending data and presentation together, then they would have to revamp everything -- Maybe the new look and feel doesnt call for the artist title to be in an h1 tag, but the AJAX call returns <h1>Artist title</h1> then they have to change the way the data is stored, the way the Ajax call returns the data, instead of just populating a new tag with the artist's name.

This is a core fundamental principle in design patterns and almost every design pattern that exists follows this principle. If you have ever heard of mvc thats what it is about, separation of your layers. Model represents the data, view represents the markup or the presentation, and controller represents the logic which controls how these two interact.

That's why handling JSON in your data calls will help you to not run into problems later on and your code will be cleaner and simpler as JSON is a very simple data format. (also as @alex-gitelman already said, it is faster to transfer!)

It defers the layout and presentation of the data to the page that calls the Ajax method. in your case you format the HTML on the server.

JSON is just a way to represent data, while html represents data+markup. So html will be lot bigger in size as it includes more info. Also if html is used, that means server does, in effect, all rendering for the page but what if you want to populate parts of data in different frames?

So while html responses do make sense in some cases, AJAX is lot more efficient if only data in form of JSON is transfered.

Mainly it's brevity; sending only the raw data rather than HTML should result in a significantly reduced data payload.

Different browsers process JSON with varying speeds depending on whether they have an inbuilt JSON parser. Essentially all modern browsers have this - the notable exception (as always!) is IE6 for which a JSON parser shim can be used (see Douglas Crockfords json2.js)

It's always possible that you might want to perform some special processing on the client and if you have the data then you have more power to be flexible. Unless there are exceptional reasons why not I would generally make use of this approach...