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:
- 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.That's actually a good thing!
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).
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...Oh yeah, speaking of templates
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....