That looks a hell of a lot like underscore.js templates (http://underscorejs.org/#template) to me. What would be the advantage if I was to make the swap?
It's based on EJS. So it's indeed really similar to underscore. In fact, we benchmarked against underscore's template function and EJS and, at least in our templates, achieved better performance (Not very scientific: we got averages out of 200000 renders). It offers breakable printable blocks, and very nice debuggability.
I'll try to do a /proper/ benchmark (Different cases, different types of templates, and such). Because the tests were with a simple template that had all the shared features. When I do, I'll add it to the README.
It's not that complicated, swaping between the two. they're basically the same if you don't use breaking printable blocks. So you just change:
tm = _.template(string);
tm(context);
to
tm = new Thulium({template : string}).parseSync().renderSync(context);
It's different in that you do the initialization, parsing and rendering in different steps. TBH, with smallish templates, I found Thulium to be about 10µs faster. Which in most cases, is negligible. So if you're already using underscore, you probably shouldn't change everything. But if you need extra features like wrapping the output of a function in form tags or something like that, you can do it really easily with thulium. (Porting some of our helpers from EJS to Thulium meant a reduction of many lines of code and complexity.)
Updated with a JSPerf: http://jsperf.com/thulium-vs-underscore-and-ejs ... Tm runs faster in chrome/node... Underscore wins in firefox. So we'll need to get to work in optimizing stuff for firefox too :)
We based it on EJS because we had a lot of views with EJS. But we needed a lot of performance (Our goal was to be faster than the underscore templating language). We also needed debuggability. So, it's built in a way that works very well with all the tools we use. Finally, the feature we benefit from the most is broken printable blocks. It's very easy to capture the output from a function in a block, and just move it around as we please. It makes wrapping helpers a hell of a lot easier.
I don't think so. I think the purpouse is to offer less: We don't even have built-in helpers or file loading mechanisms or caching. The philosophy is that we just do templating, we do it really well, and the rest is code from your stack. This philosophy has worked with our projects.
