03 June 2012 HTML, Rendering, REST Robert Muehsig

Ein Grundkonzept des Webs war es, dass der Browser eine Anfrage zum Server stellt und als Antwort HTML, CSS und Javascript zurück bekommt. Durch den Einsatz von Javascript und schlanken REST Services wurde es nach und nach populärer das HTML Rendering auf den Client zu verlagern. Da mich diese Frage auch interessiert und Twitter als einer der Großen von Client-seitigem Rendering wieder Abstand genommen hat, möchte ich auch meine Gedanken weitergeben.

Typischer Ablauf beim Server-Side Rendering

Beim “klassischen” Modell fragt der Client den Server an und der Server antwortet mit einem kompletten HTML Markup und schickt es zum Client zurück. Hierbei kann der Server das HTML über ASP.NET oder andere Server-Seite Sprachen erzeugen oder es ist einfach eine statische HTML Datei. Der Client an dieser Stelle ist relativ dumm, da er nur das Markup lädt und anzeigt bzw. bei AJAX Requests es in die DOM einhängt.

Typischer Ablauf beim Client-Side Rendering 

Die erste Antwort vom Server ist in diesem Fall kein komplettes HTML Markup sondern es werden Templates und andere “Grundgerüst” Elemente zum Client zurückgeschickt. Erst im nächsten Schritt werden wirklich Daten angefordert und sobald die Antwort kommt wird es über eine Javascript Templating Engine in die DOM eingefügt. Hierbei gibt es eine große Anzahl, z.B. Hogan.js.

Twitter Probleme dabei

Wie bereits erwähnt: Lange Zeit hat Twitter das Client-Side Rendering bevorzugt und dabei auch den Trend der Hashbangs mit erstellt. Twitters stieß allerdings auf Performance-Probleme, was im Ablauf der Client-Side Renderings begründet ist. Beim Aufruf eines Tweets versteckt sich in der ersten Antwort des Servers nur Template Sachen. Die Daten werden erst in einem zweiten Request geladen. Nun hat es Twitter wieder zum “alten” Modell umgestellt, mit dem Ergebnis das der Aufruf eines Tweets (bei einer neuen Session) um 1/5 schneller ist.

Da ich bei einem Projekt vor der gleichen Entscheidung stand, hier mal die Pro- und Contra-Argumente aus meiner Sicht

Client-Side Rendering – die guten Seiten

Durch das Templating und Rendering auf dem Client werden die Services auch wesentlich schlanker – man geht vermutlich automatisch in die Richtung REST.

Zudem erhöht sich die (gefühlte) Flexibilität, da man sehr gut Services miteinander kombinieren kann und oftmals benötigt man pure Daten ohne Markup um eine moderne Web-App schick aussehen zu lassen.

Client-Side Rendering – die schlechten Seiten

Die Performance kann negativ beeinträchtigt werden – sieh der Fall von Twitter. Allerdings sind das Probleme der “ganz Großen”.
Ein viel größeres Problem ist die erhöhte Komplexität die man sich dadurch in die Applikation holt. Server-seitiges rendern ist durch IDEs wie Visual Studio & co. ziemlich ausgereift und lässt sich auch prima debuggen. Auf der Client-seite muss man erst einmal die passende Engine finden. Durch Knockout.js (obwohl das noch eine Ecke mehr macht als “rendern”) und Hogan.js (das von Twitter kommt).
Eine andere Problematik kann je nach Art der Anwendung auch Suchmaschinenoptimierung sein. Google und co. mögen immer noch kein Javascript. Wenn beim Seitenaufruf nur Templates zurückkommt, aber kein Content, dann ist dies für Suchmaschinen vermutlich eher hinderlich.
Frameworks wie ASP.NET MVC samt Razor haben viele Mechaniken drin, welche man erst im Javascript nachbilden muss. Ein Beispiel ist die Validierung, welche in einer “klassischen” MVC Anwendung mit Data-Annotations kein großes Problem mehr ist. Wenn man dies auch über Javascript rendern lassen möchte, muss man sich überlegen wie die Fehlermeldungen (welche z.B. im ModelState sind) nun als JSON zurückgegeben werden. Das Feld hier ist recht groß und vermutlich wird es komplex (aber durchaus möglich!).
Natürlich muss Javascript auch angeschaltet sein, aber das sollte heutzutage ja kein Problem mehr sein.

Doch lieber Server-seitiges Rendering?

Ich denke beide Varianten kann man gut miteinander kombinieren, sodass der erste Aufruf schnell ist und Google mit Content versorgt werden kann und kleinere Sachen können via REST Services und Javascript Templating angezeigt werden. Aber ich denke das ist ohnehin der Weg den bereits viele gehen ;)

Weitere Informationen

Ich hab diese Präsentation gefunden und kann zudem diesen Blogpost empfehlen.


Written by Robert Muehsig

Software Developer - from Saxony, Germany - working on primedocs.io. Microsoft MVP & Web Geek.
Other Projects: KnowYourStack.com | ExpensiveMeeting | EinKofferVollerReisen.de