Wann sollte JavaScript HTML generieren?

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?

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.

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.

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 .

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.

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.).

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.

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.

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.