What is a Template Engine?
- 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.
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.