Der Template-Engine Vergleich: Blade vs Smarty

Da ich mich in letzter Zeit verstärkt mit dem Laravel Framework auseinandergesetzt habe, kam mir die Idee zu einem Vergleich der Template-Engine Blade mit Smarty. Smarty wird seit jeher in vielen Webprojekten genutzt, hier eine Liste mit CMS, die Smarty einsetzen. Gleich der Disclaimer: Blade lässt sich nicht ohne weiteres unabhängig von Laravel Framework einsetzen. Im folgenden geht es mir eher um ein paar grundsätzliche Gedankengänge, warum überhaupt eine Template-Engine. Und um das Bild abzurunden fehlt hier sicherlich Fluid Template Engine der CMS aus dem Hause Typo3.

Wie alle begann: PHP als Template Engine
PHP als Template-Engine ist eine zweischneidige Sache. Aus der Praxis lässt sich sagen, dass die gemischten HTML-PHP-Files ein echter Wartungs-Alptraum sind. Ein wichtiges Argument gegen PHP in Templates wäre die Lesbarkeit für Menschen. Die permanenten eckige Klammern sind wie ein Frontalangriff auf die Augen. Dazu gibt es das ewige Problem, ob ich HTML Tags mit PHP bestandteilen ausgebe oder direkt ein HTML-Element als Variable mit dem Sprachkonstrukt echo ausgeben lasse.
<a href="<?php echo $linkUrl;?>">Mein Link</a>
oder
<?php echo '<a href="'.$linkUrl.'">Mein Link</a>'; ?>
Beides ist möglich und beides wirkt in Templates einfach furchtbar.

Anbei der Screenshot aus einem WordPress-Template:
wordpress source
Mein Gehirn benötigt viel zu lange, um zu erfassen, was in diesem File eigentlich passiert.
Vielleicht auch auf diese Formel herunter gebrochen: Sobald ich in der Präsentationsschicht der Applikation bin (also was im MVC Pattern dem View entspricht), möchte ich möglichst wenig PHP sehen.

PHP als Template-Engine: nein.

Blade macht sich als Template-Engine dann doch sehr gut. Es ist eine Vererbung implementiert und eigentlich alles soweit drin, was man in der Praxis für Templates benötigt. Mir fiel z.B. auf, dass ich eine Weitergabe der Variablen im includierten View benötigt hätte. Das geht, und so kann ich quasi einen Sub-View mehrfach einbinden mit @include und entsprechend Variablen nur in diesen Kinds-View mitgeben. Praktisch etwa bei Artikellistings.

Template Engine? Ja, aber bitte so wenig wie möglich davon
Eigentlich passt das auch genau so, da man heute viel Funktionen in serverseitigen Template-Engines einfach nicht mehr benötigt. Smarty-Plugins? Ganz ehrlich, habe ich nie benutzt. Es ist in den meisten Fällen vermutlich effizienter direkt mit einem Plugin PHP-seitig entsprechend Daten umzuformatieren. Zumal der Bedarf dafür auch zunehmend schwindet.
Der Ansatz, serverseitig etwa Artikeltexte zu kürzen und Anzahl von Boxen pro Spalte festzulegen, ist in Zeiten von Responsive Design überholt. All das wird sich in den Browser zu Javascript und CSS3 verlagern. Die Shopsoftware Shopware berechnet beispielsweise das HTML bestimmter gerasterter Seiten noch per Smarty. Vor 2 Jahren hätte man das noch so abgenickt, heute wirkt dieses Vorgehen wie ein Relikt aus einem vergangenen Zeitalter. Mit CSS3 und Javascript hat man inzwischen browserseitig so viele Möglichkeiten, dass vieles in Template-Engines überholt wird. Etwa das erste oder letzte Element einer Liste kennzeichnen zu lassen. Oder die Anzahl von Elementen pro Reihe durchzählen zu lassen. Was nur Sinn macht, wenn diese Anzahl schon serverseitig festgelegt ist und sich nicht wie im Responsive Design je nach Bildschirmgröße permanent ändern kann.

All das gibt es bei Blade nicht. Blade kommt sehr einfach daher, wo man bei Smarty eher den Eindruck hat, dass jede Menge Altlasten mitgeschleppt werden. Das muss man allerdings zur Verteidigung auch sagen: Smarty hat schon ein paar Jährchen auf dem Buckel und entsprechend einer Pfadabhängigkeit und Abwärtskomptabilität werden ganz alte Sprachbestandteile mitgeschleppt.

Ein Klassiker ist für mich dabei die foreach-Schleife. Wenn des eine Hitliste der meistgenutzten Funktion gibt in Programmierung, dürfte foreach ein heißer Anwärter auf einen der vorderen Plätze sein. Und das wurde extrem umständlich umgesetzt. In Smarty 2.x lautete dann der Aufruf:

{foreach key=schluessel item=kontakt from=$kontakte}

Das ist reichlich weit weg von PHP und wozu item und der optionale key-Parameter wirklich nützlich sein sollen, erschloss sich nie. Inzwischen ist Smarty mit der v3 näher an PHP und der Aufruf lässt sich auch realisieren mit


{foreach $kontakte as $kontakt}
{$kontakt.name}
{/foreach}

Siehe Doku Smarty 2 zu Smarty 3

In Blade dagegen heisst es dagegen von Anfang an einfach:


@foreach ($users as $user)
<p>This is user {{ $user->id }}</p>
@endforeach

Siehe Laravel Template Doku

Und das finde ich extrem einfach zu lesen und praktisch. Ich bin im foreach-Loop und kann einfach auf meine Daten zugreifen. Direkt von Anfang an.

Das Gute an Blade ist, dass es so wenige Funktionalitäten zur Verfügung stellt. Ich muss mich nicht erst an die Syntax gewöhnen. Gegenbeispiel SMARTY, wo mit Smarty 2 eine umständliche Syntax z.B. für die Deklaration von Variablen eingeführt wurde. Oder zum Zugriff auf Arrays und Objekte mit dem Punkt-Operator.

Im Unterschied zu Smarty besitzt Blade keine eigenen Variablen sondern ist basiert auf den PHP-Variablen. Blade-Files sind quasi PHP-Files, in denen alternativ die Blade oder die PHP-Syntax verwendet werden kann.
Insofern muss ich auch nicht in der Doku nachschlagen, wie viele Parameter die Blade-interne strtolower Funktion hat oder mir den Kopf zerbrechen wie ich verschiedene String-Funktionen verkette (was in Smarty ein echter Alptraum ist). Blade ist pures PHP unter der Haube und so kann ich dann auch auf meine Variable etwa strtolower($meineVariable) anwenden. Alles in die Blade-Klammern zur Ausgabe gepackt – fertig. Wenn es mir die Funktionen je nicht ausreichen, kann ich einfach ganz reguläres PHP in den Templates verwenden. Bei Smarty sind die {php} Blocks dagegen meist schlechter Stil und auch nur bedingt sinnvoll, da beim Kompilieren der Templates die Variablen aus dem Smarty-Objekt erst wieder in PHP rückverwandelt werden müssen.

Dazu kommt ein grundlegendes Bedenken: wenn Software-Architektur vernünftig umgesetzt wurde, sollten in der Präsentationsschicht der Daten eigentlich auch keine großen Änderungen mehr erfolgen. Wenn in die Smarty-Templates dann allen Ernstes SQL-Abfragen gecodet werden, läuft etwas falsch (und ein Programmierer hat seinen Beruf verfehlt).

Und um an dem Punkt zu bleiben: für Programmierer, die das Frontend beackern, ist Smarty bedingt gut. Früher wurde noch die {debug}-Konsole eingesetzt, die in einem Popup-Fenster dem Entwickler (sowie allen Besuchern etwa eines xt:commerce Webshops) die Variablen ausgab. Heute werden Browser Plugins wie FirePHP oder Developer Companion eingesetzt, um die Variablen zu debuggen. Aus der Praxis: es geht, ist aber nicht besonders komfortabel. Bei großen Arrays ist es hier recht mühseelig, sich die entsprechenden Keys ausgeben zu lassen, da ich bei jedem Page Reload mich mühseelig durch die GUI klicken muss. In Blade habe ich dagegen direkt Zugriff auf die PHP-Variablen und kann mir diese bequem in ein Logfile wegschreiben oder diese direkt im Browser dumpen.

In einer Diskussion im Laravel Forum zu Blade und Template-Engines allgemein meinte ein Teilnehmer: „Blade is just a fast regex parser“. Die .blade.php Files werden durch die Parser-Klasse verarbeitet und zu regulären PHP Files im Cache kompiliert.

Fazit: Blade stellt wenige, aber sehr effektive Befehle zur Verfügung, die PHP im Template ersetzen.

2 Antworten zu “Der Template-Engine Vergleich: Blade vs Smarty”

  1. Was soll das Rumgehacke auf der Smarty v.2. Dein Artikel ist vom Jahr 2013. Da gab es Smarty v.3 mit der neuen Syntax schon seit 3 Jahren! Da kannst du auch gleich über Windows 3.1 ablästern. Lächerlich!

    • Voll und ganz Ihrer Meinung. Der Author vergleicht hier Äpfel mit Birnen. Wenn man außerdem schon den Syntax anspricht, sollte man auch mehr als nur eine foreach-Schleife erwähnen. Das Fazit am Ende ist auch einfach nur lächerlich – Kein einziges Wort über Smarty.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

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