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 werden vom Server ausschließlich Daten bezogen, die der Webclient verwendet, um den DOM entsprechend anzupassen.

SPAs sind somit möglich.

Chancen:

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

Risiken:

• Zusätzlich zum Server muss mitunter umfangreicher clientseitiger Code entwickelt werden – vielfach 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.

Serverseitiges Rendering (SSR)

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

SPAs sind nicht möglich, nur MPAs.

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.

Gemischtes Rendering

Das Setzen des innerHtml-Attributs von DOM-Elementen ist nicht langsamer als entsprechende Aufrufe von DOM-Methoden. Es ist somit praktikabel, serverseitig DOM-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 Veränderungen, die keine 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.