Ich würde gerne wissen, welcher Ansatz schneller ist, mit reinem PHP in den HTML-Dateien oder mit einer Template-Engine wie Smarty, Twig, ... Was ich als nächstes besonders gerne wissen möchte: Was wird schneller geparst, ist der Smarty-Cache beispielsweise schneller als reines PHP? Welche der Template-Engines ist am schnellsten? Ich bin dabei, eine einfache Anwendung zu schreiben, bei der die Geschwindigkeit an erster Stelle steht.
"Depends" ist die Antwort auf alle Ihre Fragen.
Was ist "schneller"? Ausführungszeit? Entwicklungszeit? Instandhaltung? Speicheraufwand? Eine Mischung aus ihnen? Eine Template-Engine handelt normalerweise mit etwas Leistung (Geschwindigkeit, Speicher) für bessere Entwicklung und Wartung.
Wenn Sie über ein rein dynamisches Templating sprechen (dh: Template, das bei jeder Anfrage ausgewertet wird), überholt PHP jede Template-Engine. Das ist wirklich ein Nobrainer. Wenn Sie Caching berücksichtigen, kann eine Template-Engine wie Smarty helfen. Caching ist jedoch nichts, was Sie nicht in PHP implementieren könnten. Mit Smarty ist es nur für Sie gemacht worden (und auf einer weit anspruchsvolleren Ebene, als Sie möglicherweise).
Wenn Sie ein Framework verwenden, sagen Sie Symfony, ist es ratsam, Twig zu verwenden, da Twig und Symfony eng integriert sind. Sicher können Sie Smarty oder einfaches PHP benutzen. Die Frage ist: ist es praktikabel?
Caching ist sinnvoll, wenn Sie Sites aus Datenquellen wie einer Datenbank oder Remote-APIs erstellen. Was Sie wirklich (im Sinne einer Reduzierung) sparen, sind Datenbankaufrufe, intensive Berechnungen usw. Überprüfen Sie, ob Sie zeitintensive Funktionen ausführen, um Ihre Site zu erstellen. Wenn ja, verwende Caching (wenn du kannst).
Unter Berücksichtigung von Kompromissen in den Bereichen Entwicklung / Wartung / Komfort / Leistung würde ich (immer) die Verwendung einer Vorlagen-Engine empfehlen. Als Smarty-Entwickler schlage ich natürlich Smarty vor. Wenn Sie nicht Symfony verwenden, können Sie mit Twig besser arbeiten. Oder ein anderes Framework mit einer anderen Template Engine.
Bitte ignorieren Sie Beiträge wie Smarty vs. Twig , da sie nur eine sehr eingeschränkte Ansicht der Suchmaschinen vergleichen. Traue keinen Benchmarks, die du nicht selbst gefälscht hast ™.
Im Allgemeinen ist Smarty 3.1 jedoch etwas schneller als Twig. Twig macht zur Laufzeit (zur Zeit der Ausführung einer Vorlage) eine Menge Dinge, die Smarty zur Kompilierzeit tut (zu der Zeit, zu der eine Vorlage für die Ausführung vorbereitet wird). Twig ist nicht wirklich weg Geschwindigkeit hier pissen. Twig muss zur Laufzeit bestimmte Dinge tun. Sie haben ein bisschen Leistung für ein bisschen "convenienve" (Zugriff auf Arrays und Objekte mit der gleichen Notation, zum Beispiel) gehandelt.
Lasst uns die Tropen, die zu diesem Thema gehören, auseinander reißen:
1. Behalte die Logik aus der Präsentation heraus - setze keinen "Code" in deinen HTML-Code
Jeder der das sagt und dann sagt, dass er mit Templating gehen soll, ist widersprüchlich:
Sie müssen aufhören, sich selbst zu belügen. Ihre 'Templating-Syntax' ist eine Programmiersprache, die auf einer anderen aufgebaut ist, die wiederum auf einer anderen Sprache aufgebaut ist - das ist ineffizient, redundant und seltsam .
Außerdem kann ich nicht erkennen, wie die Existenz der Variablen jeder templatierenden Engine, von der jemals die Rede war, nicht als Logik betrachtet wird - ihre Existenz, ihr Inhalt und ihre Implementierung hängen von einem logischen Teil ab Backend.
Und was ist mit diesen Templating-Systemen mit if / else Anweisungen und für Schleifen? Das ist das Wesen der Logik - genau die Konzepte, die die meisten Programmiersprachen verwenden. Sie benötigen variable Daten, die nur generiert oder durch irgendeine Form der Berechnung existieren können.
Sie können dynamischen Inhalt nicht bereitstellen, ohne Präsentation mit Logik zu mischen. Es ist unmöglich.
2.1 Es ist sicherer ...
Also trauen Sie Ihrem HTML-Typ nicht zu?
Fall: Sie denken, dass Ihr HTML / CSS-Typ dumm ist und versehentlich das Datenbankpasswort ausgibt
Wenn das so ist, habe ich Neuigkeiten für Sie - Ihre Umgebung ist bereits nicht sicher, wenn sensible Daten von überall im Programm abgerufen / geändert werden können.
Fall: Sie denken, dass Ihr HTML-Typ zufällige Serverkonstanten drucken wird - es ist gefährlich, ihm als Einzelperson zu erlauben, mit Serverlogik zu arbeiten
Ich sehe - Er ist entweder dumm oder hasst seinen Job und will gefeuert werden und wird daher etwas Dummes tun, wie das Drucken von Session-Variablen. Gut, aber dazu sage ich ...
... Warum zum Teufel ist dieses Zeug nicht Peer-Review ? Selbst wenn er keinen Zugang zu einer direkten Serverlogik, sondern zu einem ausgefallenen Templating-System hätte, könnte er seine Dummheit / Hass nur deshalb verbreiten, weil er das letzte Wort über die Ausgabe hat. Oder er könnte sogar mit einem anderen Programmierer (falls vorhanden) in Verbindung stehen und trotzdem auf Server-Konstanten und Co. zugreifen.
-
2.2.1 Gute Templating-Engines bereinigen die Ausgabe automatisch oder erlauben es dem Templates, dies selbst zu tun - er weiß besser, wenn Daten bereinigt werden müssen
Du Dummy.
Sie wissen nicht, wann die Ausgabe bereinigt werden soll? Du kannst das nicht selbst machen ..?
Trotzdem, vielleicht bist du nur der Code-Affe und der HTML-Typ ist ein Spezialist für Web-Sicherheits-HTML-Injection, und er sollte die einzige bereinigende Ausgabe sein. In diesem Fall erlaubt ihm der Zugang zu PHP auch die Verwendung von htmlspecialchars() und nicht das, was die Vorlage ihm ermöglicht.
Was das automatische Escaping betrifft, können Sie, sofern Sie sicher Inhalte weitergeben, ein solches einfaches Feature in den Code implementieren, den Sie gerade ausführen.
-
2.2 ... und ich kann steuern, mit welchen Daten gearbeitet wird
Denken Sie über Klassen, Funktionen usw. nach - Sie werfen Daten hinein, sie arbeiten damit, dann erhalten Sie ein Ergebnis. In der Regel befassen sie sich nicht mit externen Daten, es sei denn, sie werden ihnen ausgehändigt (andernfalls ist unklar, gefährlich und schlechte Praxis - Einige Konstanten beiseite). Mit denselben Methoden können Sie genau das, was Sie für Ihre Produktion benötigen, effizient, klar und unbegrenzt weitergeben.
-
3. PHP-Syntax ist zu schwer / schwierig, um den Stil Menschen
zu lehren
Die Wahrheit ist, dass es nicht komplizierter ist als die Pseudosyntax, die von Vorlagensystemen wie Smarty erzeugt wird. Wenn das ein Problem ist, dann ist dynamischer Inhalt nichts für Sie.
Das Folgende ist in PHP 'kurze Syntax' - Ist es zu schwierig?
<div class='username'><?= $username ?></div>
4. Es ist zu viel Arbeit, um meine eigene Lösung zu entwickeln
Obwohl ich behaupten würde, dass es nicht so ist, können Sie sich frei entscheiden, was Sie wollen! Wählen Sie, was am besten zu Ihren Bedürfnissen passt.Sie sind in der Regel frei, nicht schwer zu integrieren und verfügen über zahlreiche Funktionen.
Ich habe den Eindruck, dass die meisten Leute sich für Templating entscheiden, einfach weil es in der Datei "schöner" aussieht. Sie lieben es zu denken, dass die TPL-Datei etwas Spezielles ist, sie mögen die Art, wie die Syntax aussieht; Wie von Zauberhand wird die Variable durch das kleine @ oder # Symbol "aufgerufen" und springt von Ihrer Logik in die Ausgabe.
Es scheint wie ein Trick - Die schöne Zauberin ( AKA Die Vorlagenmaschine ) zieht Sie mit ihrer Schönheit an. Obwohl sie an das Auge appelliert, ist sie wirklich ein blutsaugender Dämon und extrahiert deine Seele ( Server-Ressourcen ) im Austausch für Augenweide, die niemand sonst sieht (deine Benutzer würden es lieber haben) eine schnellere Website und mehr Funktionen, die durch die $$$ gespart werden, sparen Sie bei der Strom- / Serververmietung)
%Vor% Ich gebe zu, es gibt nur einen Fall, den ich mir vorstellen kann, in dem Templates über PHP Grund haben - Portabilität zu anderen Anwendungen. appartisans Antwort adressiert das. Dennoch ist es nicht schwer, <?= $var ?> durch {{@var}} - zu ersetzen. Das ist ein Job für ein Templating-ähnliches System.
Einfach und rein die Meinung, ich denke der einzige Vorteil ist die Portabilität. Sie können Vorlagen oder Ansichten aus einer Vorlagen-Engine in eine andere Back-End-Anwendung erneut verwenden. Angenommen, Sie verschieben Ihre Anwendung von PHP nach Java, müssen Sie die Vorlagen nicht umgestalten.
Andernfalls fügen Sie Komplexität hinzu, fügen eine andere Ausführungsschicht hinzu (mehr Zeit), mehr Anforderungen zum Verwalten der Anwendung (Sie benötigen Personen, die diese Vorlagen-Engine kennen) und so weiter. PHP selbst ist die beste und am besten ausgestattete Vorlagen-Engine, wahrscheinlich die schnellste, und Sie können auch Caching durchführen, mit dem Vorteil, den Cache von der Back-End-Anwendung und nicht von der View zu steuern.
Ich werde das wieder aufnehmen, da sich die Dinge wesentlich geändert haben und einige Beweise aus der früheren Antwort fehlen.
Ohne genau zu wissen, warum Frameworks Vorlagen-Engines über PHP verwenden, was die meisten tun. Aus irgendeinem Grund gibt es einen ständigen Versuch, PHP mit einer anderen Abstraktionsschicht zu "reparieren". Immer mit dem Anspruch der Einfachheit ohne Verlust von Vielseitigkeit oder Leistung.
Ungeachtet dessen ist die Verwendung von PHP immer noch die schnellste und vielseitigste Art des Templatings. PHP in seinen frühesten Inkarnationen sah fast wie eine Templating-Sprache aus. Aber werfen wir einen Blick auf die Fortschritte in PHP und platzieren Sie sie Seite an Seite mit den After-Layern .
Twig und einige andere behaupten, etwas zwischengespeichert zu haben, was in früheren Versionen von PHP immer ein Addon war. Caching ist jetzt ein Standard-Teil von PHP5.5 + (Opcache) und verwendet PHP als Vorlagensprache gibt mehr Leistungsverbesserungen.
Twig und andere fordern eine einfache Syntax für Designer. Wenn Sie die Syntax einer Template-Engine vergleichen, werden Sie sehen, dass die Logik ähnlich ist, mit dem einzigen Vorteil, ein Template-System zu verwenden wie Twig ist eine weitere Ebene der Sicherheitstrennung zwischen dem Designer und dem zugrunde liegenden Systemcode.
Zwei sehr beliebte CMS Wordpress und Drupal haben PHP als Template Engine verwendet. Das alte Argument, eine Template-Engine zu verwenden, um die Verwendung von PHP beim Entwerfen einer Website zu sichern und zu vereinfachen, ist im heutigen Web nicht wirklich gültig. Während sich Drupal 8 auf Twig zubewegt, liegt es hauptsächlich daran, dass Zweig ein Teil von Symfony Framework ist (zurück zu dem, warum Frameworks Template-Engines verwenden). Wordpress dagegen benutzt immer noch PHP. Wordpress wächst rasant mit Webdesignern, die PHP verwenden, um dies zu ermöglichen. Drupals Community wurde teilweise durch die Entscheidung für Twig und Symfony geteilt.
Es scheint also so zu sein, dass die Verwendung von PHP die bessere Wahl in Bezug auf die Leistung ist, aber auch die Vorliebe für zukünftige Designer und Designer. Zumindest alle Beweise führen zu dieser Schlussfolgerung.
Das hier ist meine grundlose Meinung. Ich denke, dass die Verwendung von etwas anderem als PHP als Template-Engine im heutigen Web einige inhärente Schwächen in der zugrundeliegenden Framework- oder Web-Anwendungsarchitektur beinhaltet. Diese Schwäche ist ihre Komplexität und Kompliziertheit , die auf Designer- oder Designer-Ebene nicht einfach erklärt werden kann.
Wenn Sie eine leichte Anwendung schreiben, die klein sein muss. Halten Sie es klein und leistungsfähig, indem Sie PHP verwenden, und überlassen Sie die anderen Engines "Unternehmen" Ebenengruppen und Projekten
Ich habe ein Problem mit dem Argument, dass Logik und Datenanzeige so weit wie möglich getrennt sein müssen. Ich habe festgestellt, dass die Validierung und Anzeige von Daten tatsächlich viel Logik in Formularen erfordert. Informationen über Datentyp, Nummernbereich, Beziehung zwischen verschiedenen Daten erfordern viel Code. Die eigentliche Frage ist, ob wir eine Template-Sprache auf der Server-Seite oder Javascript auf der Client-Seite verwenden sollen. Durch die Verwendung von Ajax und clientseitigem Code zur Datenanzeige und -validierung verfüge ich über sehr wenig Template-Code. Das größte Problem bei Template-Engines ist die Einführung neuer Coderegeln und -syntax. Ich sehe die Zukunft mit PHP-, Jquery- und Ajax- und Template-Engines, die an Attraktivität verlieren.