Fork this page on GitHub

Which template engine should I use?

So which template engine should I use?

Scalate offers a number of different template engines. Template engines have different strengths and weaknesses, it depends on your requirements and the make up of your team as to which is the best choice for you.

This page tries to help guide you towards the template engine thats right for you.

Quick Start?

If you already know JSP, Erb or Velocity and want to get started quickly on using an expressive template engine with static typing using the powerful Scala programming language, which detects errors in your templates on each save along with a nice error console in development mode you might find SSP to be the simplest to get started.

Who edits the templates?

The make up of your team and the people who own or edit the templates can affect which style of template engine is the most suitable.

You may even choose to use a mixture of template engines based on the split of who edits the templates across designers and developers.

Designers edit templates

If you have a designer who doesn't write Java or Scala code who wants to own the templates then Mustache is well worth a look. Mustache provides logic-less templates which also work inside the browser using mustache.js.

You can use a regular HTML file as the template and let your designer own and edit it, using a little JavaScript file inject the template with sample data. There is no need for your designer to use a mock or test server; they can just work on a static HTML page with JavaScript.

Your Scala/Java developers can then just reuse the template and inject the values on the server side using the real services and domain model. Scala/Java developers then just focus on populating the context with the right objects that render the template nicely.

Java / Scala developers edit templates

If Java/Scala developers maintain the templates then you probably want to use a DRY approach that uses the minimum amount of expressive code - plus minimise the glue code required to bind template to domain objects and services.

Using static typing can boost performance, detect any typos in a template as soon as you save changes and hopefully soon can help with powerful IDE completion.

So a template engine which reuses the Scala programming language for expressions is worth a look; you get fast static code with lots of error checking as you save your templates.

Choosing the best template engine for your team then depends on the kind of output you are generating…


If you are mostly generating HTML or XHTML then we highly recommend you take a look at Scaml which is the most DRY and concise template language we've ever seen for Scala. It combines the best of Scala, CSS selector syntax and whitespace indentation allow you to generate dynamic HTML / XHTML in a very clean, concise and DRY way.

Scaml can be a little bit of an acquired taste; at first it can look a bit odd until you start to recognise the use of CSS style symbols for ID / class attributes and so on. So rather than just turning away as soon as you see the use of the . # = and @ symbols on the first line of the templates, please give Scaml a try - we're sure you'll like it if you give it some time to sink in! :-)

Generating arbitrary text?

If you are generating arbitrary text (not just HTML/XHTML) you might want to take a look at SSP which should feel very familiar if you've ever used JSP, Erb or Velocity before.

Its main strengths are its flexibility; it can generate any kind of textual output - though its not quite as DRY as Scaml if you are solely creating HTML / XHTML.

If you are put off the JSP / Erb style notation, please be aware you can always use Velocity style directives which are much easier on the eye.


Template Pros Cons


  • great for designers
  • no code in views
  • works in static HTML in browser using mustache.js
  • uses reflection and no static typing
  • easy to have typos in deeply nested templates
  • harder to test all paths through template


  • very DRY for HTML / XHTML
  • static typing for speed and to catch all typos on save
  • easy to test
  • not suitable for non HTML/XML output
  • little bit of an acquired taste; can take a few days to really get it


  • easy to pick up if you know JSP, Erb or Velocity
  • static typing for speed and to catch all typos on save
  • easy to test
  • Not as DRY as Scaml for HTML generation
  • some don't like the use of <%= exp %> notation, though there is always the velocity directive style for that