Indeed! :) documentFragment is my response to folks who commonly compare .innerHTML vs. appendChild(), where their examples include one .innerHTML update vs. document.body.appendChild(node) in a “for” loop or some such. (One would expect the latter will be slower of course, given the browser will be attempting to reflow the document with each loop iteration vs. once with a write to .innerHTML.)

This blog did however get me to run some quick tests. All done on FF3 – not real official or anything. Each test I created 1000 divs with a small amount of text:

docFrag: 76ms
appendChild: 64ms
innerHTML: 40ms

The difference is, I created a container div, and inserted 1000 children and then appended the container to the body. This is much faster than appending every single child to the body one at a time. Appending the container to the body first, then appending 1000 children is 83ms.

“createDocumentFragment” is useful if you need to insert multiple “loose” children directly into a node. However, I usally prepare my code with containers that can be replaced.

DocumentFragment are the way to go when developing web applications for limited devices and mobile phones. See [1,2]

Also notice that since the documentFragment is not in the document itself, CSS are not applied to its elements. This means that you won’t be able to fiddle with the getComputedStyle( aChildOfTheDocumentFragment ); and other style properties of the children of a documentFrament.

AnM8tR: But in a more realistic scenario you would have a deeper DOM (sub)tree with various text nodes and attributes to touch. On devices and mobile phones, using a documentFragment vs many appendChild directly in the document makes a real difference.

I think this is an interesting discovery, I myself wasn’t aware the browser supported DocumentFragment object. I would say, however, that the most important thing in DOM node construction is to append child nodes to a non-inserted parent node (such as a div).