Server: Mal wieder cool 

Es gab Witze nach dem Urlaub, dass JavaScript sich für Server-Side Rendering entschieden hat. Ich glaube, das wurzelte in

• Die Basecamp-Gang veröffentlicht Hotwire, was wie Marketing-Glamour für eine Kombination von Technologien wirkt. „HTML über das Draht“, sagen sie, was bedeutet, dass der Server HTML generiert und ausliefert und die clientseitige JavaScript-Logik den Aufgaben überlässt, die nur clientseitige JavaScript-Logik bewältigen kann.
• Die React-Gang mit Introducing Zero-Bundle-Size React Server Components, was meiner Meinung nach der erste Schritt des Kernprojekts in Richtung Server-Side-Anything ist.

Ich bin ganz Ohr für Marketing-Hype, aber es ist erwähnenswert, dass dies nur frische Ansätze für bereits solide (wenn ich es wagen darf, *alte*) Ideen sind.

Turbo („Das Herzstück von Hotwire“) ist eine Weiterentwicklung von Turbolinks, was eine äußerst einfache Grundidee ist: Klicks auf interne Links abfangen. Anstatt dass der Browser die Seite komplett neu lädt, wird der Inhalt der neuen Seite per fetch geladen, an Ort und Stelle eingefügt und die URL mittels History.pushState() aktualisiert. Nun hat man das Gefühl einer Single Page App, ohne eine SPA erstellt zu haben. Das ist äußerst praktisch, wenn man seine App bereits in Rails mit ERB-Vorlagen erstellt hat.

Aber ist das wirklich effizient? Nun, bisher war es nicht besonders beliebt. Die Denkweise war, dass das *Netzwerk* der Engpass ist, also lassen wir so wenig wie möglich über das Netzwerk senden. „So wenig wie möglich“ bedeutet normalerweise JSON. Wenn man JSON auf dem Client erhält, benötigt man nun ein Vorlagensystem auf dem Client, um es in nutzbaren DOM umzuwandeln. Mit dieser Technik zahlt man zwei Kosten: 1) das Laden einer clientseitigen Bibliothek 2) die Daten-zu-DOM-Verarbeitung. Wenn man „HTML über das Draht“ sendet, zahlt man keine dieser Kosten (schneller), sendet aber theoretisch größere Datenpakete über das Netzwerk (langsamer), was davon ausgeht, dass HTML schwerer ist als JSON, was... fragwürdig ist.

Also... *es kommt darauf an*. Es hängt davon ab, wie groß die Datenpakete sind und was damit geschehen soll.

Man würde erwarten, dass die React-Meinung lautet: Auf jeden Fall den Client nutzen. Aber das stimmt nicht mit der neuen Vorschau auf serverseitige Komponenten überein. Das Video macht überdeutlich: Das „Rendern“ der Komponenten auf dem Server ist schneller, besonders in verschachtelten Komponentensituationen, in denen viele der Komponenten für das Abrufen ihrer eigenen Daten verantwortlich sind. Was kommt dann über das Netzwerk? Ist es DOM-fertiges HTML? Hier nicht. Aus einem kurzen Blick auf das Video scheint die Netzwerkantwort ein proprietäres Format¹ zu sein, das eine React-Komponente beschreibt. Das scheint wichtig zu sein, da es bedeutet, dass das clientseitige JavaScript-Bundle diese Komponente überhaupt nicht enthält und Zustand² hin und her geschickt werden kann. Lauren Tan macht im Video auch klar: Das ist *so etwas wie* SSR, aber unterschiedlich von dem, wie etwas wie Next.js heute SSR macht. Und der Punkt ist, das Next.js von morgen weitaus besser zu machen.

Also: **Server**. Sie sind einfach gut darin, bestimmte Dinge zu tun (sagt der Typ, der in seinen WordPress-Blog tippt). Es scheint tatsächlich eine gewisse Dynamik dahin zu geben, weniger auf dem Client zu tun, was meiner Meinung nach die meisten von uns zustimmen würden, dass es in letzter Zeit ein wenig zu viel geworden ist, wobei die Asset-Größen immer weiter wachsen.

Lassen Sie uns diese Server an den Rand schieben, während wir schon dabei sind.