Yehuda Katz didn't use mustache directly with ember and build Handlebars so that he could start from zero and build up syntactic structures that would support data binding from the get-go. And now, things are into the next level. He wanted to change the working structure of handlebars, which led him to build a new project rather than releasing a next version of handlebars. The new project is nothing but HTMLBars.

Quick overview and advantages

• It's a new templating library build on top of handlebars.
• HTML + handlebars = HTMLbars.
• Simplicity in the markup, removes the need for helpers like bind-attr
• It was created to improve the DOM manipulation; hence, the performance.
• Atleast 30% faster than handlebars.
• Fast DOM cloning; so large lists will be rendered faster.
• Get rid of metamorph (script tags).
• Unlike Handlebars HTMLBars understands your markup
• Builds DOM fragments instead of Strings
• Binding update order
• Templates are no more logic-less. You can write {{#if (a==b)}}
• Structured HTML from server side helps search engine bots.
• Minimal use of Garbage collection events.

It knows your DOM

Cleaner code

Handlebars compilers used to emit strings, and with some javascript functions it used to render those strings to your DOM using the innerHTML. But in case of HTMLBars, things are different. Here, the compiler directly emits DOM elements, so those metamorph tags to do the extra supporting stuffs will not be in your web page any more. It makes things very clean. Handlebars compiled html: HTMLBars compiled html:

Developer friendly code

It's always good to have HTML like syntax for any template engine, cause it makes the things simpler for the developers. As an example, for a html like <div class="myClass">Lorem Ipsum</div>, a developer will like to use a template engine which will let him code like <div class="{{fooClass}}">{{fooText}}</div> rather than, <div {{bind-attr class="fooClass"}}>{{fooText}}</div> Handlebars used to follow the second approach, but HTMLBars is supporting the first one, i.e. the developer friendly one. Due to that it will be an ease to you to write readable codes.

Fast rendering

Cloning is faster

Copying something from a master copy is always faster than to build it from scratch. HTMLBars follows exactly this approach to render elements. 'build' and 'hydrate' are two very important functions in HTMLBars. The 'build' function builds up and returns a document fragment, whereas the 'hydrate function returns information about where dynamic mustache content needs to be inserted into a clone of the document fragment. The static content is created only once, during first render. Then, for each render clone of that is made.

Loops are smarter now

In case of handlebars loops used to create each element inside it from scratch and render it to the DOM using innerHTML. But with the cloning approach of HTMLBars loops have started working smarter. They deals with hydrated clones now.

How it works

Let's take a simple example to describe how the working approach of HTMLBars are different than handlebars. Suppose we want to create a <div> which has a controller property inside it, and the class name is also a variable.

Handlebars approach

[code language="javascript"] //The template is like this. myClass and myValue are two controller properties. //This is how handlebars works var output = ""; output.push(""); [/code]

HTMLBars approach

[code language="javascript"] //The template is like this. myClass and myValue are two controller properties. //This is how htmlbars works var output = dom.createDocumentFragment(); var div = dom.createElement('div'); dom.RESOLVE_ATTR(context, div, 'class', 'myClass'); var text = dom.createTextNode(); dom.RESOLVE(context, text, 'textContent', 'myValue'); div.appendChild(text); output.appendChild(div); [/code] Neither of these two snippets mentioned above are the exact code which handlebars or htmlbars uses. This is just the kind of approach they follows. So, as you can see, in case of htmlbars, it has more specific knowledge about DOM which helps is to update the exact part which actually needs it. This is a better data binding approach.

Improved performance is visible

The working approach of htmlbars makes is much smarter and hence it can take faster actions. It emits DOM elements directly whether the handlebars used to emit strings and then randers them to the DOM using innerHTML. So here a whole stage of conversion is omitted from htmlbars' working approach.

Handlebars work flow:

HTMLBars work flow:

Erik Bryn says, htmlbars are atleast 30% faster than handlebars. There's a benchmark implementation of spinning balls comparing may of the javascript frameworks. Till date, the winner was facebook react, but Bryn proved that now ember, with the help of htmlbars is beating react too. Here is the implementation:

Conclusion

The way angular is using DOM based templating, I hope soon DOM templating will become native in browsers; and after that the renderings will be more faster. So it's actually good to see ember moving to a DOM based templating approach. Cause performance has been an issue with ember all the time. The popularity of angular is way too higher than ember; and some of the resons are, slow rendering, logicless and string templating of ember. So with the new htmlbars approach, I hope ember will earn more reputation and popularity in the competing javascript frameworks market.