tags:

views:

749

answers:

6

I've got a fairly ajax heavy site and some 3k html formatted pages are inserted into the DOM from ajax requests.

What I have been doing is taking the html responses and just inserting the whole thing using jQuery.

My other option is to output in xml (or possibly json) and then parse the document and insert it into the page.

I've noticed it seems that most larger site do things the json/xml way. Google Mail returns xml rather than formatted html.

Is this due to performance? or is there another reason to use xml/json vs just retrieving html?

From a javascript standpoint, it would seem injecting direct html is simplest. In jQuery I just do this

     jQuery.ajax({
       type: "POST",
      url: "getpage.php",
      data: requestData,
      success: function(response){

      jQuery('div#putItHear').html(response);

      }

with an xml/json response I would have to do

jQuery.ajax({
       type: "POST",
      url: "getpage.php",
      data: requestData,
      success: function(xml){
                               $("message",xml).each(function(id) { 
                                message = $("message",xml).get(id); 
                            $("#messagewindow").prepend(""+$("author",message).text()+ 
                           ": "+$("text",message).text()+ 
                             "
"); }); } });

clearly not as efficient from a code standpoint, and I can't expect that it is better browser performance, so why do things the second way?

+2  A: 

It will normally reduce the amount of data transferred and therefore improve transfer speed. As anything over-the-wire is normally the bottleneck in a process reducing the transfer time will reduce the total time taken to perform the process, improving user experience.

Garry Shutler
this gets really at the heart of the issue Garry. Though it also opens it to further debate. with 2K coming down the line, i'm wondering where the performance hit is going to come? is it from coming down the pipe? or is it from inserting a chuck verses parsing through the json/xml and then inserting one-by-one
pedalpete
It's also useful to note that when jQuery gets html back from AJAX, if it's a HTML page there's a lot of data there that jQuery can't parse. Since jQuery's method for constructing the new DOM nodes is to hold them inside a div, elements like html, head, body, etc. are invalid and ignored. This can mean you're sending back a lot of wasted data over the wire.
Gabriel Hurley
A: 

Generally JSON is a more efficient way to retrieve data via ajax as the same data in XML is a lot larger. JSON is also more easily consumed by your client side Javascript. However, if you're retrieving pure HTML content I would likely do as you suggest. Although, If you really needed to, you could embed your HTML content within a JSON string and get the best of both worlds

Steve Mc
A: 

Here are a few pros for sending JSON/XML instead of HTML:

  1. If the data is going to ever be used outside of your application HTML might be harder to parse and fit into other structure
  2. JSON can be directly embedded in script tags which allows cross domain AJAX scenarios
  3. JSON/XML preserves the separation of concerns between the server side scripts and views
  4. Reduces bandwidth
Darin Dimitrov
+3  A: 

Returning JSON/XML gives the application more freedom compared to returning HTML, and requires less specific knowledge in different fields (data vs markup).

Since the data is still just data, you leave the choice of how to display it to the client side of things. This allows a lot of the code to be executed on the client side instead of on the server - the server side needs to know only about data structures and nothing about markup. All the programmer needs to know is how to deliver data structures.

The client implementation only needs to know about how to display the data structures returned by the server, and doesn't need to worry about how these structures actually get build. All the programmer needs to know is how to display data structures.

If another client is to be build (that doesn't use HTML as a markup language), all the server components can be reused. The same goes for building another server implementation.

ylebre
i've actually got an xml version for these purposes. i'm more concerned about client handling the input of html vs xml/json. it isn't much different for the server to create xml vs html. but if I know 90% of the requests are going to be coming from this client, then why go to xml first?
pedalpete
XML is a bit easier to build, since you don't need to think about how it will be displayed. All you need to worry about at that point is to make sure you have all the data you need - and that the data is in a usable structure. If you know how your XML data structure is going to look at the start of a project, you can easily work on the project with 2 teams - one for gathering the data from the sources and pouring it into the XML. The other team can work with the XML mockup to work on the presentation of the data. Since the teams can work independantly, they can work parallel, thus faster.
ylebre
A: 

I'm currently wrestling with this decision too and it didn't quite click until I saw how Darin boiled it down:

"If the data is going to ever be used outside of your application HTML might be harder to parse and fit into other structure"

I think a lot of it is where/how the data is going. If it's a one-off application that doesn't need to share/send data anywhere else, then spitting back pure HTML is fine, even if it does weigh more.

Personally, if there is complex HTML to be wrapped around the data, I just spit back the HTML and drop it in. jQuery is sweet and all, but building HTML with Javascript is often a pain. But it's a balance game.

+1  A: 

You should check out Pure, a templating tool to generate HTML from JSON data.

Massimo Fazzolari