Templating HTML in Frontend Development

Building static HTML’s it’s fun (yes, it is) but it can become a boring copy & paste task sometimes. That’s why today I want to introduce a template engine for HTML.

What do I want to achieve?

  • Write less HTML.
  • Faster HTML maintenance and bug fixing.
  • Better experience when working with 2 or more developers on HTML’s.
  • Faster prototyping, faster delivery.

jinja template engine


There are many template engines out there. The one I chose, based on who uses it, is Jinja.

Since we’re not going to use the full potential of the template engine I don’t think it matters much which one you pick, as long as it has a grunt plugin.

Jinja2 is a full featured template engine for Python. It has full unicode support, an optional integrated sandboxed execution environment, widely used and BSD licensed.

More information and documentation on its website: http://jinja.pocoo.org/


The feature that got me into using this is the include. You already know how this work.

It’s a must in order to follow the DRY rule: don’t repeat yourself.

{% include "includes/_head.html" %}

... specific page content ...

{% include "includes/_footer.html" %}

Before using templates if I had to change an item on the menu component, a class or a tag that was used in all pages, well… I had to do it manually for all pages. Maybe for some cases I could do a “find & replace”. But in any case, still a hassle.
Now I just edit the template file and all the pages are recompiled instantly with the new change.


We can also set variables:

{% set pageTitle = "Home" -%}

Then use it on our templates as so:

<title>{{ pageTitle }}</title>

I use this mostly for the page meta title. I set the variable before including the _head.html template so that it will inherit the value. It allows me to have just 1 file for the head HTML but at the same time customized for each page.


A grid view of images? A list of products?

For all those cases we can use a loop. This will allow us to just write the item/component once. The maintenance will be really easy afterwards.
Imagine using the old way and having a component repeated 20 times in the same page.

You need to change a class? Need to add new markup to the component?

If you’re using a loop, just change it once.

{% for _ in range(0, 10) -%}
 <div class="card">

 <img src="" alt=""> 
 <a href="#">
 <h1>Title Link</h1>
 Some Text
 <a href="#">Button</a>

 <!-- .card -->
{% endfor -%}

With the code above we’ll repeat the card component 10 times. This is a real time saver when I have to modify the component in any way.

Loops with Arrays

Things can get very interesting. Say you want to create a menu or a component but with unique text for each item.

We can use the for statement and loop through an array

 {% for item in [
   ["Title 1", "red"],
   ["Title 2", "blue"],
   ["Title 3", "green"],
   ["Title 4", "yellow"]
   <li class="{{ item[1] }}">{{ item[0] }}</li>
  {% endfor -%}

It will be rendered in:

  <li class="red">Title 1</li>
  <li class="blue">Title 2</li>
  <li class="green">Title 3</li>
  <li class="yellow">Title 4</li>

Although this is a very simple example the component we want to repeat could be very complex, markup wise.


None of these awesomeness would make any sense if we weren’t able to build the HTML on each file save.

Using a grunt task we can watch over the source HTML files and compile them. It’s really fast so no development delay.

Check out grunt-jinja for more information.

Folder structure

Pretty straight forward:

  • /html/
  • /html-source/includes/_head.html
  • /html-source/includes/_footer.html
  • /html-source/homepage.html
  • /html-source/product.html
  • /html-source/login.html

It can be anything since you’re free customize the jinja grunt task to fit your project.

What does this mean for the Backend Developer?

Nothing. Nada. Nic. You will still have a folder called html for the compiled files.

Just remember, if you need to change the static HTML’s you will have to update the html–source folder and run the grunt task. Otherwise bad things will happen.


Additionally to all this, since we’re splitting up the files we can easily have multiple developers working on HTML’s without stepping in each other toes.
One can work on the _head.html file, while the other on the homepage.html file. Both will be able to commit their code and do changes without having to merge. Pretty sweet.

I believe using this templating engine will boost your productivity while the impact on your workflow will be minimal. I’ve already used it on a real project and it has greatly improved my delivery and bug fixing times.

Your thoughts?


Published by

Ricard Torres

Ricard is a Senior UI/UX Developer @ TBSCG. Based in Barcelona he also plays guitar, takes photographs and teaches Haidong Gumdo.

4 thoughts on “Templating HTML in Frontend Development”

  1. Good read, well written, convincing arguments! But tell the truth, the title ‘Ninja…’ really is what first attracted you to this.

Comments are closed.