Kategorien
Template Engines … eine gute Idee?
Vor kurzem habe ich mal wieder etwas über Smarty gelesen, das ich früher wirklich häufig verwendet habe. Ich war ein echter Verfechter dieser Engine. Seit einiger Zeit habe ich die „Entwicklung“ von Smarty nicht mehr verfolgt und irgendwie würde ich meine neuen Projekte auch gar nicht mehr unbedingt mit einer solchen Technik aufsetzen. Aber warum nicht mehr?
Es gibt zwei Punkte, die ich an einer Template Engine toll finde. Erstens kann ich bestimmt, was in der View passiert. Smarty kann zum Beispiel PHP Code verbieten und somit die mögliche Logik im Template reduzieren. Meine Erfahrung dabei ist, dass man so eher noch mal nachdenkt, ob man nicht vielleicht doch zuviel Intelligenz daein gepackt hat. Schön ist natürlich auch, und da kommen wir auch schon zum zweiten Punkt, dass man dem Webdesigner alles wegnehmen kann, was er mit PHP so an Sicherheitslücken und anderem Rumgehacke einbauen kann. Wenn er Funktionalität braucht, dann muss er mit dem Backend Entwickler reden.
Nachteil der Engine ist die zusätzliche „Sprache“, die ich einführe. Smarty bringt seine eigene Syntax mit und genau in dieser muss ich meine Templates schreiben. Eine Abstraktionsebene also mehr. Die Webdesigner, die jetzt nicht mehr so viel Müll machen können, können auch so nicht mehr so viel machen, denn sie können die Smarty Syntax meistens nicht. Und eine einfache Schleife in smarty ist halt keine „einfache“ Schleife mehr. Eigentlich ist ja PHP damals auch genau für so „Templategeraffel“ gemacht worden. Wo können also die Nachteile sein?
Ich würde mal sagen, dass sich die Pro und die Contra Argumente ungefähr die Waage halten. Es kann also jeder für sich selbst entscheiden, ob er den „Umweg“ über eine Template Engine nimmt oder ob er direkt in PHP designed. Da in den meisten meiner Projekte keine Webdesigner arbeiten, gelten für mich derzeit die Pro Argumente kaum und meinen Code versuche ich auch selbst sauber zu halten. Ich weiss aber, dass das Smarty Thema eine Art Religionsfrage ist und hoffe, dass hier auch rege diskutiert wird.
Smarty wird übrigens bald in der Version 3.0 erscheinen. Ich denke mal, dass ich darüber berichten werde.
Meiner Meinung nach lohnt sich so eine abstrahierende Template Engine nur, wenn man Usern die Möglichkeit geben will, eigene Themes/Layouts zu erstellen. Dem Webdesigner/Frontend-Entwickler kann man ja genauso sagen, was er machen darf und was nicht. Wenn man Transferobjekte oder Arrays benutzt, kann er auch am System so quasi nichts kaputt machen (setXXX() save()).
Also trifft der Fall nicht ein, dass ein User selbst Templates ändern soll, so spreche ich mich glasklar für PHP selbst als Template Engine aus.
Habe bisher mit Smarty nur die besten Erfahrungen gemacht. Unsere Frontendler hier können Smarty (fast) genauso selbstverständlich wie HTML, JS und CSS. Und ehrlich gesagt ist die Syntax von Smarty nun nicht wirklich komplex und schwer zu erlernen. Für die Arbeitsteilung in größeren Projekten ist es nahezu unverzichtbar – meiner Erfahrung nach 😉
Wie gesagt, ich kann beide Meinungen verstehen. Aber vielleicht kann mich ja jemand endgültig überzeugen 🙂
Zu der Zeit als Smarty entstand, hatten wir gerade unsere erste eigene Template-Engine „gebaut“. Grund war eigentlich, dass mir Smarty damals viel zu langsam und vor allem zu unsinnig war. Es brachte mir eigentlich keine Vorteile gegenüber reiner PHP-Entwicklung. Wir haben damals mit unserer eigenen Engine auf eine Erweiterung von HTML4 mit Schleifen, Funktionsaufrufe (Module) und Variablen gesetzt.
Für mich ist heutzutage Genshi (Python) eine super Template-Engine. Zumindest vom Konzept her, da sie komplett auf XML basiert und damit keine unsinnige zusätzliche Syntax einführt. Ich kann Genshi-Templates problemlos in einer XML-Datenbank speichern, validieren und sogar dynamisch erzeugen oder bearbeiten lassen.
Wichtig an einer wie auch immer genutzten Template-Engine finde ich, dass die Templates sich irgendwie validieren lassen, dass sie einem tatsächlich Arbeit abnimmt und leicht durch eigene Funktionen/Module erweiterbar ist.
Achja… bei demobereich haben wir uns übrigens auf die Nutzung von Zend-ViewHelpern und Partials beschränkt. Ist auch eine Art Template-Verwendung, oder?
ich für eine strickte trennung, egal ob das projekt jetzt für mich alleine ist oder nicht!
ich hasse nichts mehr als dass in einem file php,js und html gemischt wird
Früher war ich auch ein Smarty-Fanboy, teilweise auch zu recht 🙂 Die Frontender mit denen ich damals zusammengearbeitet hab kamen mit der Syntax von Smarty deutlich besser zu recht als mit nativem PHP.
Irgendwann sind wir dann einmal umgestiegen auf reines PHP um in den Views die nötigen Logiken abzubilden und das tut auch problemlos. Aktuell sehe ich in Smarty und Co. keinen wirklichen Benefit mehr, eher eine Hürde im Erlernen einer zusätzlichen Syntax die irgendwo nicht wirklich viel Vorteil bringt.
Das ganze Thema ist mehr als nur eine Glaubensfrage – manchmal glaube ich wird dadurch auch ein heiliger Krieg in der Webentwicklung ausgelöst 😀
Ich finde Smarty vollkommen überflüssig. Das hat mehrere Gründe:
– Smarty Syntax oder PHP Syntax ist beides einfach
– Templates beschränken sich auf echo, for, foreach, if/else
– Template Engines in einer Template Engine sind Zeit- und Resourcenverschwendend
– werden sie oft falsch eingesetzt (Code & Design trennen? Falsch, Business Logik vom Design trennen!)
– MVC die bessere Wahl ist für die gesamte Entwicklung
Ich bereue es, Smarty in einem Projekt mal eingesetzt zu haben. Ich finde die Smarty Templates etwas unübersichtlich. Außerdem kann man in einem Smarty Skript die gemischte Verwendung von HTML, JS und CSS auch nicht vermeiden – da kommt es immer auf den Ersteller an.
Könnte man die PHP Template Skripte nicht irgendwie mit einem Code Sniffer oder so validieren und somit nur bestimmt Variablen und Funktionen erlauben? Dann hätten wir die Smarty Vorteile auch in normalen PHP Templates.
Ein großer Vorteil von smarty wurde garnicht erwähnt – das tolle Caching-System.
Meiner Meinung nach gehören in die Templates eh nicht mehr als die Ausgabe der Variablen und maximal noch eine alternierende Schleife.
Wenn mehr Code benötigt wird, wurde was falsch gemacht.
Also ich setze seit langer Zeit das PEAR ITX als Template-Engine ein. Der große Vorteil: alles HTML + HTML-Kommentare für die logische Kennzeichnung von Blöcken. Die „Logik“ steckt aber weiterhin im PHP, das entsprechend bestimmt welche Blöcke gar nicht oder sogar wiederholt angezeigt werden.
Ich möchte (wie bei Smarty) definitiv keine weitere Pseudo-Logik-Sprache verwenden, mein Ziel ist klar das HTML vom PHP ganz sauber zu trennen. Kann man mMn viel besser lesen, man kann die Anzeigelogik klar in reinem PHP nachvollziehen und es können (wichtig!) zwei Leute an jeweils demTemplate und der andere an der Logik schreiben, ohne das gleiche File zu verwenden. Das Template kann ich sogar einen HTML-Dummy geben der von Logik und PHP keine Ahnung hat, er muss mir nur Variablen-Platzhalter und Blockkennzeichnungen eintragen. Das fertige HTML kann man sogar in einem Browser anschauen ohne dass man überall Smarty-Code drin stehen hat.
Einziger Wermutstropfen: ITX ist noch PHP4 (*iiiih*), wenn jemand ein vergleichbares TS kennt bitte mir Bescheid sagen 🙂
@Roman: Das Caching von Smarty lässt sich auch mit einfachsten Mitteln nachbauen und sogar noch wesentlich optimieren. Als ich zuletzt Smarty angeschaut hatte, fehlte z.B. slientseitiges Caching komplett, es wurden keine ETags generiert und keine „304 – not modified“ Header verschickt …
Andererseits nützt einem Caching von Views so gut wie nichts, wenn die Daten alle Userbezogen sind. Man kann viel mehr Performance rausholen, wenn man Ergebnisse einer Datenbankabfrage cacht anstatt pro User & View eine Datei zu cachen.
hatte mich mal ne zeitlang mit dem thema befasst, ende der geschichte war, dass ich eine template engine als zwischenlayer nicht brauchte, weil eigentlich php ja genau für das gedacht ist, was man nochmal versucht mit einer template engine abzubilden.
Ich möchte nicht mehr auf Smarty verzichten wollen.
Die klare Trennung von Programmierung und Designer, sowie die Erleichterung für multisprachfähige Seiten durch conf Dateien sind meiner Meinung nach schon ab kleinen Projekten sinnvoll.
Es macht die Arbeit und die Wartbarkeit des Codes schneller und einfacher.
Und wenn die PHP Programmierung passt, dann sind auch nur die Smarty Grundladen notwendig.
Ich kann die Verfechter von MCV verstehen, jedoch lässt dich Smarty zum Beispiel mit Zend_View kombinieren, was die Arbeit (wenn man bisher auf eins von beiden setzt) erleichtert.
War auch lange Zeit Smarty-Anhänger. Smarty ist auch klasse, was mich aber nicht davon abgehalten hat, eine eigene Template-Engine (http://code.google.com/p/serpent-php-template-engine/) zu schreiben.
Aber warum, wenn ich Smarty so gut finde? Ganz einfach. Man kann es sich nicht so einfach machen und sagen, diese ist für alles gut und die andere eben nicht. Nein, jede hat ihre Stärken. Aber man braucht eben nicht immer alle Stärken.
Speziell an Smarty hat mich folgendes gestört:
– Performance (Smarty ist extrem langsam, wobei durch das Kompilieren anderen Engines gegenüber viel rausgeholt wird)
– Unausgereiftes Caching-System (sagte Dennis schon)
– PHP4
– Keine Möglichkeit von Rekursionen in Templates (z.B. für Navigationsbäume)
– Man muss neue Syntax lernen
Toll finde ich an Smarty:
– Template Security (sollte ich das irgendwann mal brauchen, werde ich auf jeden Fall Smarty einsetzen. Aber in den letzten 10 Jahren habe ich es nicht einmal gebraucht.)
– der Zwang, sauber zu arbeiten und Business-Logik nicht ins Template zu mogeln
Deshalb habe ich eine geschrieben, die grundsätzlich PHP ist, aber halt hier und da ein wenig mehr Komfort bietet.
Ach ja:
MVC hat nichts mit Smarty zu tun. Smarty kann lediglich das View, ja eventuell sogar nur ein Teil des Views sein.
@Christoph: Savant kennst du aber? 😉
Ich benutze entweder Dwoo oder PHP mit der alternativen Schreibweise (CodeIgniter lässt grüßen).
Ich habe mich für Dwoo entschieden weil bei Smarty lange nichts mehr passiert ist.
@Dennis:
Aber sicher. 🙂 Es unterstützt PHP short tags allerdings nur, wenn sie eingeschaltet sind. Und viel wichtiger: Es unterstützt keine Template-Vererbung. Für mich das coolste Feature, seit ich Template Engines kenne.
hmm ich denke, alles hat seine gewisse Berechtigung. Es gibt halt jene und solche Situationen in den es sinnvoll wäre, Template Engins einzuführen, bzw. zu verwenden, oder nicht.
Ich persönlich bin eher gegen template engins. Aber das liegt wahrscheinlich eher daran, dass ich selber nicht direkt den nutzen erkenne und sich für mich der Aufwand nicht lohnt sich darin einzuarbeiten. Wird mir hingegen diktiert die Engin der Wahl zu verwenden, ist es natürlich eine andere Sache.
Smarty, gutes altes Smarty.
Ein weiterer Schritt zu Beantwortung der Frage wieviele Regexes man in einem Projekt einsetzten kann bevor es niemand mehr warten kann.
—
Ich habe gut Erfahrungen gemacht mit Smarty, zu Zeiten als man in der PHP Welt MVC noch mit „muss viel coden“ ausgeschrieben hat und sonstige Konzepte auch noch nicht so ausgereift und in der Community verbreitet waren war Smarty ein toller Weg Programmieren beizubringen das Html Code nicht mitten in den anderen Code gehört.
Klar hätte man alles schon immer ohne ein Template System machen können und der Benutzung von Smarty ist schon seit entstehung mit dem (imho validen) gegenargument „php ist eine template engine und braucht deswegen keine“ wiedersprochen worden.
Mit Smarty kann man einfach allse JS in den , alles CSS in den bringen, templates ineinander rekursiv includieren, überschreiben und sonstige Schweinerein anstellen.. in einer PHP 5(.3), ZF, eZ Welt spielt das keine große Rolle mehr aber als PHP 4.2 noch state of the Art war wars ein schönes Tool.
@13 / Dennis – kurze Anmerkung zu den eTags .. ist vielleicht auch besser so 🙂 Näheres dazu siehe hier: http://developer.yahoo.com/performance/rules.html#etags
Das Argmument mit dem armen Webdesigner, der ja kein kompliziertes PHP kennt, kann ich nicht nachvollziehen.
Heutzutage sollte ein Webdesigner mehr können als „nur“ HTML, CSS und Pixelschubsen. Er sollte sowohl in der Lage sein, die Smarty Sprache zu erlernen als auch die rudimentären PHP Befehle, die für eine Ausgabe in einem Template, das auf PHP basiert, benötigt werden. Und er sollte in der Lage sein, auf den Master of Desaster zu hören, wenn dieser ihm sagt, welche Befehle er NICHT in seinem PHP Template ausführen soll. Macht er es doch, gibt es auf die Finger.
So! Und nun dürfen alle Webdesigner mich verbal verprügeln… 😉
@Steffkes: Den Artikel kenne ich natürlich, trotz allem weist Yahoo! in ihrem yslow! Tool darauf hin, ETags zu verwenden. Die Problematik, die da beschrieben wird, lässt sich umgehen, wenn man mittels PHP die ETags sinnvoll generiert (z.B. dieselbe Webseite bekommt auf allen Servern immer denselben ETag, weil die View sich nicht geändert hat) lässt sich leicht verwalten. Auf verschiedenen Servern kommt bei der md5() Funktion bei demselben Input immer derselbe Hash raus. Wie der Apache das handhabt, weiß ich nicht, macht aber auch nichts, da der Apache nicht so Anforderungen in diesen Fällen eingehen kann und soll.
@Ralf: Genau das sehe ich genauso.
Ich persönlich bin ein Freund von xslt. In einem 2 stufigen Prozess kann man so sehr schnell aus seinen XML-Daten schönen HTML Code erhalten und abstrahiert die lästige HTML Ebene. Hat auch den Vorteil, dass man Controls schön kapseln kann und man eine zusätzliche Abstraktionsschicht in die View zieht. Wir nutzen XSLT übrigens auch für die Internationalisierung.
XSLT ist natürlich auch nicht unbedingt einfach, hat aber den Vorteil, dass man es auch außerhalb des PHP-Universums nutzen kann. Der Prozessor, den PHP mitbringt, ist auch extrem schnell.
Grüße
Die meisten negativen Punkte welche sind zwar korrekt aber der Beste positive Aspekt von Smarty wird hier nicht genannt. Durch seine sehr gute Plugin-Architektur bin ich in der Lage Smarty mit eigenen Kontrollen zu erweitern (vor allem Block-Plugis).
Dadurch lassen sich sehr komplexe Kontrollen mit einem einzigen Tag im Template-Quelltext einbinden. z.B. Tabs in Tabs:
{tabgroup}
{tab name=“Tab1″}
{tabgroup}
{tab name=“Tab1-1″}{/tab}
{tab name=“Tab1-2″}{/tab}
{tab name=“Tab1-3″}{/tab}
{/tabgroup}
{/tab}
{tab name=“Tab2″}{/tab}
{tab name=“Tab3″}{/tab}
{tabgroup}
@Norbert:
Ich sehe nicht ganz den Nutzen, HTML mit einem Konstukt zu abstrahieren, welches noch aufwändiger ist als das eigentliche HTML. Abstraktion soll ja im Allgemeinen vereinfachen und nicht verkomplizieren.
Könntest du mal praktische Beispiele für den Nutzen geben?
@Joe: Zu diesen tabgroups finde ich nichts – kannst du das mal genauer erläutern? So wirklich den Sinn dahinter verstehe ich derzeit auch nicht 🙂
@Christoph
wenn ich das Beispiel von Joe Scylla aufgreifen darf. Sowas haben wir in xslt realisiert. Das heißt ich habe meine eigenen Tags und diese werden dann durch xslt in solch eine Tab-Konstruktion umgebaut. Die Komplexität bei der Benutzung ist genauso hoch wie in Joes Beispiel.
Eine genau Erklärung würde leider mehrere Seiten füllen, daher nur eine grobe Beschreibung.
Man definiert sich einerseits Controls im xslt, die durch bestimmte Tags repräsentiert werden – vergleichbar mit JSF-Elementen. Für das jeweilige Template schreibt man sich dann ein XSLT, dass eine xml-Struktur enthält, die mein allgemeines Template nutzt. Beim Erzeugen des HTML Codes wende ich ich auf meine xml-Daten erst das spezielle Eemplate und dann das allgemeine an. Und am Ende fällt dann der HTML Code raus. Ich sehe den Vorteil primär in der Erstellung von Webapplikationen, man kann durch das Austauschen der allgemeinen Templates applikationsweit das Verhalten/Aussehen etc eines Controls ändern.
Wenn dich das genauer interessiert, kann ich mich gerne mal melden 😉
Grüße
Das erinnert mich irgendwie an View Helper / Partials aus dem Zend Framework …
Ich empfehle mal einen Blick auf http://www.nosmarty.net/ zu werfen. Eine tolle Liste an Gründen, weswegen man kein Smarty verwenden sollte.
@Igor: Netter Link 🙂 Danke dafür.
@Norbert:
Danke, ich werde mir das hier mal anschauen und dann gucken, ob ichs gut finde: 🙂
http://www.webholics.de/2007/08/14/xslt-als-template-engine-in-php-teil-1/
Viele Grüße
Also in den letzten beiden Projekten habe ich wieder PHP selber verwendet. Das HTML-File sah dann sinngemäss so aus:
getHTML();
?>
Layouten darf der Designer per CSS, ich stelle an fast allen Elementen entsprechende Klassen bereit.
Nun gut, wenn ich z. B. die Spalte „Vorname“ doch nach dem „Nachnamen“ anzeigen will, muss ich halt im Sourcecode bei Aufruf des entsprechenden Widgets die beiden Elemente tauschen. Erscheint mir aber das weit geringere Übel, als immer noch ein korrektes HTML-File zu erstellen und PHP-seitig zu prüfen, ob das HTML-Template das bereitstellt, was ich erwarte…
@mich selbst:
da oben soll eigentlich ein rudimentäres HTML-File drin sein mit $main->getHTML() innerhalb zweier PHP-Tags.
traut hier jemand htmlspecialchars() nicht?
Auch gestern Abend vom Symfony Guru noch gebloggt worden: http://fabien.potencier.org/article/34/templating-engines-in-php
Lustig – heute morgen les ich einen neuen Artikel von Fabien Potencier über „Templating Engines in PHP“ (http://fabien.potencier.org/article/34/templating-engines-in-php).
Ich hatte leider noch keine Zeit den Artikel fertig zu lesen, aber es sind interessante Argumente und Ansichten die er da bringt und gegen Ende werden einige Template Engines verglichen. Also eigentlich eine gute Ergänzung zu diesem Post.
lol … jetzt war ich wahrscheinlich 2 sekunden zu spät dran
@Christoph
Das sind eigene Tags welche man über die Plugin-Struktur von Smarty bereitstellen kann. Siehe: http://www.smarty.net/manual/de/api.register.block.php
Ähhh… ich weiß. Das ging wohl an Joe, oder?! 🙂
Caching – lol!
Also ich war schon immer Gegner von smarty, auch wenn ich lange Zeit eine eigene „TemplateEngine“ mit „Caching“ verwendet habe. Sowohl bei Smarty, als auch bei meiner TE muss man bzgl. Caching folgendes erwähnen: Es wird ein HTML-PHP-Mix generiert, der dann einfach sehr viel schneller geladen werden kann (eingebunden). Caching muss aber auch stets prüfen, ob das Cache-File aktuell ist.
Verwendet man eine einfache Trennung von PHP und HTML, läuft vieles sehr viel schneller: Man hat eine viel größere Macht auf beiden Seiten und ist nicht auf kommende Versionen einer Entwicklergruppe angewiesen (Freiheit), es läuft einfach schneller (Smarty alleine als Klasse schon zu laden ist einfach ein unnötiger Overhead), man muss keine neue „Sprache“ lernen und man verliert auch nicht die Trennung von Design und Logik. Smarty ist weder übersichtlicher, noch trennt es Design von der Logik besser als die bereits von php vorgesehene Handhabbarkeit von HTML. Ein include() einer HTML-Datei bindet direkt HTML in das Script ein. Möchte man also dynamische Inhalte, baut man sich eine winzige Klasse, die es zulässt mehrere Dateien „hinzuzufügen“ (Dateinamen) und Variablen festlegen zu können. In einem abschließenden Aufruf, nach dem Programm, werden einfach durch die Klasse alle „Template-Files“ eingebunden. Die Template-Files können durch einen Aufruf innerhalb der Methode der „Layout-Klasse“ direkt auf andere Methoden der Klasse zugreifen und so zum Beispiel auch auf Variablen. Eine Abtrennung der Logik im Template muss man eben selbst vornehmen, die missachtet man bei smarty auch viel zu schnell.
Ich sehe kein Grund, warum man eine „richtige, cachende Template-Engine“ verwenden sollte. PHP-Include reicht aus (und smarty macht nach all der „Arbeit“ auch nichts anderes).
Das sind ja meine Lieblingseinträge… polarisierend 🙂
Mal angenommen, du musst deine Templates herausgeben. Wie willst du denn sicherstellen, dass die Externen keinen Blödsinn in den Templates machen?
Dokumentiert ist deine Template-Klasse doch vermutlich auch nicht. Ein Problem, wenn man mit mehreren Entwicklern arbeitet.
Was ich damit sagen will: Man kann nicht einfach sagen, dass irgendetwas Dreck ist, nur weil es dem eigenen Typ nicht entspricht (Achtung, das gilt nicht für Twitter ;-)).
Ich habe eine Abneigung gegen Smarty. Erstens weil Templates inzwischen ein heilloses Durcheinander aus verschiedenen Views bekommen (siehe Gallery2) und zum Anderen:
Als PHP-Programmierer muss man heute bereits 2 Programmiersprachen (PHP + JavaScript) können. Dazu eine Datenbanksprache (SQL) und zwei Layout-Sprachen (HTML + CSS). Brauchen wir wirklich noch eine 6 Sprache?
huschi.
Es geht bei der Verwendung einer Template Engine NICHT DARUM den dummem Webdesigner mit Code zu verschonen (dann hat er den falschen Job) sondern den Code der DIE VIEW betrifft zu kapseln!!!!!!!
Zum Donnerwetter nochmal!
@huschi:
6 Sprachen? Heute sollte man ein Projekt doch aus mindestens 25 Domain Specific Languages zusammenstückeln, verteilt in lauter kleine Einzeldateien…
@thorsten:
Wenn es nur um die Kapselung geht, dann kann ich die View in einer Klasse per echo oder DOM realisieren. Aber der Vorteil an einem Templating-System ist halt auch, dass man was am Layout ändern kann, ohne was am Code ändern zu müssen (in Maßen).
@thorsten: Ich glaube du verwechselst da etwas. Templates/Vorlagen an sich sind ein Weg die View zu kapseln. „Template Engines“ sind nur Möglichkeiten diese Templates aus was anderem als purem HTML bestehen zu lassen.
Ich halte nicht viel davon, eine komplexe Template-Engine wie Smarty zu verwenden. Mit php ist dies garnicht nötig, denn php selbst IST eine Template-Engine: , da brauche ich keinen Smarty-Wrapper drum der mich eine neue Syntax lernen lässt, der Templates aufwendig on-the-fly kompilliert oder Umständlich im Vorraus.
Das Argument, Designer damit zu bewusst einzuschränken halte ich für an den Haaren herbeigezogen: wer befürchtet, dass sich seine Designer nicht an die Regeln halten, hat ein ganz anderes Problem.
Hallo Leute, ich möchte mal in die Runde fragen, ob jemand einen Sinn in JavaScript Template Engines sieht? Ich habe zwischenzeitlich einige ausprobiert aber ich habe das Gefühl, das diese Template-Parser wenig Zukunft haben, da die JS Browserunterstützung fraglich ist, denn viele User stellen JS einfach ab. Gibt es denn wirklich große Webseiten die damit betrieben werden? Hat jemand ein Projektbeispiel?
LG Oliver