ChatGPT解决这个技术问题 Extra ChatGPT

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

It is quite easy to load HTML content from your custom URLs/Web services using JQuery or any other similar framework. I've used this approach many times and till now and found the performance satisfactory.

But all the books, all the experts are trying to get me to use JSON instead of generated HTML. How's it much more superior than HTML?

Is it very much faster? Does it have a very much lesser load on the server?

On the other side I have some reasons for using generated HTML.

It's simple markup, and often just as compact or actually more compact than JSON. It's less error prone cause all you're getting is markup, and no code. It will be faster to program in most cases cause you won't have to write code separately for the client end.

Which side are you on and why?

it's worth noting that the X in AJAX is XML, and HTML at one point was supposed to be XML. The idea was that HTML was human and machine readable data (like JSON), and CSS would do the presentation. Under those conditions, it would not violate "separation of concerns" to send HTML in an AJAX request

P
Pascal MARTIN

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


All data is ultimately presentation.
@Cyril: Huh? I think you are trying to say that data, to be useful, has to be used and thus presented somewhere in some form, and I agree. But to say that data is presentation seems misguided, at the very least.
Hi Vinko, notice the 'ultimately'? I mean exactly what you mean. Just trying to get into the book of quotable quotes here. Ha ha!
The basic question is whether you are absolutely, positively, ultimately sure you will not be using this data for anything but HTML. Because once packed into HTML, the data will be nearly unrecoverable. With JSON your backend can work with XML, SVG, database engines, cross-site API and a thousand other frontends and systems that can accept JSON. With HTML, you will be only able to use it in within HTML.
@SF: When returning HTML from the server, I make sure to split the HTML generating code from the code that accesses the database. That way I can easily add a JSON form as well.
V
Vinko Vrsalovic

I mainly agree with the opinions stated here. I just wanted to summarize them as:

It is bad practice to send HTML if you end up parsing it client-side to do some calculations over it.

It is bad practice to send JSON if all you'll end up doing is to incorporate it into the page's DOM tree.


what if you need to do some calculations and also incorporate it to the page's DOM?
I wonder how long will the above statement have a truthfulness attached to it, If you add the "Half-life of Knowledge" into equation?
is it possible to return an HTML that has