What's the most efficient way to inject new code into the DOM?

I'm doing a little debate with a backend developer for my project (I'm the guy in the front) who introduces new stuff to the DOM. He claims that the best method for injecting a lot of code (obtained via ajax) is to send a JSON object and then iterate over each element of that object. He says he will save some bandwidth and become more server friendly.

Obviously (for me, at least :-)) this means there are many CPU cycles running on the client.

The data is a table with 20-30 rows (2-3 columns each), which means several (useless) iterations.

On the other hand, I think the best way is to send pure XHTML (server generated source) and just inject it in place. This means only one cpu cycle ( $('selector').html(data)

where data

is the data received with AJAX, but also means a lot of bloated HTML code.

I am using jQuery (but I think this is not too important).

So what do you guys think? Thank!

+2


source to share


3 answers


Even in the beginning I usually send HTML

for inserts at certain places, now I usually use JSON

when I can, XML

otherwise, mainly because I can change many places on the page, and act more dynamically with little information.

It is also JSON

smaller than XML

and usually better than "human parsing". The biggest advantage of XMl is that it has been around for a long time and is a standard, so you have both the tools and a knowledgeable workforce. JSON, on the other hand, is a little more obscure. Of course, any developer who deserves their paycheck will be able to recognize it faster than I can write it. Think about it:

  • it has javascript syntax and
  • its the same XML concept.

About just sending, HTML

Quirksmode
says:

If the HTML snippet contains forms, or if the receiving HTML element is a form, this method gives terrible errors in Explorer.

(...)

I will study JSON thoroughly and can switch to it for unlimited access to the application I mean. However, I feel that XML remains the best general format so far, mainly because people are used to it.

Also, HTML snippets can get quite complex (...) So the server-side script that generates HTML can get quite complex.



Also, by only sending HTML, you can just insert information, you won't receive information, you will receive snippets so you can't work with it. Remember, the advantage of AJAX is to have dynamic pages, not pages with some parts that refresh without reloading the full page. You can use it for that, and it's okay, and valid use, but you're using the potential.

Even though HTML insertion could be faster than dom

manipulation, I don't think it is (apart from the problems that IE 6 might have). This you should check and see if it is right for you to use, is it really a performance bottleneck.

I tend to agree with the final argument of the previous link .

While I would like to say that one of them is "the best", I think that choosing the right format depends on the circumstances, and not on any theoretical consideration.

+4


source


$('selector').html(data)

is not one processor cycle; this is one call method. The browser has to process all of this HTML.



The only way to tell is to test both methods and decide how much you care about client response time and server load. From your description, it probably doesn't matter much anyway. I suspect you will want to optimize the third factor: developer comfort. Whichever makes the most sense and is easy to maintain.

+7


source


It depends on the data being returned in most situations I find myself in. If the server is responding with form or general content, I prefer straight XHTML like you are.

When it comes to getting actual data , I prefer the JSON format. Yes, I need to generate client side markup, but since everything is well organized in a JSON array, I can pick and choose a filter as needed. It also allows me to easily change the view of the data later without getting our third party guy involved (his to-do list is always 4-5 days long!)

+2


source







All Articles