jsPerf vs. templates

Yesterday I saw a tweet about a jsPerf test case comparing templates, which got me curious about how various types of JS templates stack up - to each other and to the other methods. I took a look through the public test cases on jsPerf and found several more people answering that question in various ways, which yielded some interesting info:

• JavaScript Templating - the test case from the tweet, comparing micro-templating and a custom engine
• DOM vs innerHTML based Templating - compares seven different template engines
• nTPL vs Mustache - yes, that
• Precompiled templates - precompiled version of micro-templating against uncompiled ones
• Template vs concatanation - what it says

After looking at these, (probably for no good reason) I was curious if anything would change if the template were more complex and there were more data - the test cases above all produce fairly simple markup. To make a long story short, no, there's no difference I could see (but don't take my word for it). That's not really so surprising since it's all just string manipulation. The more complex templating engines seem to take longer, in general. The ones with simpler vocabularies are pretty fast. But performance-wise? Smaller is still better.

Ok, not good, but not terrible. One thing I noticed as I tweaked various things was that the relationship between the speed of concatenation and speed of the template seemed to stay the same. I was concerned that with more data, there might be more problems. When I added more data, though, both methods slowed by around the same percentage. For reference, templates seem to take about 150% the time to process that concatenation needs, assuming you're considering really unperformant concatenation, which I was (cheating has been removed in the latest revisions).

So there's a performance sacrifice in using templates over doing all the concatenation yourself. This is not really a shocker, because when you do it manually Javascript doesn't have to parse the markup bits of the final product - it's just dumb text. In my initial curiosity, I didn't think things through fully and realize that anything the concatenation approach is going to have to do, the template approach will eventually have to do as well. Also not surprising, then, that the template engines that come out on top in the second bullet point above are those that appear to switch back and forth between pure JS and dumb text, basically just expanded versions of concatenation.

Referring back to the shorter examples people had posted, I doubt you'd want a template in many of those scenarios if performance was at all a factor. In the example I was using, though, I would still choose to take the performance hit because of the readability advantage. It's possible to organize concatenation so it can be worked with more easily (which I tried to do, cause it was beating the pants off templates anyway and putting it all on one line would have been cruel), but it's still less maintainable than markup is going to be. You have to worry about escaping quotes or apostrophes, you can't indent accurately, and there's a disincentive to separate elements that might be part of different concepts on the page.

One thing that's still bugging me is how to deal with nested templates. I added a test case trying to split out the template for an array of objects under the parent, and it didn't do a whole lot better than a for loop within a single template. I'm wondering how various template engines handle that. Maybe someone will eventually post that test case. Maybe me! But not tonight.

In case you're one of the five people in the world I haven't told, I'm going to be speaking about that very subject at the Boston jQuery Conference coming up in October. I'm pretty excited about it. Hey, look at that! There are still tickets available....