Template Engines of a Web-Project Interface Building

5 min readFeb 17, 2020

Interface template engines even in the age of “heavy” frameworks such as React / Angular / Vue remain a popular topic and should be considered by both novice programmers and people with some experience in web development.

It might seem that template engines are not very common now, but there are dozens of them, all of them are applied in practice and each has its own properties, advantages and disadvantages.

To begin with, we shall define what a “template engine” is, where and what it is implemented for.

A template engine is inherently special software that uses an HTML entities to generate the final view sent in response to a client’s request.

Web templates are used to create sites and pages of any type, since the template acts as an unfilled form of the document, the same for any presentation before filling in the data.

The “modern web” is characterized by double projects, for example: React / Angular / Vue for the client part and NodeJS / Django / PHP for the server part. Developers actually write TWO applications to solve one problem. For large projects or projects with great interactivity, this might be reasonable, but is ti so for small and medium-sized projects?

Knowledge of template engines and methods of their implementation in the project allows the back-end developer with minimal knowledge of CSS frameworks and JavaScript to create and run a project of quite high quality without involving web programmers.

The main goal of the template engine is to separate the presentation from the program code. In particular, the use of template engines improves the readability and testability of the code. At the same time, completely different people can be engaged in design and programming, since the data is connected “surgically” exactly in the places where it is needed, or maybe one person, alternating activities or distributing work on the code and presentation in time.

It should also be noted here that the template is, in fact, a kind of “contract” between the client and server data. And then it is a contract, so its formation is a responsible job. Therefore, template engines are often created with elements of a real programming language. Elements of object-oriented programming, in particular, inheritance, are supported.

All templates are created according to the reuse principle and the possibility of transfer to third parties. This means that a good template becomes an object of intellectual property and a subject of sale via the Internet. There are many commercial sites that offer free or paid templates, and also sell licenses for their use.

Any template engine works with the “engine” inside the framework on top of which it is used. The engine analyzes the written template, extracts specialized tags from it and associates it with data to form the page before sending it to the client. Thus, the template engine can conditionally follow the formula:

(data_source + tamplate_text) * engine = view.

Each programming language has its own list of standard template engines, although there are also language-independent ones. Among all, many dependent template engines can be distinguished as follows: Java (Apache Velocity, FreeMaker, Thymeleaf), PHP (Smarty, Twig, Blade, Volt), Python (Jinja2, Django Templates), Ruby on Rails (eRuby, Haml), JavaScript (Handlebars , Pug, Underscore, Haml).

Among the independent, Mustache, Handlebars, Jade. Moreover, they are also the most used according to statistics.

For example, Django Template has a very simple syntax and its template is as follows:

My first name is {{ first_name }}.

My last name is {{ last_name }}.


{% for item in items %}

<li>Item: {{ item.name }} </li>

{% endfor %}


after the transfer to the client it looks like:

My first name is John.

My last name if Snow.

- Name 1

- Name 2

That is, using the template engine, you can easily create a page interface, and then fill it with data for each client! At the same time, the template engine supports sections, inheritance and conditions, so that the presentation can be divided not only between the code and the template, but also between several templates, which may or may not be included in the view without a single JavaScript line.

Of course, pages with templates are formed on the server side. This process is called Server Side Rendering (SSR).

SSRs and templates are easily subjected to SEO optimization, and without additional libraries and frameworks, because not all search engines can process and execute JavaScript for rendering, for example, React applications and the time of crawling (analysis) of each site is limited.

SSR has a positive effect on overall project performance perceived by user. This is especially evident on slower machines and on slow or mobile Internet. There is no need to wait until JavaScript is downloaded, processed and executed. The browser only needs to display the finished HTML immediately, without waiting for JavaScript — and the user can already read the content. Thus, the phase of “passive waiting” is reduced. After the “render”, the browser simply walks through the finished DOM, checking that it matches with what is formed for the user, and adds event listeners, if any.

SSR is used when you need maximum website performance and responsiveness for the client, but you can pay for it with additional server resources. With server rendering, the entire HTML of the page is generated. This completely eliminates the need for additional data requests from the client at the starting point of page unloading from the server.

A drop in performance can be observed only when time is spent on the formation of the first page on the server. This problem is solved by server-side caching. Further, all HTML responses to standard queries are already “known” and the response time “tends to zero”.

Of course, server rendering is not a panacea. Its work is accompanied by computational costs, the need for caching, memoization and the presence of advanced memory management systems, but allows you to extract more relevant data and respond to a more complete list of requests than with static or purely client rendering.

We will look at various types of rendering in our next articles. The only thing that can be said here is that the template-based SSR gave birth to such modern, but still less common technologies like Gatsby, Jekyll, Svelte and Metalsmith.

As a conclusion, we can say that the use of template engines is justified for small projects and start-ups, in which the first place is not the interactivity of web components, but the relevance of the data, download speed and minimization of the load on the device of the content consumer. Or, if one or two people are working alone,without the support of “pure” web programmers.