6

From what I can tell, most developers will use heavy jQuery DOM manipulation tactics to deliver their updated AJAX views. Once things get out of hand, they may consider refactoring using template engines such as Mustache.js. Is this a valid assessment of a natural progression to use a template engine?

When I begin a new AJAX heavy project, is the best practice to use a template engine or is jQuery DOM manipulation good enough?

I have yet to find any negatives with using a template engine. The maintainability, efficiency and simplicity seem to be the redeeming qualities.

Please advise me on whether JavaScript template engines should be used or not by default.

Jason Rikard
  • 163
  • 1
  • 5

3 Answers3

5

@Jason, these notes come to my mind:

  1. JavaScript templates are handy, mostly when you have a list (or array) as the underlying datasource. For example, when you get the list of active employees in JSON format from the server, it's better to bind it to a JavaScript template on return (AJAX response) instead of looping over each employee and creating HTML elements by concatenating strings and employee properties together.
  2. However, there are sometimes situations where JavaScript binding simply is an overhead. Most of the times, you don't have a list of records. Rather, you have a single value in your AJAX response. For example, when you vote-up on stackexchange sites, the return value is not a list, thus not suitable to be used with a JavaScript template.

  3. Another situation that you may not be able to use JavaScript templates is the heterogeneous, instead of homogeneous, datasource. For example, in response to an AJAX request, you may return this JSON string:

    "{"firstName":"Saeed","lastName":"Nemati","isEmployed":true,"interests":["computer","music","language","philosophy","mathematics","physics"],"voteDirection":"up","totalScore":5}"

Which is a complex object of an employee and a vote action. In these scenarios also, you can't use JavaScript templates and should use DOM manipulation directly.

  1. JavaScript refactoring or jQuery refactoring sometimes becomes a headache, as there are still not sophisticated tools out there to help you in a good level. Thus, for example if you create a <div class='employee'><h1>Saeed Nemati</h1></div> HTML fragment on an AJAX response in many places, and then you decide to create <a> tag instead of <h1> tag, you really need to concentrate on this.
Saeed Neamati
  • 18,142
  • 23
  • 87
  • 125
1

It depends or complexity (sometimes templating is a must and sometimes it's an overkill) and functionality you want to have.

As an example when functionality matters - consider the point that Mustache.js (and many other templating systems) don't know anything about DOM, so the won't really let you update the template, only re-render, thus, replace it. Sometimes you don't want to keep some state (like whenever "<details>" element is expanded or not) in your models. Replacing the whole DOM subtree with newly-rendered template will lose this state. There are templating systems (for example, Knockout.js) which allow you to bind DOM nodes to values to combat this problem, though.

drdaeman
  • 111
  • 3
0

Some of the drawbacks of templating to update the DOM are mitigated by using some sort of MVC pattern on the javascript side - JSON updates a javascript model object, which is observed by a controller object which can either update the DOM via template or directly.

This is much more refactorable and DRY than repeating HTML fragments in multiple places. It is also better for handling complex JSON, since the code to use the JSON object to update the model can be written once and not depend on the details of the DOM.

psr
  • 12,846
  • 5
  • 39
  • 67