Reputation: 21895
Major differences I've seen are:
#if
, #unless
, #with
, and #each
{{this}}
in blocks (which outputs the current item's string value)Handlebars.SafeString()
(and maybe some other methods)if !x ...
)(Please correct me if I'm wrong with the above.)
Are there any other major differences I am missing?
Upvotes: 393
Views: 157725
Reputation: 34525
Another difference between them is the size of the file:
To see the performance benefits of Handlebars.js we must use precompiled templates.
Source: An Overview of JavaScript Templating Engines
Upvotes: 14
Reputation: 330
here you can see some speed test of different mustaches vs handlebars. mustache caches templates in memory without any user effort, that's why i run it once. It's 3 times slower than mustache. Filesystem cache may slow development and the final result may be comparable to just single run. Dont trust those statements blindly, especially speed.. (PHPs are fast because of opcache+jit enabled)
Upvotes: 0
Reputation: 4878
NOTE: This answer is outdated. It was true at the time it was posted, but no longer is.
Mustache has interpreters in many languages, while Handlebars is Javascript only.
Upvotes: 26
Reputation: 51
I feel that one of the mentioned cons for "Handlebars" isnt' really valid anymore.
Handlebars.java now allows us to share the same template languages for both client and server which is a big win for large projects with 1000+ components that require serverside rendering for SEO
Take a look at https://github.com/jknack/handlebars.java
Upvotes: 5
Reputation: 3184
One subtle but significant difference is in the way the two libraries approach scope. Mustache will fall back to parent scope if it can't find a variable within the current context; Handlebars will return a blank string.
This is barely mentioned in the GitHub README, where there's one line for it:
Handlebars deviates from Mustache slightly in that it does not perform recursive lookup by default.
However, as noted there, there is a flag to make Handlebars behave in the same way as Mustache -- but it affects performance.
This has an effect on the way you can use #
variables as conditionals.
For example in Mustache you can do this:
{{#variable}}<span class="text">{{variable}}</span>{{/variable}}
It basically means "if variable exists and is truthy, print a span with the variable in it". But in Handlebars, you would either have to:
{{this}}
instead{{../variable}}
to get back out to relevant scopevariable
value within the parent variable
objectMore details on this, if you want them, here.
Upvotes: 32
Reputation: 3985
Mustache pros:
Mustache cons:
Handlebars pros:
Handlebars cons:
Source: The client-side templating throwdown: mustache, handlebars, dust.js, and more
Upvotes: 90
Reputation: 2976
One more subtle difference is the treatment of falsy values in {{#property}}...{{/property}}
blocks. Most mustache implementations will just obey JS falsiness here, not rendering the block if property
is ''
or '0'.
Handlebars will render the block for ''
and 0
, but not other falsy values. This can cause some trouble when migrating templates.
Upvotes: 9
Reputation: 71
—In addition to using "this" for handlebars, and the nested variable within variable block for mustache, you can also use the nested dot in a block for mustache:
{{#variable}}<span class="text">{{.}}</span>{{/variable}}
Upvotes: 5
Reputation: 2129
You've pretty much nailed it, however Mustache templates can also be compiled.
Mustache is missing helpers and the more advanced blocks because it strives to be logicless. Handlebars' custom helpers can be very useful, but often end up introducing logic into your templates.
Mustache has many different compilers (JavaScript, Ruby, Python, C, etc.). Handlebars began in JavaScript, now there are projects like django-handlebars, handlebars.java, handlebars-ruby, lightncandy (PHP), and handlebars-objc.
Upvotes: 149