Rendering von Webseiten

Beim Rendering werden Webbrowser angewiesen, DOM-Element zu erstellen, zu löschen oder zu verändern. Diese Anweisungen können durch entweder serverseitigen Code, clientseitigen Code oder durch beide erfolgen.

Clientseitiges Rendering (CSR)

Beim clientseitigen Rendering:

• findet entweder kein Austausch mit einem Server statt
• oder sendet der Server Daten, die in Formaten wie JSON oder XML serialisiert sind. Der Webclient deserialisiert diese und passt den DOM aufgrund dieser Daten entsprechend an.

Chancen:

• Der DOM kann selektiv verändert werden, so dass der Zustand bestimmter Element erhalten bleibt.
• Der DOM kann schneller aktualisiert werden, für Aktionen, die keine Kommunikation mit einem Server benötigen.

Risiken:

• Zusätzlich zum Server muss mitunter umfangreicher clientseitiger Code entwickelt werden – im Allgemeinen in einer weiteren Programmiersprache und ist somit dessen Randbedingungen unterworfen.
• Das Datenaustauschformat koppelt client- und serverseitigen Code implizit.
  • Dies kann gemindert werden, wenn client- und serverseitig die gleiche Codebasis für die De-/Serialisierung verwendet wird – entweder in Form von (transpiliertem) JavaScript oder mittels WebAssembly. Beide Varianten führen aber zu Einschränkungen von Performanz und/oder Beherrschbarkeit.

Zusammen ermöglicht dies SPAs.

Serverseitiges Rendering (SSR)

Beim serverseitigen Rendering sendet der Server bereits vollständig formatierte Dokumente (in Formaten wie HTML, CSS, SVG etc.) an den Webbrowser. Clientseitig muss kein Code ausgeführt werden.

Chancen:

• Serverseitig steht eine größere Auswahl an Programmiersprachen und Ökosystemen zur Verfügung.
• Es gibt keine Kopplung durch ein Datenaustauschformat.

Risiken:

• Der DOM kann nicht selektiv verändert werden.
• Die Last des Renderings kann nicht auf die Clients verteilt werden.

SPAs sind somit nicht möglich, nur MPAs.

Client- und serverseitiges Rendering

Das Setzen des innerHtml-Attributs von DOM-Elementen ist nicht langsamer als entsprechende Aufrufe von DOM-Methoden. Es ist somit praktikabel, serverseitig HTML-Strings zu generieren, sie mit den übrigen Daten zu übertragen und dem innerHtml-Attribut ausgewählter DOM-Elemente zuzuweisen. Anschließend können Eventhandler, mittels der Ergebnisse von z.B. Element.getElementsByClassName() gesetzt werden (Hydration).

Bei DOM-Elementen, für deren Erstellung oder Anpassung ohnehin Daten vom Server bezogen werden müssen, bietet sich dieses Vorgehen an.

htmx verwendet diesen Ansatz – allerdings auch für Interaktionen, die keine neuen Daten vom Server benötigen. Diese haben teilweise eine merkliche Latenz.

Chancen:

• Der DOM kann selektiv verändert werden, so dass der Zustand unveränderter Element erhalten bleibt.
• Der DOM kann schneller aktualisiert werden, da Kommunikation mit einem Server nur notwendig ist für Aktionen, die ohnehin Daten vom Server erfordern.
• Logik kann serverseitig, unter freier Wahl der Programmiersprache entwickelt werden. Die entsprechende Datenbehandlung und DOM-Manipulation entfällt im Client.
• Durch das reduzierte Austauschformat entsteht nur eine minimale Kopplung von client- und serverseitigem Code.

Risiken:

• Die Last des Renderings kann nicht auf die Clients verteilt werden.