

A proper JavaScript templating engine with a sane syntax - pablasso
https://github.com/freshout-dev/thulium

======
jamesRaybould
That looks a hell of a lot like underscore.js templates
([http://underscorejs.org/#template](http://underscorejs.org/#template)) to
me. What would be the advantage if I was to make the swap?

~~~
benbeltran
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.

~~~
jamesRaybould
I don't suppose you have a jsperf link to contrast and compare? I'm assuming
swapping between the 2 isn't all that straightforward?

~~~
benbeltran
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.)

------
ricardobeat
What makes it different from EJS?

~~~
benbeltran
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.

------
tucaz
Not sure this would work with any ASP.NET app other than the ones using Razor
engine since <% and <%= are reserved words for outputting data.

~~~
thoughtpalette
I had the same concern.

------
beebs93
Any plans for template inheritance (e.g. swig)?

~~~
benbeltran
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.

