Reputation: 92581
I know that doing multiple dom manipulations is bad as it forces multiple repaints.
I.e:
$('body').append('<div />')
.append('<div />')
.append('<div />')
.append('<div />');
Instead a better practise is apparently:
$('body').append('<div><div></div><div></div><div></div><div></div></div>');
but I am curious about virtual manipulation
I.e:
$('<div />').append('<div />')
.append('<div />')
.append('<div />')
.append('<div />')
.appendTo('body');
is it still bad, obviously there will be some overhead from calling a function several times, but is there going to be any severe performance hits?
var divs = [
{text: 'First', id: 'div_1', style: 'background-color: #f00;'},
{text: 'Second', id: 'div_2', style: 'background-color: #0f0;'},
{text: 'Third', id: 'div_3', style: 'background-color: #00f;'},
{text: 'Fourth', id: 'div_4', style: 'background-color: #f00;'},
{text: 'Fifth', id: 'div_5', style: 'background-color: #0f0;'},
{text: 'Sixth', id: 'div_6', style: 'background-color: #00f;'}
];
var element = $('<div />');
$.each(divs, function(i,o){
element.append($('<div />', o));
});
$('body').append(element);
Imagine that the divs array has come from an database table describing a form (ok, i'm using div's in the example, but it can be easily replaced with inputs) or something similar.
or with the "recommended" version we have:
var divs = [
{text: 'First', id: 'div_1', style: 'background-color: #f00;'},
{text: 'Second', id: 'div_2', style: 'background-color: #0f0;'},
{text: 'Third', id: 'div_3', style: 'background-color: #00f;'},
{text: 'Fourth', id: 'div_4', style: 'background-color: #f00;'},
{text: 'Fifth', id: 'div_5', style: 'background-color: #0f0;'},
{text: 'Sixth', id: 'div_6', style: 'background-color: #00f;'}
];
var element = '<div>';
$.each(divs, function(i,o){
element += '<div ';
$.each(o, function(k,v){
if(k != 'text'){
element += k+'="'+v+'" ';
}
});
element += '>'+o.text+'</div>';
});
element += '</div>';
$('body').append(element);
Upvotes: 9
Views: 3615
Reputation: 24988
Whatever happened to good old markup generation at runtime? Seriously, what happened?
I agree with @Sohnee's point about importance of readability, but DOM manipulations are some of the most expensive operations a browser can perform. The option of maintaining a string of markup can be made perfectly readable and offer a user experience improvement beyond negligible.
In this jsperf, we're creating a 10x100 table at runtime - a perfectly reasonable (and not the most complex scenario by far) for data pagination. On a quad core machine running a recent version of Chrome the direct DOM manipulation script takes 60ms to complete, as opposed to 3ms for markup caching.
This is an indistinguishable difference on my setup, but what about the poor number-crunching folk sitting behind a corporate firewall and still forced to use an obsolete version of IE? What if the DOM operations required were to be heavier, with attribute manipulation and aggressively forcing re-paints/re-flows?
All I'm saying is if you ever want to optimize some javascript, this is not a bad place to start.
Upvotes: 1
Reputation: 92274
I think that if you start getting to the point where this kind of code is a performance bottleneck, you should be using templates instead of DOM manipulation.
But yes, using the document fragment approach (putting all nodes into a detached node before attaching to the DOM) is going to be faster in most cases, almost never slower.
Upvotes: 0
Reputation: 7281
If you're really worried about performance when appending nodes, you need to use documentfragments. These will allow you to append elements to the dom without repaint. John Resign has an excellent article on this topic. He notes a 200-300% increase in performance. I implemented documentfragments in one of my apps and can confirm his claim.
Upvotes: 1
Reputation: 250882
Firstly, although it is great to read about potential performance hits like this you should always start by measuring to see if you even have a problem.
If you cannot perceive a problem, write the most readable code.
If you can perceive a problem, measure, change and measure.
Having said all this, the last example you have posted involves elements that are not yet written to the DOM, so there would be no repaint until the appendTo
adds the elements to the DOM.
I would be very surprised if you could capture a difference in speed between second and third example - and quite surprised if you could see any major difference between any of them.
Upvotes: 10