Serverseitiges Templating: Jinja2 Handlebars

Serverseitige Templates erzeugen HTML auf dem Server, bevor es an den Browser gesendet wird. Sie liefern SEO-freundliches Markup bereits beim ersten Byte, funktionieren ohne JavaScript und vermeiden das Problem einer „leeren Seite, bis JavaScript geladen ist“, das beim rein clientseitigen Rendering auftritt.

Jinja2 ist die De-facto-Templating-Bibliothek für Python — sie wird von Flask, Django (über das integrierte oder das jinja2-Backend), Pelican und mkdocs verwendet. Logik steht in {% %}-Tags, Ausdrücke in {{ }}: <h1>{{ title }}</h1> für Variablen und {% for item in items %} für Schleifen.

Handlebars ist die meistgenutzte Templating-Bibliothek für Node.js und besonders bei Transaktions-E-Mails (SendGrid, Mailgun) sowie SSR mit Express beliebt. Ausdrücke stehen in {{ }}, Blöcke in {{# }}: {{#each items}}<li>{{name}}</li>{{/each}}.

Beide Engines maskieren Variablenausgaben standardmäßig automatisch — {{ user.name }} mit name = "<script>" gibt "&lt;script&gt;" aus und neutralisiert dadurch XSS. Verlassen Sie sich immer auf das automatische Escaping; verwenden Sie den expliziten Raw-Filter (Jinja: {{ x|safe }}, Handlebars: {{{x}}}) nur für vertrauenswürdiges HTML.

Jinja: {% extends "base.html" %} im untergeordneten Template und {% block content %}{% endblock %} im Basis-Template. Handlebars: {{#> layout }}{{/layout}} mit Partial-Blöcken. So kann ein Basis-Layout die Struktur einmalig definieren; Seiten füllen die variablen Bereiche aus.

Jinja: {% include "header.html" %}. Handlebars: {{> header}}. Beide binden ein weiteres Template in das aktuelle ein. Partials sind die Bausteine großer Komponentenbibliotheken – sie werden zu Seiten und Layouts zusammengesetzt.

Jinja-Filter: {{ price|currency }}. Handlebars-Helper: {{currency price}}. Beide ermöglichen den Aufruf von Formatierungsfunktionen für Werte. Definieren Sie eigene Helper für projektspezifische Transformationen, etwa zur Datumsformatierung, Pluralbildung oder Link-Erzeugung.

Jinja: {% if user.is_logged_in %}Welcome{% else %}Sign in{% endif %}. Handlebars: {{#if user.isLoggedIn}}Welcome{{else}}Sign in{{/if}}. So können Templates anhand von Daten verschiedene Zweige verwenden, ohne auf clientseitiges JS zurückzugreifen, um Inhalte ein- oder auszublenden.

Beide Engines kompilieren Templates vorab zu Funktionen und rufen diese Funktionen anschließend für jede Anfrage auf. Die Kompilierung erfolgt einmalig, das Rendering ist schnell. Bei Websites mit sehr hohem Datenverkehr sollte das gerenderte Ergebnis am Edge (Varnish, Cloudflare) zwischengespeichert werden, statt identische Seiten erneut zu rendern.

Kombinieren Sie Templates mit i18n-Bibliotheken: Jinja2 + Babel für Python, Handlebars + i18next für Node. Templates enthalten Übersetzungsschlüssel ({{ t "welcome" }}); die i18n-Schicht löst sie in die passende Sprache auf. So kann ein Template in vielen Sprachen gerendert werden.

Moderne Frameworks bringen eigene Template-Formate mit: ERB (Rails), Twig (Symfony), Blade (Laravel), Razor (.NET), Slim/Haml (kompakter). Die Muster sind gleich, die Syntax unterscheidet sich. Wählen Sie die Engine, die zu Ihrer Backend-Sprache und Ihrem Ökosystem passt.

Templates eignen sich hervorragend für herkömmliche serverseitig gerenderte Websites. Bei interaktiveren Apps verwischen Frameworks wie Next.js (React), Nuxt (Vue) und SvelteKit die Grenzen: Sie rendern Templates auf dem Server, aber dieselben Komponenten werden auf dem Client hydriert und dadurch interaktiv.

Warum ist Auto-Escaping in Templating-Engines wie Jinja2 und Handlebars standardmäßig aktiviert?

Serverseitige Templating-Engines (Jinja2 für Python, Handlebars für JS, ERB/Twig/Blade für andere Stacks) erzeugen auf dem Server mithilfe von Variablen, Schleifen, Bedingungen, Partials und Vererbung HTML. Auto-Escaping schützt standardmäßig vor XSS. Kombinieren Sie die Engines für mehrsprachige Websites mit i18n-Bibliotheken. Templates bilden die Grundlage; moderne Frameworks setzen darauf Hydration auf.