So wählen Sie eine Web-Front-End-Vorlagen-Engine aus (empfohlen)

Der Inhalt dieses Artikels befasst sich mit der Auswahl einer Web-Front-End-Vorlagen-Engine (empfohlen). Freunde in Not können sich darauf beziehen.

Die Template-Engine ist dafür verantwortlich, Daten zusammenzustellen und die Daten in einer anderen Form oder Erscheinung darzustellen. Die Seite im Browser ist der endgültige Ausdruck der Web-Template-Engine.

Ob Sie die Template-Engine direkt verwenden oder nicht, Webvorlagen gab es schon immer, nicht im Frontend, sondern im Backend. Ihre Entstehung lässt sich sogar auf die Zeit vor dem HTML-Standard der Hypertext Markup Language zurückführen offiziell etabliert.

Serverseitige Template-Engine

Die früheste mir bekannte Web-Template-Engine ist PHP, das 1997 offiziell geboren wurde und serverseitig arbeitet. Werfen wir einen Blick auf das offizielle Intro-Whatis von PHP:

HPer sind sich im Allgemeinen einig, dass PHP selbst die natürlichste und nativste PHP-Template-Engine ist, weil sie es ist. In der PHP-Welt gab es viele neu gepackte Template-Engines, die berühmteste davon ist Smarty.

Viele andere serverseitige Sprachen verfügen über HTML-Vorlagen-Engines, wie z. B. JSP und Moustache.

Es besteht kein Zweifel daran, dass das von diesen serverseitigen Template-Engines generierte Endergebnis ein HTML (XML)-String ist und die Verarbeitungsflusslogik mithilfe der Syntax der Hostsprache selbst implementiert wird.

Ihr gemeinsames Merkmal: HTML ist nur eine Zeichenfolge, und das Endergebnis erfordert möglicherweise eine Bereinigung oder Korrekturvalidierungstools wie Tidy.

Hier ist eine Frage: Ist es notwendig, einen sekundären gekapselten Smarty zu haben?

Browserseitige Template-Engine

Die früheste, die ich kenne Die Front-End-Template-Engine ist jCT, die auf Google Code gehostet wird und 2008 geboren wurde. Die Host-Sprache ist JavaScript und funktioniert im Browser.

Wenn Sie heute in OSC nach der JavaScript-Template-Engine suchen, erhalten Sie über 100 Ergebnisse:

Lightweight: tpl.js, T.js
Awareness: arttemplate, mustache.js, doT.js, handlebars.js, pug
DOM-Baumbasiert: domTemplate, transparency, Plates
VDOM-basiert: htmltemplate-vdom, virtual-stache, html-patcher
Beliebte Frameworks : Vue.js, ReactJS, riot
Real-DOM: PowJS

Ihr gemeinsames Merkmal: alle unterstützen Interpolation.

Hier finden Sie auch einen Vergleich der Beliebtheit von Templating-Engines und sogar eine Abstimmung für die besten Javascript-Templating-Engines sowie die Gründe für die Vor- und Nachteile.

Wie wählt man aus?

Ich denke, dass jede Engine und jedes Framework in einer bestimmten Zeit immer einen Wert hat, zumindest in Ihrer Anwendung, also wird dieser Artikel es tun Kommentieren Sie nicht, was an einem bestimmten Motor schlecht ist, da dies unsachlich wäre. Um nun die zuvor gestellte Frage zu beantworten: Ist Smarty existent? Meine Antwort ist: Ja. Der Grund ist ganz einfach, er hängt davon ab, für wen es verwendet wird und vom allgemeinen Hintergrund. Bei Anwendungen, bei denen Front-End und Back-End nicht getrennt sind oder das Front-End-Personal nicht ausreichend mit der Back-End-Sprache vertraut ist oder die beruflichen Verantwortlichkeiten dies erfordern, ist es realistisch, dass das Front-End-Personal sie beherrscht Eine gebräuchlichere Vorlagensyntax (Sprache) ist im Gegenteil eine Verschwendung von Fähigkeiten.

Im Folgenden finden Sie allgemeine Vorschläge für die Engine-Auswahl:

Voraussetzung ist, dass die ausgewählte Engine die Datenwiedergabeanforderungen erfüllen kann und nicht mit bestehenden Abhängigkeiten in Konflikt steht Motor, dann haben Sie bereits Ihre Antwort.

Handelt es sich um eine einmalige Projektanforderung? Wenn ja, wählen Sie einfach das leichte Projekt mit der geringsten Lernkomplexität. Möchten Sie Komponenten entwickeln?

Die Engine unterstützt vorkompilierte Ergebnisse, sodass Sie diese nicht jedes Mal in Echtzeit kompilieren müssen.

Möchten Sie plattformübergreifend arbeiten? ? Es gibt offizielle, die Unterstützung bieten, und React-JSX-Engine oder eine reine VDOM-Engine.

Wählen Sie diejenige mit der geringsten Komplexität zum Erlernen oder Warten. Wie wir alle wissen, verbringen Entwickler nicht gerne mehr Zeit mit dem Debuggen als mit dem Schreiben von Code.

Der letzte Schritt ist der Leistungsvergleich. Der Leistungsvergleich ist eine sehr detaillierte Aufgabe, und die Vergleichsergebnisse anderer Personen stimmen möglicherweise nicht unbedingt mit Ihrem Szenario überein.

Ich denke, der Vergleich von Grammatikstilen sollte abgeschwächt werden. Einige Grammatiken haben sogar spezielle Hintergrundgründe.

Warum ist der Leistungsvergleich das Letzte?

Leistung ist in der Tat wichtig, aber wenn die Leistung Ihr Anwendungserlebnis nicht beeinträchtigt, dann ignorieren Sie sie. Es ist schwierig, Anwendungsszenarien wirklich zu simulieren. Derzeitige Testtools können diesen Effekt jedoch nicht erzielen.

Auf einige der oben genannten Fragen gibt es feste Antworten: Wie sind Komponentenentwicklung, Unterstützung für die Vorkompilierung und Komplexität zu berücksichtigen?

Komponentenentwicklung

Bei der Komponentenentwicklung geht es nicht länger um die Auswahl einer Template-Engine, sondern um die Auswahl der ökologischen Umgebung. Wenn Ihre Bewerbung schneller abgeschlossen werden muss, dann hat Zeit oberste Priorität. Wählen Sie ein beliebtes Framework, das über genügend Komponenten verfügt, die Sie verwenden oder auf die Sie verweisen können. Wenn Ihre Anwendung über eine unabhängige ökologische Umgebung verfügt und eine Technologieauswahl für eine langfristige Wartung erfordert, lesen Sie weiter unten.

Vorkompilierung

Vorkompilierung sollte Folgendes haben:

Das Kompilierungsergebnis erfordert keinen Kompilierungsprozess mehr in der Zielumgebung.
Kompilieren Sie die Ergebnisse aus Gründen der Debugbarkeit. Das bedeutet, dass die Ergebnisse nativen ECMAScript-Code und keine reinen Datenbeschreibungen enthalten sollten.
Jeder weiß, dass React-JSX die Vorkompilierung unterstützt. Die offizielle Aussage ist, dass React Without JSX immer erstellt wird.

Einige auf Stringverarbeitung basierende Engines unterstützen auch die Vorkompilierung. Wenn Sie eine Vorkompilierung benötigen, wird empfohlen, die Engine aufzugeben, deren Kompilierungsergebnis noch auf der Zeichenfolgenverkettung basiert. Dies war eine technische Methode, bevor HTML5 allgemein unterstützt wurde.

Zumindest muss es ein kompiliertes Ergebnis wie React-JSX geben, um debuggbar zu sein. Hinweis: Vue.js unterstützt mehrere Template-Engines, um den gleichen Effekt zu erzielen.

Original-ReactJS-Code, der Web Components-Technologie verwendet:

class HelloMessage extends React.Component {
  render() {
    return <p>Hello <x-search>{this.props.name}</x-search>!</p>;
  }
}

Nach der Kompilierung:

class HelloMessage extends React.Component {
  render() {
    return React.createElement(
      "p",
      null,
      "Hello ",
      React.createElement(
        "x-search",
        null,
        this.props.name
      ),
      "!"
    );
  }
}

Viele VDOM-Engines können auch ähnliche Effekte kompilieren, wie z. B. htmltemplate-vdom.

  <script>
        var id = 3;
        var env = {
            people: [
                {
                    id: &#39;id1&#39;,
                    name: &#39;John&#39;,
                    inner: [{ title: &#39;a1&#39; }, { title: &#39;b1&#39; }],
                    city: &#39;New York&#39;,
                    active: true
                },
                {
                    id: &#39;id2&#39;,
                    name: &#39;Mary&#39;,
                    inner: [{ title: &#39;a2&#39; }, { title: &#39;b2&#39; }],
                    city: &#39;Moscow&#39;
                }
            ],
            githubLink: &#39;https://github.com/agentcooper/htmltemplate-vdom&#39;,
            itemClick: function(id) {
                env.people.forEach(function(person) {
                    person.active = String(person.id) === String(id);
                });
                loop.update(env);
            }
            // Omitted ....
        };
    </script>

Komplexität

Es ist schwierig, anhand eines einzigen Kriteriums zu beurteilen, welche der beiden Engines weniger komplex ist. Dies liegt an den unterschiedlichen Denkmustern der Benutzer. Beispielsweise sind die Unterschiede in der Verwendung und den vorkompilierten Ergebnissen der oben aufgeführten Engines für verschiedene Benutzer unterschiedlich. Dies ist die Rationalität und der Wert der Existenz verschiedener Engines.

Einige Benutzer denken, dass String-Vorlagen die Anforderungen dieses Anwendungsszenarios erfüllen können und leichtgewichtig und ausreichend sind.
Einige Benutzer denken, dass die Template-Engine der String-Splicing-Technologie nicht leistungsstark genug und nicht modern genug ist.
Einige Benutzer denken, dass OOP rational, logisch und abstrakt genug ist.
Einige Benutzer denken, dass natives HTML als Frontend bezeichnet wird.
Einige Benutzer glauben, dass VDOM eine breitere Anwendbarkeit hat.

Diese Urteile haben ihre eigenen Gründe, mit unterschiedlichem Fokus und unterschiedlichen Maßstäben. Aber wir können ihre Komplexität immer noch anhand ihrer Gemeinsamkeiten betrachten.

String-Vorlagen sind normalerweise sehr leichtgewichtig und gehen über den Rahmen dieses Abschnitts hinaus. Was sind die allgemeinen Kriterien zur Beurteilung der Komplexität von Nicht-String-Vorlagen? Ich denke, die Komplexität der Datenbindung kann berücksichtigt werden.

Die in diesem Artikel erwähnte Datenbindung ist nicht nur Interpolation, sondern umfasst auch Kontext und Ereignisse und sogar die Hostumgebung der gesamten Laufzeit.

Tatsächlich ist für diese Fähigkeit eine Engine erforderlich, die mindestens die VDOM-Ebene erreicht, da VDOM echten DOM-Knoten zugeordnet werden kann.

Es gibt wahrscheinlich mehrere Modi (Kombinationen):

1. Der Eingabeparameter ist ein Objekt und die Variable x in der Vorlage ist das .x-Attribut des Objekts, zum Beispiel: virtuell -stache-example
2. Spezifische Syntax oder Attribute, wie zum Beispiel: Vue.js's..., berechnete Attribute, Methoden
3. Abstrakte semantische Attribute, wie zum Beispiel: Vue.js's active für eine Vielzahl von Szenarien und ist leicht zu verstehen.
4 Es ist nicht erforderlich, dass Benutzer mit nativen Methoden vertraut sind und native Methoden zum Binden verwenden, wie zum Beispiel: PowJS

Diese Modi sind nur theoretisch, normalerweise müssen Probleme beim Template-Engine-Design gelöst werden. Für Benutzer ist es besser, direkt zu fragen:

1. Kann das einfachste console.log(context) zum Debuggen direkt in die HTML-Vorlage geschrieben werden?
2. Layer-DOM-Baum? Oder andere Kontextparameter übergeben?
3. Kann auf den generierten Knoten im mehrschichtigen DOM-Baum zugegriffen werden?

Das Template-Engine-Team wird Ihnen die richtige Lösung geben, aber normalerweise ist es so hängt mit dem Problem zusammen. Wörtlich beschriebene Ziele variieren. Ich denke, das ist der Schlüssel zu Ihrer Entscheidungsfindung, Ihrer Anerkennung der richtigen Methode des Beamten.

Eingebettet in DOM

Eingebettet in HTML

PowJS wird wie folgt implementiert:

Anweisungen, die implementiert werden müssen, um die Vorlage zu implementieren
Vorab kompiliert Nativen ECMAScript-Code ausgeben
Die Syntaxstruktur der Vorlage stimmt mit der Schreibmethode von ECMAScript-Funktionen überein
Letztendlich ist das Schreiben von PowJS-Vorlagen wie das Schreiben von ECMAScript-Funktionen.

Schreiben im GoHub-Index

<template>
  <details>
    <summary>{{ctx.Description}}</summary>
    <p>
      </p>
<p>{{pkg.Import}}</p>
    
  </details>
  <dl>
    <details>
      <summary>{{rep.synopsis}}</summary>
    </details>
  </dl>
</template>

Die meisten Template-Engines implementieren if und every-Anweisungen. Die obige PowJS-Vorlage enthält außerdem:

Globale Objekte sind, sel
Vorlage (. Funktion) Benennung Repo, Liste
Vorlage (Funktion) Eingabeparameterdaten
benutzerdefinierte lokale Variable ctx
Untere Vorlage (Funktion) formale Parameterableitung data.sha->sha
Durchquerung Der Wert wird abgeleitet Der formale Parameter der unteren Vorlage (ctx.Package,val-pkg)->pkg, (data.content,val-rep)->rep
DOM-Knotenoperation this.renew, this.appendTo, dies ist direktes Rendern zum Seiten-DOM-Baum
Prozesskontrollunterbrechung
Pseudoknoten if="':';", der p-Knoten wird beim Rendern überhaupt nicht generiert, es handelt sich um einen Pseudoknoten, der dem Blockcodesymbol "{ }"
Der Schlüssel liegt darin, dass die gesamte Vorlagenstruktur, die Befehlssemantik und die ECMAScript-Funktionen genau gleich sind:

Es gibt keine Datenbindung, Sie schreiben eine ECMAScript-Funktion, übergeben Sie einfach die Parameter, welche Bindung Willst du?
Es gibt keine Ereignisbindung, alle Knoten sind real.
Zum Debuggen suchen Sie einfach nach einem do oder if oder let und fügen Sie _=console.log(x) ein Komma-Ausdrücke können nahezu nahtlos eingefügt werden.
Die gesamte Geschäftslogik wird vom Benutzer geschrieben und PowJS ist nur für das Einkleben in eine Funktion verantwortlich.
Die exportierte Ansicht ist der ECMAScript-Quellcode entnommen aus der Demo „Meine Ordner“

Ist PowJS also die endgültige Wahl? Das Konzept von PowJS ist Nativeness, natives DOM und natives ECMAScript.

Nativ ist auch das Problem bei PowJS. Ich glaube, dass einige Benutzer einen abstrakteren Stil bevorzugen.

Nativ bedeutet, dass Sie es erweitern und andere Bibliotheken für den Abgleich einführen können, aber PowJS wird niemals einen Watcher durch Definieren von Setter/Getter implementieren, was den Rahmen der Template-Engine sprengt. Wenn es einen gibt, muss es sich um ein unabhängiges Projekt handeln .

Abschließend möchte ich noch sagen: Ihre Bedürfnisse sind der Schlüssel zur Auswahl einer Vorlage, und diejenige, die zu Ihnen passt, ist die beste.

Das obige ist der detaillierte Inhalt vonSo wählen Sie eine Web-Front-End-Vorlagen-Engine aus (empfohlen). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!