Why Is It a Bad Practice to Return Generated HTML Instead of Json or Is It

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

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

How dangerous is it send HTML in AJAX as opposed to sending JSON and building the HTML?

I tend to use the following rules:

1. Request and return HTML for quick snippets, then use client-side (static) Javascript to insert them. Great for alert messages.

2. Request and return JSON for large datasets. This works great when you want to do filtering, grouping, or sorting on the client side without re-requesting the data in a different form.

3. Request and return JSON for large datasets, but include the (escaped) HTML snippet for each record in the JSON record. This means more rendering time and more bandwidth use than (2), but can reduce duplication of often complex HTML rendering.

4. Request and return Javascript, and eval it client-side. This works best for interactions such as hiding, showing, moving, and deleting. It can work for insertions as well, but often type (1) or (5) work better for that.

5. Request and return Javascript, and eval it client-side, but include escaped HTML in the Javascript so the server is doing the HTML rendering.

I probably use 5 and 1 the most often.

Javascript - Json or html?

If you want the user be able to switch between different views, and this is data that can simply be included on page load, then just include onload then hide/show or load as json and then populate as needed.

If this is a very simple request that needs to be updated as needed and you don't plan on other similar needs in your app then just return html.

However if you are making a request that submits data or performs some action, I am a fan of returning a consistent json response with error boolean, error message and content/data elements.

API responses: references inside the same response is a bad practice?

There's nothing intrinsically wrong with your suggestion; it may well be a much better approach. Apart from the obvious benefit of reducing the payload size, your suggestion will also eliminate the possibility of data anomalies. Anomalies could occur in the existing structure because it allows for two different 'copies' of the same offer to have property values that don't tally. If you don't completely and utterly trust the data source, then you might feel the need to validate incoming offers. But you can't even do this, because which of the many copies of (say) offer1 could you regard as the 'master' copy?

It is for this reason that Ted Codd invented First Normal Form, which is popularly summarised as "eliminate repeating groups".

I said that this may well be a better approach, but whether it actually is a better approach depends a little on your context. For example, if you want to immediately store this data in a relational database, then it's definitely a better approach because the normalisation has been pushed upstream, possibly back to the source, but certainly outside the scope of your application, meaning you don't have to worry about the aforementioned anomalies, and you have way less data to process.

On the other hand, if you want to produce a hierarchical report - or store the data in a hierarchical structure akin to the one you have received, then it's not quite so clear cut. I would still argue eliminating the risk of anomalies is a big gain, as is the potentially large reduction in payload size, but you may pay a price by having to cache the offers somewhere, and then having to 'look up' the offer data as you process each idOffers array. If performance suffers badly from this you might need to weigh these things up. If there are a relatively small number of offers, I doubt this would be an issue.

So I think your instincts are sound.

Why use JSON instead a normal html output with AJAX?

JSON is easily parsed by JavaScript and it is lightweigh.

Returning as JSON is generalization. i.e apart from your browser any other client which can process JSON can make use of response from the server. In this case your data and presentation are in separate layers.

Returning as HTML is specialization. Not all client can process the HTML response. In this case you are binding the data and presentation layer together.

There is a another thread that have discussed about this in details.
Why is Everyone Choosing JSON Over XML for jQuery?

---

Related Topics