JavaScript Template Libraries

Adding content to a page is a staple activity in an Ajax browser application and I've seen many JavaScript templating libraries for generating the HTML to be added. Overall I think this is a bad practice and avoidable.

Example

The TrimPath templates are one of the older examples of using template to generate HTML in the browser. Here is a 1 minute version of the TrimPath 10 minute Introduction

Somehow there needs to be some data available to the JavaScript. This data could be written into the page by the server-side tempting engine or could be the server response for an Ajax request. Here is some data written into the page.

<script language="javascript">
    var data = {people:[{first:'Fred', last:'Flintstone'},
                        {first:'Barney', last:'Rubble'}]};
</script>

The templates that convert this data into bits of HTML are commonly stored in hidden elements in the page.

<textarea id="people_jst" style="display:none;">
  {for p in people}
    <li>{p.first} {p.last}</li>
  {/for}
</textarea>

Then generate the HTML from the data and template.

<script language="javascript">
    var result = TrimPath.processDOMTemplate("people_jst", data);
    document.getElementById('list').innerHTML = result;
</script>

Cons

For the standaristas, this templating approach is not semantic. The content of the hidden text area is not part of the page content: it is part of the page's behavior because it is for the sole use of the JavaScript. Storing the template in a hidden element in the page would be enough to give a standards purest a perforated ulcer. I'm definitely with them on this one.

Using a templating system in the browser requires the template processing library to be downloaded to the browser. The TrimPath libary is 10496 bytes minimized or 3119 bytes minimized and gzipped. This is not huge overhead but adding several unnecessary 3 KB libraries to a page definitely starts to add up when there are also the usual event and Ajax libraries included too. There is also the cost of any bugs that may be present in the 400 lines of template library code. Even though the TrimPath templating library isn't too big it likely would grow as people add more features.

For me there just seems to be and associated stench from burdening the browser with parsing and processing templates each time they are used. In JavaScript we can write the above template as.

function people_jst(data) {
  var html = '';
  for (var i=0; i<data.people.length; i++) {
    var p = data.people[i];
    html += '<li>'+p.first+' '+p.last+'</li>';
  }
  return html;
}

No this JavaScript function isn't as pretty as the template and isn't as easy to maintain as the template complexity grows. It is much easier and safer to have a designer work on templates then on JavaScript functions. Developers are accustomed to the nice embedded HTML templates on the server-side and it is natural to want the same on the client-side.

Pros

There is only one real pro I can think of for sending a template to the browser like TrimPath and many other libraries use. If the template is used server-side then it can be shared with the client side. This is DRY and therefore good, however there is at least one other way to stay DRY in this situation.

Send Compiled Templates to the Browser

Instead of a client-side templating library to process templates repeatedly, as needed, we can have a server-side template library that compiles our templates into JavaScript functions like I have done manually above. These JavaScript functions are then sent to the browser. By doing this we are DRY, have reduced browser library dependency, improved browser performance and we can work on templates to develop our HTML.

In Rails, for example, DRY is one of the most important tenets. To stay DRY, Ajax is used to call the server to render little bits of HTML that are then dynamically inserted into the page. With the ability to share templates easily with the JavaScript as compiled functions, this client-server chatter would be reduced. If the embedded templating language is JavaScript then the template to function conversion would be trivial. Using JavaScript on the server-side is not standard now but it won't be long until it is.