it-swarm.com.de

Wann sollte JavaScript HTML generieren?

Ich versuche so wenig HTML wie möglich aus JavaScript zu generieren. Stattdessen ziehe ich es vor, vorhandene Markups zu bearbeiten, wann immer ich kann, und HTML nur zu generieren, wenn ich ein Element dynamisch 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 zu verfolgen ist. Meine Faustregel lautet: HTML ist für die Dokumentstruktur, CSS für die Präsentation, JavaScript 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?

34
VirtuosiMedia

Immer wenn ich in Javascript auf eine starke HTML-Generierung gestoßen bin, war dies fast ausschließlich in einem eigenständigen UI-Plugin der Fall. Dies ist sinnvoll, da das gesamte Plugin in einer einzigen JS-Datei (+ eine CSS-Datei zum Anpassen von Stilen) gekapselt werden kann, sodass es leicht 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, dass es sowohl sauberer, einfacher zu schreiben als auch einfacher zu warten ist, wenn Sie die HTML-Generierung von Javascript und auf der Serverseite fernhalten.

19
scrwtp

Ich denke, das Problem ist, dass Sie sauber geschriebene serverseitige Vorlagen mit schlecht geschriebener ad-hoc clientseitiger HTML-Generierung vergleichen. Natürlich ist der sauber geschriebene Code einfacher zu lesen, zu pflegen und zu verfolgen.

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

Es gibt viele clientseitige Vorlagenbibliotheken. Sie funktionieren ähnlich wie die serverseitigen. Was Sie bevorzugen sollten, ist der Leistungskompromiss kompliziert, aber JSON ist normalerweise kompakter als das HTML, das es wird, und wenn die Vorlage auf dem Client vorhanden ist kann einige Serveraufrufe eliminieren. Auf der anderen Seite ist JS auf dem Client möglicherweise deaktiviert oder 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 Browserfunktionen Ihrer Zielgruppe sind.

Es hängt jedoch genau davon ab, was Sie tun, ob Sie JS Ihrer Serverumgebung vorziehen, welche Vorlagenlösung Sie bevorzugen usw.

29
psr

Es gibt einen Trend zur Verwendung clientseitiger Vorlagen. Im Extremfall würde der Server nur die RESTful-API bereitstellen, z. B. im JSON-Format, während das gesamte Rendern clientseitig ausgeführt wird. Der Vorteil dieses Ansatzes besteht darin, dass JS-Code und -Vorlagen statische Ressourcen sind, die zwischengespeichert, übertragen und über CDN 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 Lightweight-Format zurückgeben, werden weniger serverseitige Ressourcen benötigt, wodurch die Antwort schneller wird. Da es auch leichter ist, ist es weniger Netzwerkübertragung, was es wiederum schneller macht. Auf diese Weise können Sie auch bei langsamen Verbindungen wie 3G eine sehr reaktionsschnelle Anwendung mit geringer Latenz haben. Daher ist dieser Ansatz für mobile Seiten und Anwendungen beliebt.

Es gibt zahlreiche Bibliotheken, die JS-Vorlagen implementieren. Eine der beliebtesten sind Pure , Moustache und Dust.js . Später von LinkedIn verwendet, haben sie die Vorteile in ihrem Artikel beschrieben "JSPs im Staub lassen: LinkedIn in die clientseitigen Vorlagen von Dust.j verschieben".

15
vartec

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. Geben Sie mehr Serverressourcen frei, um nur JSON-Daten und statische Inhalte (HTML, JS und CSS) bereitzustellen.

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

Aber Sie können es nicht verwenden - zumindest nicht einfach -, wenn Sie SEO benötigen. Oder wenn Sie eine Zielgruppe ansprechen, für die Javascript deaktiviert ist, ich aber nicht sicher bin, ob diese für Youtube, Twitter, Facebook, Google Mail usw. immer noch relevant ist.

2
Mic

Ich generiere HTML-Code in jquery, weil ich ein Portlet verwende und nach der Ausführung des JSP-Codes muss ich eine Schleife mit HTML-Code erstellen, die ich in einem Java für nicht bekommen kann) Schleife mit etwas Javascript-Code darin. Also rendere ich Java Arraylist in einem Javascript-Array und benutze die Strings, um HTML zu generieren.

0
Laura Liparulo

Wir erstellen einseitige Apps (ala Google Mail) und es gibt buchstäblich nein serverseitige HTML-Generierung in unseren Apps überhaupt. Stattdessen verwenden wir Backbone.js, um unsere Client-Seite zu strukturieren, und Handlebars, um unseren JSON in Vorlagen zu rendern, die in die Seite eingehen. Es funktioniert in der Tat sehr gut und wir sind am Ende unserer ersten App angelangt, 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 sie sauber und einfach zu machen.

0
John Munsch

In Bezug auf das dynamische Laden von Seiten sollte man erkennen, dass hinter all der Magie "JQuery AJAX Cloud!") Nur zwei mögliche Dinge passieren:

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

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

Es wäre nicht sehr sinnvoll, statischen Inhalt mit Javascript auf eine Seite zu laden, da immer die Möglichkeit besteht, dass er nicht richtig geladen wird oder der Client ihn deaktiviert ("Nehmen Sie diese lästigen Anzeigen!"). Außerdem ist es sehr schwierig, HTML-Inhalte zu ändern, wenn sie in einer hässlichen document.write() oder einer Kette von document.createElement() 's verwischt sind.

Du hast also recht; Geben Sie entweder den unformatierten 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.

Ein letzter Hinweis: Wenn Sie xmlhttprequests, ähm, AJAX, in eine Website implementieren möchten, ist es wahrscheinlich die beste/sicherste Möglichkeit, die Daten in einem Datenformat (wie XML) zu speichern, zu laden und entsprechend auszugeben auf dem Client. document.write und element.innerHTML ist wirklich nicht der beste Weg, um Inhalte zu manipulieren, und wird in Zukunft möglicherweise Kopfschmerzen verursachen (warum läuft dieses Skript nicht? Mein kaputtes <i> tag kursiv alles! usw.).

0
Jeffrey Sweeney

Mein Mantra dazu lautet: 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. Wenn Sie beispielsweise ein Formular mit dynamischen Zeilen haben (z. B. "Anderen Anhang hinzufügen"), möchten Sie wahrscheinlich das Formular in HTML, die Schaltfläche "Zeile hinzufügen" und die Schaltfläche "Senden" ... möchten Sie wahrscheinlich nicht generieren das HTML mit Ihrer 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.

0
dukeofgaming