Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I had a go at this in <a href="http://jsfiddle.net/4vjY6/15/" rel="nofollow">this jsFiddle</a>. Replacing a chunk of content is fastest when using DOM methods, but setting <code>innerHTML</code> isn't cripplingly slower and probably acceptable if your templates aren't very complex and you won't lose too much time in the string manipulation. (This isn't very surprising, "dealing with broken HTML quickly" is kind of what browsers are supposed to do and <code>innerHTML</code> is an ancient and popular property that probably had lots of optimisation go into it.) Adding another join() step in the innerHTML method also didn't really slow it down.</p> <p>Conversely, using <code>jQuery.tmpl()</code> /and/ the DOM fragment method was orders of magnitude slower in Chrome on Mac. Either I'm doing something wrong in the <code>dom_tmpl</code> function, or deep-cloning DOM nodes is inherently slow.</p> <p>I commented out the append tests because they froze up the tab process when you run the whole suite - thousands through tens of thousands of nodes shoved into a document probably confuse Chrome somehow. Appending with innerHTML alone ended up glacially slow because the string ends up being really huge.</p> <p>The conclusion would seem to be: unless done stupidly or on very large strings, concatenating strings in a templating library likely <strong>isn't going to be what makes it slow</strong>, while trying to be clever with cloning chunks of the DOM will. Also, <code>jQuery.tmpl()</code> handled 2000-ish ops/sec on my computer, and 500-ish on my iPhone 4, this is likely "fast enough" if you're targetting these platforms. It was also in the same ballpark as the DOM fragment function making the latter largely pointless.</p> <p>If you mostly need to replace the content of existing nodes and your templates aren't very large, use Underscore.js's templating and <code>innerHTML</code>. Underscore.js seems to do ten passes through the whole string, so if your templates /are/ large this could be an issue. </p> <p>If you need to append to existing nodes, you can avoid serialising and reparsing the existing content by creating a wrapper element, seting its <code>innerHTML</code>, then append the wrapper element to the target node. </p> <p>If you <em>really</em> want speed or your templates are crazy large, you'll probably have to do something like having a server-side script precompile your templates into Javascript that creates the respective nodes. </p> <p>(Disclaimer: I don't claim to be any good at constructing test cases and benchmarks and only tested this in WebKit, you should tailor this to your use case and get a more relevant set of numbers.)</p> <p><strong>Update:</strong> I <a href="http://jsfiddle.net/4vjY6/17/" rel="nofollow">updated my jsFiddle benchmark</a> to not use any jQuery features, in case its presence (user data on nodes etc.) was the cause of DOM node cloning being slow. Didn't help much.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload