ajax html vs xml/json responses - performance or other reasons

Question

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

Answer 1

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

Answer 2

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

Answer 3

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.

Answer 4

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.

Answer 5

To me it boils down to this:

It's for many of us, much less work to use a server side, mature, template engine that we're accustomed to, to generate html and send it down the pipe, than using a bunch of javascript code to generate HTML client side. Yes, there are some templating engines for javascript now which may mitigate it somewhat.

Since I already separate model, logic and views server side, there is no argument in having yet another separation. JSON is a view, HTML is another view.

And lets face it; both HTML/AJAX and JSON/AJAX are many times better than full page over the pipe.

The final thing you perhaps need to think about is; if you're going to be search engine friendly - you might have to generate the HTML server side any way (the old degrade gracefully mantra).

I usually do a combination. If there is client side logic, I use JSON - else I use HTML. Notifications and autocomplete special fields are sent via JSON.

Answer 6

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.