We opted not to use this particular technique for two reasons: 1) It's not nearly as versatile. You can use the if statements on elements, attributes, text - anything you wish - there is no restriction on its contents or location. 2) In order to actually use something like that we'd have to serialize the DOM tree first, traverse it, and then manipulate the nodes into the proper shape. This is slow slow slow and absolutely must be avoided at any cost.
A little off topic but I expect this to go well with jQuery Mobile. Can we expect any updates there? Been a bit disappointed by the relative quiet since the announcement (not that you owe me anything). Also, is there any publicly available code to check out? Thanks!
Only quiet because we're working so hard. We're releasing the alpha on October 16th (at the jQuery conference in Boston) so we're a bit frantic at the moment. Either way we're hoping to get a blog post up this week.
I see reason 1. as a downside — it allows very messy Smarty-like markup that can generate ill-formed HTML.
2. I think there's little difference whether you serialize first or later. Are all those new fancy DOM traversal, XPath and XSLT APIs really not faster than parsing and joining of strings?
"Are all those new fancy DOM traversal, XPath and XSLT APIs really not faster than parsing and joining of strings?"
It cannot be understated how much slower touching the DOM is compared to doing string manipulation. Any DOM touching - but generating DOM nodes and traversing them is radically slow. If you want to support Internet Explorer it's not even an option, as far as performance goes.
Underscore.js (http://documentcloud.github.com/underscore/) provides great Templating support and the ability to customize your templates through the use of _.templateSettings. This would allow you to use <% %>, [% %], or pretty much any symbol combination you prefer.