Über den Sinn und Unsinn einer PHP Template Engine

Vor ein paar Tagen erschien auf dem YouTube Kanal von Vitalij Mik ein Video über PHP Template Engines, welches recht schnell sehr polarisierende Reaktionen in den Kommentaren hervor rief. Augenscheinlich scheint der Einsatz von PHP Template Engines in der Community ein sehr konfliktbehaftetes Thema zu sein. Ich werde mal versuchen zu erklären, warum der Einsatz von Template Engines aus meiner Sicht so überhaupt keinen Sinn ergibt und eher von schlechtem Stil, als von Können zeugt.

Was ist eine Template Engine eigentlich?

Um es mal stark vereinfacht zu formulieren: Eine Template Engine ist eine Art Adapter für die Präsentationsschicht und verspricht einfacheres Handling von Daten innerhalb eines Templates. Oftmals implementiert eine Template Engine eine eigene Syntax, die über die Logik der Template Engine in sauberes PHP übersetzt wird.

<h1>{$title}</h1> 
<ul>
    {foreach item=item from=$items}
    <li>{$item}</li>   
    {/foreach}
</ul>

Das gezeigte Code-Beispiel zeigt die Implementierung einer einfachen foreach-Schleife in der Syntax der Smarty Template Engine.

<h1><?= $title ?></h1>
<ul>
    <?php foreach ($items as $item): ?>
        <li><?= $item ?></li>
    <?php endforeach; ?>
</ul>

Das zweite Code Beispiel zeigt die gleiche foreach-Schleife in einem HTML Template mit PHP umgesetzt.

Welche Vorteile hat eine Template Engine

Welche Vorteile bringt der Einsatz einer Template Engine, wie z.B. Twig , Mustache oder Smarty mit sich? Relativ häufig liest man folgende Punkte, die den Einsatz einer Template Engine rechtfertigen sollen:

  • Saubere und einfachere Syntax innerhalb eines Templates
  • Der Zwang die Business Logik von der Präsentation trennen zu müssen
  • Implementierung von sicherheitsrelevaten Funktionen, wie z.B. das Escaping von Werten bevor sie ausgegeben werden

Weitere Vorteile wollen mir jetzt einfach nicht einfallen. Falls ihr noch relevante Vorteile kennt, die für den Einsatz einer Template Engine sprechen, schreibt sie gern in die Kommentare.

Gibt es auch Nachteile?

Gut, vielleicht bin ich ein wenig voreingenommen. Aus meiner Sicht ist der Einsatz von Template Engines in den wenigstens Szenarien ein Vorteil. Hier mal ein paar Punkte, warum dies so ist:

  • Eine zusätzliche Syntax muss erlernt werden, obwohl PHP von Beginn an den Anspruch mit sich brachte selbst eine Template Engine zu sein
  • Eine zusätzliche Logik wird implementiert, die die Resourcen belastet. Der Speicherverbrauch und die Ausführungszeit werden zu Gunsten einer Logik belastet, die niemand benötigt. Zusätzliche Software muss auf dem aktuellen Stand gehalten und getestet werden.
  • Wenn Template Engines dazu eingesetzt werden die Business Logik von der Präsentation zu trennen, liegt das Problem eher beim Entwickler, der das Prinzip Seperation of Concerns nicht verstanden hat.

Ja, zugegeben klingt das ein bisschen offensiv. Die Nachteile liegen aber auf der Hand.

Oftmals wird tatsächlich gesagt, dass der Einsatz einer Template Engine Vorteile für die Designer mit sich bringt, die dann einfach Teile des Templates an der Stelle verwenden können, an der sie tatsächlich benötigt werden. Ob der Designer jetzt einen foreach-Block lesen kann, der mit PHP oder mit Smarty geschrieben wurde, ist aber vollkommen irrelevant. Fakt ist, dass der Designer immer eine Syntax beherrschen muss. Wenn er sich Smarty oder Twig aneignen kann, kann er sich auch gleich die PHP Syntax in Templates aneignen.

Viele Entwickler denken auch nicht drüber nach, dass der Einsatz einer Template Engine auch immer Resourcen frisst. Natürlich leben wir heute in einer Zeit, in der der Grundsatz, dass Anwendungen so performant wie möglich sein müssen, durch große Arbeitsspeicher und performantere CPUs ein wenig relativiert wurde. Dennoch ist es aus meiner Sicht unsinnig eine Logik zu implementieren, die eine eigene Syntax bereit stellt, um diese dann während der Laufzeit wieder in reines PHP zurück zu interpretieren. Dann kann man Templates auch gleich mit PHP schreiben und auf diese ganze Ruminterpretiererei verzichten. Zudem schafft man sich auch immer ein zusätzliches Modul an, welches aktualisiert und getestet weden muss. Template Engines kosten am Ende eines Tages also bares Geld. Template Engines sind in keinem Fall eine Erleichterung. Für niemanden. Weder für den Designer noch für den Entwickler. Natürlich könnte man jetzt sagen, dass die Laufzeitprobleme durch Caching und sonstige zusätzliche Mechanismen gelöst werden könnten. Das alles sind aber nur Hilfsmittel, die man ohne den Einsatz einer Template Engine nicht brauchen würde.

Kommen wir zu dem Punkt, den ich als größte Krücke von PHP Template Engines sehe. Der große, so gut klingende Vorteil, dass man gezwungen wird Business Logik von der Präsentation zu trennen. Der Vorteil, der so hübsch klingt, aber keiner ist. Wenn ein Entwickler eine Template Engine benötigt, um die Business Logik von der Präsentation zu trennen, sollte man das Problem dahinter auch klar adressieren. Der Schwachpunkt ist da eher der Entwickler, der darin endet, dass er Business Logik in sein HTML Template schreibt. Davor wird ihn auch keine Template Engine retten. Denn alle gängigen Template Engines ermöglichen dem Entwickler Business Logik in sein Template zu implementieren. Es wäre weitaus sinnvoller den Entwickler an diesem Punkt noch mal an die Hand zu nehmen und ihm die Basics im Sinne von Seperation of Concerns zu erklären.

Fazit

So hart das jetzt klingen mag. PHP Template Engines haben sich selbst überlebt. Man benötigt sie einfach nicht oder nicht mehr. PHP war von Anfang an auch als Template Engine gedacht, die man leicht erlernen kann. Seitdem hat sich PHP weiter entwickelt. Gängige Software-Paradigmen gelten eben auch für die Entwicklung mit PHP. Wenn ein Entwickler verstanden hat, dass man Business Logik von der Präsentation zu trennen hat, bin ich mir sicher, dass eine Template Engine nur noch als Einschränkung empfunden wird, die keinerlei Mehrwert bietet.

7 Gedanken zu „Über den Sinn und Unsinn einer PHP Template Engine“

  1. Sorry, aber da bin ich völlig gegenteiliger Ansicht! Ein Template Engine macht in jedem Falle viel Sinn! Nicht nur, wie im simpelsten Fall bei Word-Serienbriefen, sondern erst recht bei recherchierenden Web-Anwendungen: Ich mache eine Suche (via select * from …) und bekomme eine Anzahl Ergebnisse mit je einer Anzahl variable=wert Ergebnissen. Ob ich das nun in einer „Details“-Page oder in Übersichten oder in Medium-Detailed-Ergebnissen ausgebe, ist völlig Wurscht, da die Präsentation reines html ist. Und die Trennung zwischen Präsentation und Code ist von daher nützlich, da ich sowohl im laufenden Betrieb die Datenbank erweitern kann, als auch die html-Präsentation austauschen kann ohne dass Fehler oder Stillstand entstehen!
    Mit freundlichen Grüßen aus Bochum
    Und DIESE Website funktioniert nicht, da die Knöpfe weg sind wenn man zu viel Text eingibt! Ganz schlechte Programmierung!!!

    Antworten
    • Hey Dieter,

      ich kann Dir da nicht zustimmen. Ich verstehe Deinen Einwand. Aber grundsätzlich gilt immer die Logik von der View Schicht zu trennen. Dieser Grundsatz hat aber relativ wenig mit einer Template Engine zu tun. SQL Statements gehören in ein Repository, oder um es weitläufiger auszudrücken: in die Business Logik. Die View Schicht verarbeitet lediglich die zuvor ermittelten Daten. Mir persönlich ergibt sich mittlerweile der Sinn hinter PHP Template Engines nicht mehr. Wenn ich meine Anwendung gut programmiert habe, ist es sehr viel performanter eine einfache PHP foreach-Schleife in meinem Template auszuführen, als eine Template Engine einzubinden, die eine zusätzliche Syntax integriert, die dann von der Template Engine wieder zurück in natives PHP übersetzt wird. Wieso dann nicht gleich PHP? Ich bleibe dabei: Template Engines bleiben unnötig.

      Achso ja … als versierter Developer wirst Du sicherlich festgestellt haben, dass das hier eine WordPress Installation ist. Ja, zugegeben – das Template ist etwas in die Jahre gekommen. Dieser Kritik nehme ich mich an. Dafür, dass DIESE Website aber NICHT!!! funktioniert, hast Du trotzdem einen ganz akzeptablen Kommentar abgegeben. 😉 Wenn ich Zeit finde, werde ich ein neues, aktuelleres Template kaufen, so dass die Seite hier in einem neueren, „funktionierenderem“ Design erscheint. Versprochen. Ohne zig Ausrufezeichen.

      Antworten
      • Oups, es gibt ja eine Antwort – hab ich erst mitbekommen, als ich eine eMail bzgl. des nächsten Beitrages bekam…

        Ich muss mich da etwas relativieren, denn ich bezog mich nicht auf PHP-Anwendungen mit PHP-Template Engines, ich meinte eher den grundsätzlichen Gebrauch von Template Engines in großen, generischen Anwendungen, wie z.B. ebay oder Amazon.
        Da ergänzt man seinen „Datenhorizont“ durch neue „Perspektiven“ in beliebigen Datenbank-Tabellen mit Eltern-Kinder-Verpointerung und stellt der Auflistung oder des Einzelexemplares der Präsentationsebene über eine Template Engine ALLE entsprechenden Daten zur Verfügung, und dort, ggf. auf html-Ebene wird mal eben ein weiterer Link mit relativen Daten dieses Exemplares hinzugefügt. Ohne, dass „der Laden stillsteht“.

        Ich, der versierte – und alte – Developer habe so etwas vor nicht ganz 20 Jahren in Java mit stringtemplate als TE und dem üblichen Javascript erstellt. Inzwischen mach ich nur noch kleine Sachen Hobby-mäßig auf nem PC mit VB oder nem Raspberry mit PHP und Python.

        Begonnen habe ich das Programmieren 1968 mit Focal, Basic und Fortran auf Rechnern von IBM und Digital Equipment. Später wurde es dann C und Java auf Unix und VC und VB auf dem PC. Ohne überheblich wirken zu wollen: Ich habe Plattformen kommen und gehen gesehen. Und mit ihnen Abteilungsleiter, die sich für neue kehrende Besen gehalten haben und sich nichtmals als harte Borste erwiesen …

        Rückblickend muss ich sagen, eine Template-Engine erleichtert einem das modulare Arbeiten sehr, gerade in Verbindung mit (inzwischen) schnellen Interpretern, die es z.B. über eval() gestatten, beliebigen Code einer Anwendung im laufenden Betrieb hinzuzufügen.

        Also mein Fazit: Die Nutzung einer Template Engine ist in großen generischen Applikationen in einem großen wachsenden Datenhorizont mit schnell zu ändernder und individuell konfigurierbarer Präsentation unerlässlich. (Zack, und ohne zig (3) Ausrufezeichen)

        Mit freundlichen Grüßen

  2. Da soll man auch einen anderen Aspekt sehen: Templates verfügen nur über die Informationen mit denen die beliefert werden. Innerhalb des Templates kann man nicht z.B. DB auslesen und Daten zu „var_dump“-en ist auch nicht möglich. In Teams, wo Templates nicht von Entwickler erstellt werden ist ein Template-Engine ein Muss. Noch ein gutes Feature ist die Vererbung von Templates.

    Antworten
    • Hi Alexander,

      danke für Deinen Kommentar. Lass mich auf die verschiedenen Punkte eingehen, die Du in Deinem Kommentar genannt hast.

      Templates verfügen nur über die Informationen mit denen die beliefert werden

      Brauche ich dafür eine Template Engine oder muss ich nicht einfach nur ein disziplinierter Entwickler sein, der sich an verschiedene Grundsätze des Programmierens hält? Das, was Du hier beschreibst, ist einfach der Grundsatz Separation of Concerns. Oder um es etwas konkreter zu sagen: Business Logik gehört nicht ins Template. Wenn ich sauber programmiere, wird die Business Logik vom Controller erledigt und dem entsprechend werden nur Daten ausgeliefert, die für das Template relevant sind. Aus meiner Sicht benötige ich dafür keine Template Engine. Lediglich ein wenig Disziplin und ein paar Coding Standards, um diese Art von Code Qualität zu erlangen. Nur, weil man PHP Business Logik in einem Template ausführen könnte, rechtfertigt das noch lange nicht den Einsatz einer Template Engine.

      In Teams, wo Templates nicht von Entwickler erstellt werden ist ein Template-Engine ein Muss.

      Ich verstehe Dein Argument. Dieses Argument wird durchaus öfter genannt. Ich frage hier immer ganz plump WARUM? Jemand, der sich mit Templates auseinander setzt, muss zwingend HTML und CSS Standards drauf haben. Alles andere muss zusätzlich gelernt werden. Ob ich nun die Syntax einer Template Engine lerne, oder mich direkt mit simplen PHP Schleifen-Konstrukten oder if/else Bedingungen auseinander setze. Der Effekt bleibt der gleiche. Die Syntax einer Template Engine zu lernen ist genau so aufwendig, wie die Syntax von elementaren PHP Sprachkonstrukten zu erlenen. Letzteres zieht eben nur nicht den Overhead einer Template Engine mit sich.

      Noch ein gutes Feature ist die Vererbung von Templates

      Selbst innerhalb der Template Engine Gemeinde scheiden sich hier die Geister. Das Konzept dahinter ist einfachste Vererbung, um Templates zu erweitern. Braucht man das wirklich? In den letzten 15 Jahren meiner Selbstständigkeit gab es kein einziges Team, welches darauf zurückgegriffen hat. In einigen Teams war man sogar der Meinung, dass man schon weit vorher etwas falsch gemacht haben muss, um einen Use-Case von Template Vererbung zu rechtfertigen. Ja, das ist ein offensiver Standpunkt. Aber auch hier schließe ich mich an. Das ist nichts, was man mit reinem PHP nicht auch hinbekommen würde.

      Antworten
  3. Danke für den sehr interessanten Artikel. In den meisten Fällen würde ich dir 100% Recht geben. Gerade wenn man alleine oder im sehr kleinen Team arbeitet wird eigentlich keine Templates Engine benötigt, da PHP alles mitbringt, was man dafür braucht. Gerade die Short-Tags bei PHP sind genau so übersichtlich zu nutzen wie die Befehle einer Templates Sprache.

    Aber es gibt ein paar Punkte, die vor allem bei großen Projekten mit großen Teams zu tragen kommen.

    1. Templates Sprachen sind in der Regel Programmiersprache unabhängig. Wenn PHP gut ohne Templates klar kommt, kommen andere Sprachen nicht so gut klar damit. Der Frontende Entwickler kann in anderen Projekten direkt los legen ohne die Programmiersprache zu können oder gar zu kennen.
    2. Templates lassen sich dadurch leichter in anderen Projekten wieder verwenden und vereinfachen die Migration auf eine andere Sprache.
    3. Wenn man PHP im Templates zulässt, gibt man dem Frontend Entwickler Team sehr viel macht (Zugriff auf die Datenbank, etc) die man als erfahrener Backend Entwickler nicht unbedingt abgeben will.
    4. Wegen dem Overhead der Templates engine: In den meisten Frameworks ins eine Templates engine implementiert, also direkt verfügbar, das minimiert den Initialen Aufwand enorm.

    Ich bin mittlerweile auch mehr dazu übergegangen, Backend und Frontend komplett zu trennen und über eine saubere API zu verbinden, das beendet im Backend die Frage nach dem Templates.

    Antworten
    • Hey Caspar,

      danke für Deinen detaillierten Kommentar. Ich kann die von Dir genannten Punkte vollkommen nachvollziehen, möchte aber dennoch ein paar Worte dazu verlieren. Gerade bei großen Teams hat der Verzicht einer Template Engine enorm große, positive Auswirkungen auf die Kommunikation zwischen Front- und Backend Entwicklern. Die Backend Entwickler werden gezwungen sauberer zu arbeiten, so dass der Frontend Entwickler sauber struktuierte Datenmodelle geliefert bekommt, die er in seinen Templates ohne großen Aufwand anwenden kann. Zumal sich diese sauber strukturierten Datenmodelle durch das ganze Projekt ziehen. Somit wissen sowohl Front- als auch Backend, wovon sie reden, wenn sie miteinander kommunzizieren. Der Backendentwickler muss sich somit nicht mehr mit einer zusätzlichen, unnötigen Syntax einer Template Engine auseinander setzen und der Frontend-Entwickler kann seine Problematiken sehr viel einfacher schildern, da beide Entwickler die gleiche Sprache verwenden. Die Kommunikation untereinander wird eindeutiger und schneller.

      1. Genau dieses Argument kann ich in meiner Argumentationskette nicht gelten lassen. Eine PHP Template Engine bleibt immer an PHP gebunden. Dem entsprechend ist es vollkommen egal, ob ich jetzt einfachste PHP Logik in Form von Wenn/Dann Bedingungen in Templates schreibe, oder eine Syntax einer Template Engine nutze. Für den Frontend Entwickler bleibt der Aufwand der gleiche. Er muss die Syntax lernen. Vollkommen unabhängig davon, ob es nun die Syntax einer Template Engine oder eben PHP ist. Wenn der PHP Entwickler sauber arbeitet, muss er ohnehin nicht mehr als die oben genannte Wenn/Dann oder Schleifen Logik verwenden. Der Lernaufwand für die Syntax bleibt der gleiche. Einziger Benefit für den Frontend-Entwickler (Bezeichnung passt in diesem Zusammenhang heutzutage auch nicht mehr wirklich) ist, dass er auch in Projekten arbeiten kann, die auf eine Template Engine verzichten und lediglich einfache PHP Syntax in Templates verwenden.

      2. Diesen Punkt verstehe ich nicht ganz. Inwiefern vereinfacht die Syntax einer anderen Sprache – vollkommen dahingestellt ob PHP oder Engine Syntax – die Migration in eine andere Sprache? Migration im Sinne von PHP auf .NET? IF / ELSE Statements sind simpel und einfach zu verstehen. Unabhängig von der jeweiligen Programmiersprache. Mehr als Schleifen und Wenn/Dann Bedingungen gehören eh nicht in die Templates. Die Wiederverwendbarkeit von Templates ist eher ein generelles Argument. Wenn man sich in einem anderen Projekt die gleiche Template Engine ans Bein gebunden hat, kann man die Templates natürlich auch dort verwenden. Gleiches gilt aber auch für PHP Templates. Problematiken der projektübergreifenden Versionierung und Konfiguration der Template Engine mal außen vor gelassen.

      3. Das ist aber kein PHP Problem, sondern eher ein Problem der Entwickler, oder? Ich glaube ich lehne mich nicht all zu weit aus dem Fenster, wenn ich sage, dass ein Entwickler, der Business Logik in ein Template schreibt, kein guter Entwickler ist. In den Teams, in denen ich tätig war, hat man einen solchen Entwickler zur Seite genommen und geschult, da hier ganz offensichtlich ein paar Basics fehlten. Bei diesem Punkt geht es eher um Qualität als um einen Vorteil einer Template Engine. Zumal ich mit den meisten Template Engines ebenfalls die Möglichkeit habe Business Logik in den Templates auszuführen. Dieses Argument kann mit klar definierten Coding Standards und einer entsprechenden QA komplett wiederlegt werden.

      4. Auch hier widerspreche ich wehement. Bei allen gängigen PHP Frameworks werde ich vor die Wahl gestellt eine Template Engine zu nutzen, oder eben nicht. Das Laminas Framework hat auch eine View Schicht, benutzt hierfür aber PHP und keine zusätzlich eingeführte Syntax. Symfony bietet mir Twig an, zwingt mich aber nicht diese Engine zu nutzen. Laravel möchte mich gern zu Blade drängen, zwingt aber ebenso wenig wie Symfony diese Template Engine zu nutzen. WordPress („Framework“ im allerweitesten, ganz weit entfernten Sinne) baut ebenfalls auf PHP Syntax. Entweder benutze ich diese Komponente und installiere sie mir über einen Package Manager (z.B. Composer) oder lasse sie einfach weg. Die Implementierung entscheide ich als Entwickler genau so, als würde ich mich für die Implementierung einer Template Engine in einem nicht auf Frameworks basierenden Projekt dafür entscheiden. Entscheide ich mich dafür, habe ich auch den entsprechenden Overhead.

      Das Fazit bleibt meiner Meinung nach das gleiche, wie zuvor auch: Als guter Entwickler trenne ich die Business Logik von den Templates. Als guter Entwickler belästige ich den Frontend Entwickler nicht damit, dass er die ausgelieferte Datenstruktur auch noch aufwendig prozessieren muss, bevor sie im Frontend entgültig dargestellt wird. Für all das, brauche ich keine Template Engine. Was ich allerdings wirklich brauche sind Entwickler, die Datenmodelle entwickeln, die den Ansprüchen des Frontends entsprechen, so dass sie schnell und ohne Umwege implementiert werden können.

      Fakt bleibt aber auch, dass sich die Thematik mit der Einführung von JavaScript Frameworks, die gleichzeitig auch eine striktere Trennung von Front- und Backend über entsprechende APIs mit sich gebracht haben, Template Engines so oder so noch überflüssiger gemacht haben, als sie es ohnehin schon sind. Da bin ich vollkommen bei Dir.

      Antworten

Kommentar verfassen

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.