HTML5 templating

5th March 2013 — 3 minute read

Amongst HTML5’s new offerings is the <template> tag, and associated API.

This HTML5 rocks article on templates discusses the mechanics of using this feature, and then goes on to discuss the current ways with which this is achieved.

METHOD 1: OFFSCREEN DOM
One approach people have been using for a long time is to create “offscreen” DOM and hide it from view using the hidden attribute or display:none.

METHOD 2: OVERLOADING SCRIPT
Another technique is overloading <script> and manipulating its content as a string. John Resig was probably the first to show this back in 2008 with his Micro Templating utility. Now there are many others, including some new kids on the block like handlebars.js.

I would add to the mix, a roll-your-own method which was essentially an exercise in writing large tracts of DOM manually using string concatenation. Interestingly, if you analyse the compiled templates generated by handlebarsJS, you will find that it does this under the hood. I found this to be a good exercise in learning how templating works, and in appreciating the need for templating engines - but you would not want to use it seriously.

I have experimented with both of these, currently settling on handlebarsJS (method 2).

Now the interesting question that this raises for me is: Should I switch to using the HTML5 native templating API, or should I continue using an existing templating engine?

The redux of of my thoughts on this are that it depends on:

The amount of syntactic sugar you require
Data binding affordances

Now the details:

On syntactic sugar.

HandlebarsJS - and other templating engines - affords a very succinct way of expressing templates. The HTML5 templating API requires one to write templates using querySelectors to select DOM elements, and the fill them in manually. Iteration over an array of elements needs to be done manually. As a result it will be tempting to not separate presentation logic, from model/ controller logic. OTOH, one might prefer the greater degree of control this affords, and is confident on his own ability to keep presentation logic separate.

On data binding affordances.

Sure, binding data to your template can be written by hand. However, if you are already using an MVC frameworks that binds into a templating engine, that simply removes an extremely large amount of development that needs to be done. A great example of this would be emberJS with handlebarsJS. You technically could use Ember without Handlebars, but, why would you want to?

Conclusion.

My personal speculation is that the existing templating engines will switch from using whichever techniques it is currently using like off screen DOM or overloading <script>, to using the HTML5 templating API.

In the interim, why not continue using them? The practical thought here would be that, there is no need to switch to bleeding edge, unless that offers a significant advantage over the present situation.

Wishlist.

That the HTML5 templating API will be updated to provide syntactic sugar that allows for a more succinct expression of presentation logic.