С одной стороны, предмет действительно был квадратным. C другой стороны он был круглым. Но с третьей стороны, с которой должен быть треугольник, предмет вышел кривой и косой.  — Алешенька идет на совещанку? — в дверь просунулась Леночкина заинтересованная физиономия.
 — Алешенька на совещанку не идет. Алешенька пишет статью.
 — О кубиках?
 — Каких еще кубиках? — я опустил глаза, в руках и правда был злосчастный кубик. То есть шарик. То есть ромбик.
 — Не о кубиках! И не о шариках. О шаблонах.
 — Я им так и скажу! Шаблон, ах. — Леночка уже бежала дальше по коридору. "О шаблонах. Даже о трех разных шаблонах". Точнее, о трех причинах использовать шаблоны в серверном коде. И ни одна из этих причин не будет про HTML.  В примерах я использовал синтаксис Mustache, в силу лаконичного синтаксиса и наличия реализаций для всего, что движется. Mustache практически не позволяет себе вольностей в отличии от, например .Net Razor, который позволяет кодировать внутри шаблона, подавая тем самым плохой пример некрепким духом разработчикам.  Примеры кода будут на python. Реализация Mustache под пайтон называется pystache.  Итак, три причины впустить шаблоны в свою жизнь свой код. Если у вас есть система, внутри которой существует какие-то данные — например, данные в реляционной базе или данные, получаемые через вызовы API, иногда требуется создавать на основе этих данных артефакты.  Артефактом может быть, например, JSON или plain text файл, вложение, HTTP-респонс. Главное — артефакт по сути своей результат применения функции от некоторой относительно компактной части данных вашей системы. И артефакт имеет свой собственный синтаксис. Артефактом может быть выписка из банковского счета в текстовом формате для загрузки в legacy систему. Артефактом может быть выгрузка электронного чека в виде .json файла, который будет отправлен как вложение клиенту по почте.  Во всех этих случаях вы себе сильно упростите жизнь, используя шаблоны для создания артефактов.  Что такое шаблонизатор? Это библиотека, которая примет объектную модель (контекст), возьмет шаблон, применит одно к другому — и выдаст результат. Объектную модель и шаблон готовит программист. Итоговый результат готовит шаблонизатор. Пример: попробуем создать текстовое сообщение о заказе. Подготовим сначала объектную модель: Код сугубо заглушечный. В реальном коде может быть запрос базы данных, какая-то логика расчета значений (например, значение total.amount вычисляем на основании позиций заказа).  Обратите внимание на несколько вещей: Текст шаблона mustache выглядит так: Мы видим в шаблоне, что шапка документа для заказов в Урюпинске отличается от других городов. Мы также видим, что в конце последней строки с товарной позицией стоит точка, а во всех ранних позициях — точка с запятой. За это отвечает атрибут "comma" и метод "add_comma" в генераторе моделей. Код, который применяет контекст к шаблону, тривиален: Результат: Еще совет: если задача позволяет, сохраняйте вместе с зарендеренным шаблоном саму модель (например, в JSON формата). Это поможет при отладке и траблшутинге. Принтер трижды пискнул, выдавая новую модельку. Треугольная сторона была теперь идеальным треугольником. Две остальные стороны были квадратными. Нейронная сеть жила своей жизнью и отказывалась выдавать примитивную по всем понятиям 3д модельку. "Подарю Леночке кубик." — подумал я. Пусть радуется. Вам может потребоваться создавать JavaScript в рантайме изнутри backend-а. Зачем? Для создания отчетов на стороне браузера, например. Или получить скрипт на F# изнутри программы на Go. Или Kotlin-овский код изнутри ReactJS (не могу представить, зачем это может понадобится, но вдруг у вас такие специфические наклонности). В случае с кодогенерацией, лучше сначала написать руками результирующий код (то что мы хотим сгенерировать) а только потом разбить его на шаблон и модель. Этот подход избавит нас от тоски излишней сложности модели. Модель усложнить никогда не поздно, но лучше начать с простого. Здесь мы видим, что у нас на странице есть от одного до N графиков lineChart, у каждого из которого свой источник данных, заголовок и список показателей. Моделька: ну и шаблон: Обратите внимание: такой "в лоб" подход к шаблонизации требует отдельного усилия по экранированию значений в модельке. если в series[0].title у нас прокрадется запятая или кавычка — "Hello Kitty\"" — синтаксиc результирующего файла с треском развалится. Поэтому пишите функции экранирования и используйте их при создании моделей. Используйте форматтеры, если шаблонизатор это умеет.  Третий кубик полетел в дверь и со стуком отскочил. Тоже никуда не годится. Интересно. а можно кинуть кубик так, чтобы он проскочил под дверью и долетел до конца коридора? Можно ли 3д-печатать резиной? Или лучше сделать его наполненным маленькими такими икосаэдрами, наполненными воздухом?... Придирчивый читатель скажет, что это тоже кодогенерация, трансляция концепций из одного языка программирования в другой. На что мы ответим придирчивому читателю, что работа с SQL или с любым другим языком запросов к БД — это немного отдельная область программирования и не всем очевидно, что если шаблонами можно генерить js скрипты, то и SQL тоже можно. Поэтому вынесем запросы в отдельный кейс. И чтобы придирчивый читатель не скучал, оставим в статье только примеры нескольких запросов. Можете сами прикинуть, какая модель и какой шаблон тут лучше подойдут. В примерах на гитхабе можете посмотреть, что у меня получилось. Шаблоны (в том числе и для SQL) и примеры кода можно найти на гитхабе.