Zum Inhalt springen
clausvb.de

Template-Engines im Vergleich

vlibTemplate, Smarty, TinyButStrong und Twig nebeneinander: Syntax, automatisches Escaping, Wartungsstand, Lernkurve und Laufzeitverhalten – mit einer klaren Empfehlung je Ausgangslage.

Zuletzt geprüft: Gedacht für: Entscheidung zwischen Engines

Das Wichtigste

  • Automatisches Escaping ist das einzige Merkmal mit direkter Sicherheitswirkung. Nur Twig bringt es ab Werk mit.
  • Alle vier Engines kompilieren nach PHP. Der Laufzeitunterschied ab dem zweiten Aufruf ist in realen Anwendungen nicht der Engpass.
  • Für Bestandsprojekte ist die Wartbarkeit der bestehenden Lösung fast immer wichtiger als der Funktionsumfang einer neuen.
  • Bei Office-Vorlagen (DOCX, XLSX) gibt es zu OpenTBS praktisch keine gleichwertige Alternative.

Der Vergleich hilft nur, wenn er die Ausgangslage einbezieht. Für ein leeres Projekt sieht die Antwort anders aus als für ein gewachsenes System mit dreihundert Templates.

Gegenüberstellung

vlibTemplateSmartyTinyButStrongTwig
Syntax im Template{VAR} + Kommentar-Blöckeeigene Sprache {$var}[feld] in gültigem HTMLeigene Sprache {{ var }}
Logik im Templatefast keineumfangreichbegrenztumfangreich
Automatisches Escapingneinoptional (escape_html)optional (Voreinstellung)ja, ab Werk
Template-Vererbungneinja ({extends})neinja, ausgereift
Kompilierungjajajaja
Ausgabe-Cachingeinfachausgereiftnein (extern lösen)über HTTP-Cache
Editorunterstützungkeinevorhandengeringsehr gut
Office-Vorlagenneinneinja (OpenTBS)nein
Lernkurvesehr flachmittelflachmittel

Das eine Merkmal, das wirklich zählt

Automatisches Escaping ist der einzige Punkt in dieser Tabelle mit direkter Sicherheitswirkung. Ohne es ist jede vergessene Kennzeichnung eine mögliche XSS-Lücke, und “wir denken dran” ist über Jahre und wechselnde Beteiligte keine tragfähige Zusage.

Twig escapet standardmässig. Smarty und TBS können es, wenn man es einschaltet – bei einem Bestandsprojekt ist das ein Durchgang durch alle Templates, weil vorhandene manuelle Escapes dann doppelt greifen. vlibTemplate kann es gar nicht; dort hilft nur ein eigener Wrapper um die Setter.

Laufzeit: der Vergleich, der meist falsch geführt wird

Alle vier Engines übersetzen das Template beim ersten Aufruf in PHP-Code und legen ihn ab. Ab dem zweiten Aufruf läuft also in allen Fällen kompilierter PHP-Code. Die verbleibenden Unterschiede liegen in einem Bereich, der neben einer einzigen Datenbankabfrage verschwindet.

Praktisch relevant sind stattdessen:

  • Wird der Kompilat-Cache überhaupt genutzt? Ein nicht beschreibbares templates_c lässt Smarty bei jedem Request neu kompilieren. Das ist der Unterschied, den man misst.
  • Wie viele Templates werden pro Seite eingebunden? Fünfzig Includes kosten fünfzig Dateizugriffe.
  • Wird die Ausgabe gecacht? Das ist eine Grössenordnung mehr als jede Engine-Optimierung.

Empfehlung nach Ausgangslage

Neues Projekt, freie Wahl. Twig. Automatisches Escaping, gute Vererbung, breite Werkzeugunterstützung, und in Symfony oder Drupal ohnehin vorhanden.

Bestandsprojekt mit Smarty. Bleiben. Auf eine aktuelle Smarty-Version heben, escape_html einschalten und die Templates einmal durchgehen. Das ist deutlich weniger Aufwand als eine Migration und bringt den entscheidenden Sicherheitsgewinn.

Bestandsprojekt mit vlibTemplate. Prüfen, ob die Engine auf der Ziel-PHP-Version läuft. Wenn ja: Wrapper mit erzwungenem Escaping einziehen und weiterlaufen lassen. Wenn nein und kein gepflegter Fork existiert: Migration planen – die Templates sind wegen der schlanken Syntax vergleichsweise leicht zu übertragen.

Templates werden von Designern gepflegt. TinyButStrong, wenn die Dateien in visuellen Editoren geöffnet werden sollen. Sonst Twig, dessen Syntax auch von Nicht-Entwicklern schnell gelesen wird.

Dokumentvorlagen für Word oder Excel. OpenTBS. Hier gibt es keine gleichwertige Alternative, und für diesen Zweck lohnt es sich, TBS zusätzlich zur Haupt-Engine einzusetzen.

Sehr kleines Projekt, eine Person. Pures PHP mit alternativer Syntax. Dann aber konsequent jede Ausgabe durch htmlspecialchars – am besten über eine Kurzfunktion, damit es nicht bei jedem <?= eine Entscheidung ist.

Migration realistisch planen

Wer migriert, sollte vorher drei Zahlen kennen: Anzahl der Templates, Anteil mit Bedingungen oder Schleifen, Anzahl eigener Funktionen und Modifier. Reine Platzhalter-Templates lassen sich weitgehend mechanisch übertragen. Templates mit Logik brauchen eine Einzelprüfung, und eigene Modifier müssen in der Zielsyntax nachgebaut werden.

Der Weg, der sich bewährt hat: beide Engines parallel betreiben, neue Seiten in der neuen Engine bauen, alte nur bei ohnehin anstehenden Änderungen übertragen. Und ein festes Enddatum setzen – ohne das bleibt der Zwischenzustand jahrelang bestehen.

Häufige Fragen

Welche Engine ist die schnellste?

Die Frage führt in die Irre. Alle vier kompilieren Templates nach PHP und cachen das Ergebnis; ab dem zweiten Aufruf liegt der Unterschied im Bereich von Mikrosekunden. Die Antwortzeit einer echten Anwendung entsteht in Datenbankabfragen und externen Aufrufen, nicht im Template.

Ist Twig immer die richtige Wahl?

Für neue Projekte in der Regel ja. Für ein Bestandsprojekt mit funktionierender Engine, für Office-Vorlagen und für Teams, die eine andere Syntax seit Jahren beherrschen, gibt es gute Gegenargumente.

Was kostet eine Migration realistisch?

Der Aufwand skaliert mit der Anzahl der Templates und dem Anteil an Logik darin. Als grobe Orientierung: reine Platzhalter-Templates lassen sich weitgehend mechanisch übertragen, Templates mit vielen Bedingungen und eigenen Funktionen brauchen eine Einzelprüfung. Ohne vollständige Abnahme jeder Seite ist die Migration nicht fertig.

Kann ich zwei Engines parallel betreiben?

Technisch ja, und bei einer schrittweisen Migration ist es der übliche Weg: neue Seiten in der neuen Engine, alte laufen weiter. Der Dauerzustand ist es nicht wert – zwei Syntaxen im selben Projekt kosten bei jeder Änderung Aufmerksamkeit.

Weiterlesen