views:

164

answers:

5

Which is better in AJAX request, Response with ready HTML or response with just data and write HTML using JavaScript, and this JavaScript will use a predefined HTML template to put the coming data inside and show on the page.

Creating the HTML on the server and send to the page, will decrease the client side JS code, but will increase the response size.

Sending the data to the client side will decrease the response size but will increase the JS code.

Which is better and most used?

+1  A: 

I believe the more common method is to pass the mass of markup (HTML/CSS) via synchronous navigation to site, and keep the AJAX request/response as lean as possible [citation needed].

Admittedly, it is pretty rare to see raw HTML returning as an AJAX response. Usually it will be a JSON response, as that is the easiest to eval() with JS.

Since already most of the markup and styling classes are needed anyway, and might be used by "static" content as well, that leaves you the opportunity to keep the AJAX small, neat and to the point.

Yuval A
Indeed, it's probably not wise to pass HTML to the browser using AJAX. In fact, it's not techncially AJAX then (the X standing for XML). The common formats used are XML and JSON, the latter in particular used because it is lightweight.
Noldorin
+5  A: 

I think the right solution is highly context dependent. There may be a right answer for a given situation, but there is no one size fits all answer. Generally, if I'm using a partial view that gets replaced via AJAX, I'll return html. If I'm performing an action on a small part of something, I'll use JSON. I'm probably more likely to use JSON as there are more situations where it fits, but I try to pick the best solution for the problem at hand. I'm using ASP.NET MVC, though. Other frameworks undoubtedly have different characteristic solutions.

tvanfosson
+3  A: 

I've seen both used. In addition to the tradeoffs listed in the OP, I'd add:

  • It is better to send the information as data, not html since you'll then have more options in how you will use it.
  • What is your comfort level with JS?
  • You can use multiple UI's (on different pages) and can re-use the data on the page. Eg display the data in a short form and in a long form, but use the same data source. -- letting the client switch between the two on a page without requiring a server trip.
  • A pure JS implementation of the liquid template system is available for client-side templating: http://www.mattmccray.com/archive/2008/12/11/Liquidjs_A_Non-Evaling_Templat

Larry

Larry K
+2  A: 

I'll be extremely pragmatic here:

It depends on the amount and the complexity of the new markup.

If you need to return a elaborate piece of HTML, it's always better to write it in the server side and returning it as data, it's also easier to maintain. Building complex HTML in the client side usually is cryptic, even with the use of modern js libraries. On the other hand, if your extra markup is small, then you can create it with js. I've never done anything with ASP.NET AJAX, but having a asp.net page, a rails view, or a JSP with only a small fragment like <p class='info'>Row Updated</p> its confusing.

Let the code speak to you, If you're fighting against javascript code to create markup in the client side, maybe it should go in the server side.

Lastly: don't worry too much about the size of HMTL vs JSON, and if you do, benchmark the requests to see if the difference isn't negligible.

Pablo Fernandez
Also i found that stackOverflow send the html, i saw that in the user profile page.
Amr ElGarhy
Indeed. SO even returns javascript in <script> tags in each request.
Pablo Fernandez
A: 

Usually when updating small parts of screen you can send the JSON back to the client and the client can easily update itself. If you are trying to build a complicated Grid then better to use an UpdatePanel.

azamsharp