Write once, render anywhere - we use one template engine on the client and server

Introduction

All of you have probably already heard or use various template engines in everyday life, they are also template engines. We usually use them to generate HTML code. In this process, we usually have some kind of data model and HTML template that we fill with this data.
Previously, we generated the HTML pages only on the server side, and today we are increasingly doing this on the client. Demand gave birth to a proposal, and we began to increasingly see templating engines that work on JavaScript, and there are also templating engines with implementations in many languages ​​at the same time , including server ones, what opportunities it gives us, I will try to describe in this article. One example of such template engines is mustache (please pay attention to the list of implementations), which I will use for the examples in this article. Those. You can replace the word mustache in the article with the phrase “any template engine with implementation in JavaScript and your server language”.

Obvious use case

An obvious example of using such a template is, of course, the possibility of using a single template to generate HTML code on the server and client (surely, many of you had to duplicate the HTML code of blocks into javascript, and many continue to do it now). The need for this arises constantly, an example from life - twitter. When we open the twitter, the server renders the first few tweets for us, and when scrolling down using javascript, it loads the next batch and renders on the client using the same pattern . In this case, mustache is perfect in its pure form or in combination with icanhazjs . By the way, this approach in some form has already been mentioned in the Habré here and here .

Less obvious use case

There is also a less obvious example of use that I would like to elaborate on in more detail. The classic approach to the implementation of the site is to create a design, layout and writing of server code that fills the layout with data, and here there is also a place for mustache.
When the layout designer gives the layout, we usually can not use it in its pure form, because we have to fill it with server code, as a result, we have a hearty mess from HTML + <your server programming language>. The disadvantage of this approach is that since we filled the layout with server code, it becomes difficult to maintain, especially if the layout and the server part are done by different people. We can’t just overwrite the HTML files with the updated layout that the layout designer sent to us, we need to very carefully update the changes that the layout designer made.
In fact, the merge of changes is not the only problem that arises when transferring the layout to the server, I think each of you will be able to find examples from life when integration brought inconvenience.
The coder sometimes does not have to be sweet when he needs to create duplicate blocks that look a little different, and he has to copy pieces of his typesetting with these blocks, and when changing the typesetting, make changes at once in all places.
The server programmer also recalls a lot of bad words, when it suddenly turns out that the layout designer didn’t provide for the verbency of styles for some component states, or the layout was hard-coded and didn’t drag on when the data changed.
In the end, testing the layout is also very inconvenient, and almost impossible, until the server part was written for it. In this regard, a bunch of jambs, which could have been avoided, gets out after writing the server part of the application, and we start kicking the layout designer so that he corrects the layout and then the server programmer so that he can change the changes.
You can try to avoid all these negative aspects with the help of template engines like mustache, because now we have one template engine both on the server and on the client. This is not difficult to do, the layout designer needs to use instead of hard-coding the data, use mustache syntax, and then write a couple of lines of javascript code with which he can fill in his template with data. For clarity, I will give a small example:

<html> <head> <script type="text/javascript" src="mustache.js"></script> <script type="text/javascript" src="jquery.js"></script> <script> var data = { "newsCategory": "IT", "news": [ { "id": 1, "title": "Write once, render anywhere", "preview": "bla bla bla", "date": "01.01.2012" }, { "id": 2, "title": "Mustache in action", "preview": "bla bla bla", "date": "02.02.2012" } ] } $(function(){ $("body").html(Mustache.render($("body").html(), data)); }); </script> </head> <body> <h1>{{newsCategory}}</h1> <ul class="news"> {{#news}} <li> <h2>{{title}}</h2> <p>{{preview}}</p> <a class="readMore" href="/news/{{id}}">...</a> <div>{{date}}</div> </li> {{/news}} </ul> </body> </html> 

it's easy to guess that when implementing the server part we can use the same template, it is enough to exclude unnecessary javascript and use the mustache implementation for your server language (Ruby, Java, PHP, Python, Scala, etc.).
This template is very convenient to test (you do not need to copy repeating blocks to test various options for displaying them, just changing the data model), the layout designer will probably give you a better layout than with the classical approach, you can also check how good the layout is by substituting the data model in javascript your real data. Such a template can also be used off-the-shelf on the server and is easy to update when the layout is updated.
In fact, the fact that at the time of creating the template there will already be a ready-made data model provides many other, implicit advantages. Many shortcomings can be avoided at the design stage of the interface.
')

findings

Of course, the emergence of such template engines like mustache should significantly simplify the creation of modern dynamic websites, and make the process of creating them more literate and convenient. And even if one day, everyone will start writing one-page clients in javascript , mustache can still be used to generate pages for search engines on the server.
In the article, I did not describe how this approach can be used to build pages on the server and client from parts (partial, include, as you like), there are lots of nuances, I suggest discussing it in the comments.