Home > Architecture, Programming > Template Engines

Template Engines

This post is part of a series of posts on Client-Side Web Application Development using JavaScript.

What is a Template Engine?

JavaScript templates are essentially a way to address the need to populate an HTML view with data in a better way than having to write a big, ugly string concatenation expression.

from – http://www.dehats.com/drupal/?q=node/107


On an abstract level most template engines implement a Domain-Specific Language (DSL) to marry HTML with your JavaScript objects. Template engines can either work with the DOM or with plain strings. Based on these we can classify the template engines as

  • DOM based, DSL based (ex: Angular, Knockout)
  • DOM based, Non DSL – (ex: Future browsers that will natively support DOM templating)
  • String based, DSL based (ex: Handlebars, Mustache, dustjs)
  • String based, Non DSL – (Plain Old Html ex: Plates)

Why is the categorization relevant?

  • Using a DSL based template engine is not so user interface designer friendly, these templates are no longer Html.
  • Using a DOM based engine makes it difficult to execute the template on the server-side. These factors have a significant impact on template engine selection.

Isomorphic Templates

I have written about some requirement specific parameters here, that are problematic if we use a client-side template engine. For the cases where we need

  • SEO / Accessibility / Progressive Enhancements
  • Faster initial load times

a workable solution available today is to

  • Detect these scenarios
  • Render the pages on the server-side rather than on the client-side.

Of course we do not want to duplicate the templates once for the server and once for the client. So for these scenarios we need a template that is isomorphic (can execute both on the server and client).

A string based template engine is the best choice for the scenario, But if you use a DOM based template engine it is still not the end of the road, there are server-side DOM simulations available.

Keep in mind

  • These are DOM simulations are not real browser DOMs
  • And are bleeding edge

Template engine performance

Template engine performance has a context associated to it. That is where the template is rendered.

On the client

  • String based: string => template engine => string => browser => DOM
  • DOM based: DOM => template engine => DOM

On the server

  • String based: string => template engine => string
  • DOM based: string => DOM Simulation => DOM => template engine => string Of these operations string => DOM is an expensive operation. So in theory string based template engines are faster on the server and DOM based template engines are faster on the browser. But its good to actually measure it.

The other point to keep in mind is when considering a string based template engine on the client we also need to take into account the time taken to load the template output into the DOM.

String based: string => template engine => string => browser => DOM

Notes summarized from




Updates / Refresh

Another feature that you may want to consider when you evaluate a template engine is whether the template engine can update the views automatically when the (view )model changes. Can the template engine re-render when the model changes and can that be localized to partial portions of the view or the entire view has to be refreshed. Different libraries use different terminology here, Spark – Meteor uses the term Live Page Update, Ember calls this Auto updating templates.


  • Use a DOM-based template engine if SEO / Accessibility readers / Progressive enhancement are not a concern & you do not need server-side rendering. Ex: Knockout
  • When both client & server-side rendering are required choose a string based template engine. Ex: Handlebars / dustjs.
  • Even if you use a string based template engine it is worthwhile to keep a watch on the following categories. DOM based template engines (Angular, Knockout). Non DSL based template engine that lets you write plain old html markup and uses standard json (Plates).

Logic in templates & Reuse

  • If you come from a server-side scripting environment you may be familiar with logic getting embedded in the templates. Logic-less templates are an answer to this. DOM-based template engines are generally not Turing-Complete Programming Languages so it is hard to embed logic in DOM-based templates
  • If you come from ASP.NET Web Forms side you may be familiar with the Controls model which offers template reuse at control / widget level. Angular has support for something like this, they call it as directives.

Reading List






Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: