Wann sollte JavaScript HTML generieren?

34

Ich versuche so wenig HTML wie möglich aus JavaScript zu generieren. Stattdessen bearbeite ich lieber vorhandenes Markup, wann immer ich kann, und erst dann HTML, wenn ich dynamisch ein Element einfügen muss, das kein guter Kandidat für die Verwendung von Ajax ist. Dies macht es meiner Meinung nach viel einfacher, den Code zu pflegen und schnell Änderungen daran vorzunehmen, da das Markup leichter zu lesen und nachzuverfolgen ist. Meine Faustregel lautet: HTML ist für die Dokumentstruktur, CSS ist für die Präsentation, JavaScript ist für das Verhalten.

Ich habe jedoch viel JS-Code gesehen, der eine Menge HTML generiert, einschließlich ganzer Formulare und inhaltsintensiver modaler Dialoge. Welche Methode wird im Allgemeinen als Best Practice angesehen? Unter welchen Umständen sollte JavaScript zum Generieren von HTML verwendet werden und wann nicht?

VirtuosiMedia
quelle
2
Warum ist das Markup Ihrer Meinung nach über Ajax einfacher zu lesen und zu verfolgen?
PSR
3
Ich benutze Ajax normalerweise auf zwei Arten: Laden ganzer vorgerenderter HTML-Schnipsel in die Seite oder ein JSON-Array, das ich analysiere und dann die Daten in vorhandene Elemente einfüge. Sehr selten werde ich aus Ajax-Daten dynamisch HTML generieren und in die Seite einfügen. Da der Ajax-Inhalt normalerweise als HTML-Code vorgerendert wird, ist das Lesen einfacher als der Versuch, die Erstellung dynamischer Elemente in JavaScript zu verfolgen. Ich kann schnell einen Blick darauf werfen und die Struktur und den Inhalt sehen.
VirtuosiMedia
2
Fantastisch dornige Frage ...
Mark Canlas
2
@VirtuosiMedia - Haben die vorgerenderten HTML-Snippets beim Rendern auf dem Server nicht die gleichen Probleme wie beim Rendern über JavaScript? Ich versuche nicht, umstritten zu sein, ich verstehe wirklich nicht, was Ihr Problem ist.
PSR
1
@psr Im Allgemeinen nicht. Wenn Sie ein JS-Framework oder nur Vanilla-JavaScript verwenden, werden Sie Ihr HTML mit einer Reihe von Methodenaufrufen und Funktionen generieren. Wenn dies mit einer großen Anzahl von Elementen durchgeführt wird, kann es sehr schwierig sein, die tatsächliche Dokumentstruktur zu erkennen. Im Gegensatz dazu behält HTML-generierte Server-Seite normalerweise eine saubere Struktur bei und es wird lediglich Server-Code verwendet, der Daten in eine HTML-Vorlage zurückgibt, anstatt die Elemente selbst zu generieren. Wenn Sie also das JS-Verhalten ändern möchten, müssen Sie die Methoden zum Generieren von Elementen nachverfolgen, um die Hierarchie anzuzeigen.
VirtuosiMedia

Antworten:

19

Wann immer ich in Javascript auf starke HTML-Generierung gestoßen bin, war es fast ausschließlich in einem eigenständigen UI-Plugin. Dies ist sinnvoll, da das gesamte Plugin in einer einzigen .js-Datei (+ ein .css zum Anpassen von Formatvorlagen) gekapselt werden kann, sodass es problemlos wiederverwendbar, verteilbar und unabhängig von dem in der Anwendung verwendeten Framework ist.

Wenn Sie also ein eigenständiges Javascript-Plugin oder eine generische UI-Komponente schreiben, die Sie für verschiedene Anwendungen verwenden möchten, hat ein solcher Ansatz seine Vorteile. Ansonsten denke ich, es ist sauberer, einfacher zu schreiben und einfacher zu warten, wenn Sie die HTML-Generierung von Javascript fernhalten und auf der Serverseite.

scrwtp
quelle
29

Ich denke, das Problem ist, dass Sie sauber geschriebene serverseitige Vorlagen mit schlecht geschriebenen ad-hoc-clientseitigen HTML-Generierungen vergleichen. Natürlich ist der sauber geschriebene Code einfacher zu lesen, zu warten und zu verfolgen.

Sie nennen den clientseitigen Code "Mounds of HTML", aber natürlich ist er überall dort, wo er generiert wird, derselbe HTML-Code. Der "Hügel" ist wirklich der große Klumpen Code.

Es gibt viele clientseitige Vorlagenbibliotheken. Sie funktionieren ähnlich wie die serverseitigen. Was Sie bevorzugen sollten, der Performance-Kompromiss ist kompliziert, aber JSON ist normalerweise kompakter als das HTML, das es wird, und wenn die Vorlage auf dem Client vorhanden ist, können einige Serveraufrufe eliminiert werden. Auf der anderen Seite hat der Client möglicherweise JS deaktiviert oder ist zu langsam, um praktisch zu sein. Dies hängt also auch von Ihrer Zielgruppe ab. Insgesamt denke ich, dass die Ansätze ziemlich vergleichbar sind, wobei der größte Faktor die Browserfähigkeiten Ihrer Zielgruppe sind.

Aber es kommt genau darauf an, was Sie tun, ob Sie JS Ihrer Serverumgebung vorziehen, welche Template-Lösung Sie bevorzugen usw.

bA
quelle
15

Es gibt einen Trend zur Verwendung clientseitiger Vorlagen. In extremen Fällen müsste der Server nur RESTful API bereitstellen, z. B. im JSON-Format, während alle clientseitigen Vorgänge ausgeführt werden. Der Vorteil dieses Ansatzes besteht darin, dass JS-Code und -Vorlagen statische Ressourcen sind, die über CDN zwischengespeichert, übertragen und verteilt werden können. Dies ist nicht möglich, wenn Sie serverseitig dynamisches HTML generiert haben. Wenn Sie nur Daten von der RESTful-API im kompakten Format zurückgeben, werden viel weniger serverseitige Ressourcen benötigt, wodurch die Reaktionszeit verkürzt wird. Da es außerdem leichter ist, ist es weniger Netzwerkübertragung, was es wiederum schneller macht. Auf diese Weise können Sie selbst bei langsamen Verbindungen wie 3G sehr reaktionsschnelle Anwendungen mit geringer Latenz haben. Daher ist dieser Ansatz für mobile Seiten und Anwendungen beliebt.

Es gibt Implementierung zahlreiche Bibliotheken JS - Vorlagen, eine der beliebtesten sind reine , Schnurrbart und dust.js . Später von LinkedIn verwendet, haben sie die Vorteile in ihrem Artikel "JSPs im Staub lassen: LinkedIn auf clientseitige Vorlagen von dust.js verschieben" beschrieben .

vartec
quelle
Ich mache meine erste Webapp (wie sie heutzutage genannt werden, habe ich Java / C ++ Hintergrund). Und es scheint mir selbstverständlich, viel HTML mit JS zu generieren, wenn der Benutzer einen Prozess durchläuft, bei dem er mehrere verschiedene UI-Komponenten benötigt, und ich die Seite nie neu
lade
2

Der Vorteil des Generierens von HTML auf dem Client besteht darin, dass Sie die Rendering-Arbeit auf jeden Client verlagern, der im Allgemeinen im Leerlauf auf die Antwort wartet. Freigabe weiterer Serverressourcen, um nur JSON-Daten und statischen Inhalt (HTML, JS und CSS) bereitzustellen.

Wir machen eine Web-App, die ausschließlich HTML mit Javascript generiert. 87% der Serverzugriffe sind JSON-Daten, der statische Inhalt wird in der Regel einmalig und dann aus dem Browser-Cache geladen.

Aber Sie können es nicht verwenden - zumindest nicht leicht -, wenn Sie SEO benötigen. Oder wenn Sie eine Zielgruppe mit deaktiviertem Javascript ansprechen, aber ich bin mir nicht sicher, ob diese für Youtube, Twitter, Facebook, Gmail, ... immer noch relevant ist.

Mic
quelle
0

In Bezug auf das dynamische Laden von Seiten sollte man wissen, dass hinter all den "JQuery AJAX Cloud!" Magie, nur zwei mögliche Dinge passieren:

  1. Der Code eines Elements wird in ein div (bad) oder eingefügt
  2. Inhalt wird in einen Iframe geladen (besser, aber es ist einfach nicht dasselbe ...)

In Bezug auf die ursprüngliche Frage erstelle ich HTML-Inhalte über Javascript, wenn ich eine Web-App erstelle, die XML- oder JSON-Daten liest, die auf dem Server gespeichert sind, und sie werden stark verändert.

Es wäre nicht sinnvoll, statischen Inhalt mit Javascript auf eine Seite zu laden, da es immer die Möglichkeit gibt, dass er nicht richtig geladen wird oder der Client ihn deaktiviert hat ("take that pesky ads!"). Darüber hinaus ist es sehr schwierig, HTML-Inhalte zu ändern, wenn sie in einer hässlichen document.write()oder einer Kette von Elementen verschmiert sind document.createElement().

Also hast du recht; Geben Sie entweder den rohen HTML-Code ein oder verwenden Sie ein serverseitiges Skript, um die erforderlichen Informationen auszugeben, wenn dynamischer Inhalt erforderlich ist. Verwenden Sie Javascript, um HTML nur dann einzufügen, wenn die Site ohne Internetverbindung oder in einem ähnlichen Fall funktionieren soll.

Eine letzte Anmerkung: Wenn Sie xmlhttprequests, ähm, AJAX, in eine Website implementieren möchten, ist es wahrscheinlich die beste / sicherste Methode, die Daten in einem Datenformat (wie XML) zu speichern, zu laden und entsprechend auszugeben auf dem Client. document.writeund ist element.innerHTMLwirklich nicht der beste Weg, um Inhalte zu manipulieren, und wird in Zukunft möglicherweise Kopfschmerzen verursachen (warum wird dieses Skript nicht ausgeführt? Mein kaputtes <i>Tag kursiv formatiert alles! usw.).

Jeffrey Sweeney
quelle
1
Das sind sicherlich nicht die einzigen Dinge, die passieren können. Javascript hat vollen Zugriff auf das DOM, und Sie können den DOM-Baum nach Belieben bearbeiten, wenn Sie eine AJAX-Antwort bearbeiten.
Tdammers
Warum ist das Injizieren von Inhalten in ein Div schlecht?
Peter Taylor
@ PeterTaylor Injizieren von Inhalten ist nicht schlecht, mit innerHTMList.
Raynos
@PeterTaylor Wenn ein oder zwei Elemente mit document.appendChildoder etwas hinzugefügt werden , gibt es wahrscheinlich keine Probleme. Das Problem ist, dass Code so aussieht div.innerHTML="<table cellpadding='0'><tr><td><label>Val:</label></td><td><input type='text' /></td></tr></table>- ein Albtraum, den es zu debuggen gilt.
Jeffrey Sweeney
Aber was hat das mit "JQuery AJAX Cloud!" Zu tun? Zauber'? Ihr Beispiel dort sieht eher nach seiner Antithese aus.
Peter Taylor
0

Mein Mantra dazu ist: Wenn es einfacher ist und sich niemand um das Markup kümmert.

Sie können auch beides nutzen und ein Limit definieren, bei dem es einfach zu schwierig ist, sich um das Markup zu kümmern und Sie sich lieber auf den DOM-Baum konzentrieren möchten. Beispiel: Bei einem Formular mit dynamischen Zeilen (z. B. "Einen weiteren Anhang hinzufügen") möchten Sie das Formular wahrscheinlich in HTML, die Schaltfläche "Zeile hinzufügen" und die Schaltfläche "Senden" ... Sie möchten es wahrscheinlich nicht generieren das HTML mit deiner serverseitigen Sprache oder so.

Eine andere Faustregel kann die Wiederverwendbarkeit sein. Wenn Ihre Lösung auf andere Probleme auf der Clientseite angewendet werden kann, kapseln Sie sie in js.

dukeofgaming
quelle
0

Wir erstellen einseitige Apps (z. B. Google Mail), und unsere Apps enthalten praktisch keine serverseitige HTML-Generierung. Stattdessen verwenden wir Backbone.js, um unsere Clientseite zu strukturieren, und Handlebars, um unsere JSON in Vorlagen zu rendern, die in die Seite eingefügt werden. Es funktioniert in der Tat sehr gut und wir nähern uns dem Ende unserer ersten App, die es verwendet, und wir werden in Zukunft ein noch größeres Projekt in Angriff nehmen.

Jede Art von Fat Client, bei dem der Server nur zum Speichern von Daten und zum Zurückgeben von Abfrageergebnissen verwendet wird, ist ein Aushängeschild für eine Zeit, in der JavaScript HTML generieren soll. Verwenden Sie nur eine gute Template-Engine, um die Arbeit zu vereinfachen.

John Munsch
quelle
0

Ich generiere HTML-Code in jquery, weil ich ein Portlet verwende. Nach der Ausführung des JSP-Codes muss ich eine Schleife mit HTML-Code erstellen, die ich in einer Java-for-Schleife nicht mit Javascript-Code erhalten kann. Also rendere ich Java Arraylist in einem Javascript Array und benutze die Strings um HTML zu generieren.

Laura Liparulo
quelle