Rendering Spectrum

Hier sind die Hauptkategorien des Renderns von Websites

• Client: Stellen Sie eine <div id="root"></div> bereit und lassen Sie eine JavaScript-Vorlage alles rendern.
• Statisch: Rendern Sie das HTML vor.
• Server: Lassen Sie einen Live-Server Anfragen verarbeiten und die HTML-Antwort generieren.

Sie schließen sich nicht gegenseitig aus.

• Eine Website könnte 75 % ihrer Seiten statisch vorab rendern (z. B. Blogbeiträge), aber die anderen 25 % haben einen Server, der darauf reagiert (z. B. Foren).
• Eine Website könnte alle Seiten statisch vorab rendern, aber ein paar leere <div>s darin haben, die clientseitig gerenderte Inhalte enthalten (z. B. ein dynamisch generiertes Menü basierend auf dem eingeloggten Benutzer).
• Eine Website könnte hauptsächlich serverseitig gerendert sein, aber einen Cache davor haben, sodass sie statisch funktioniert.
• Eine Website könnte statisch rendern, sich dann aber in eine vollständig clientseitig gerenderte Website „hydrieren“.
• Eine Website könnte eine Mischung aus Server- und statischem Rendering sein, aber dynamische Teile haben, ähnlich dem clientseitigen Rendering, die aber tatsächlich in einer Edge-Funktion stattfinden, sodass es eher dem serverseitigen Rendering ähnelt.

Next.js ist interessant, da es alle drei kann. Hier ist Tim Neutkens in einem aktuellen Interview

Next.js ermöglicht es Ihnen, Seiten vorab zu rendern. Es erstellt HTML auf einem Server zur Build-Zeit mit statischer Seitengenerierung oder verwendet Laufzeit-Rendering auf der Serverseite. Next ermöglicht Ihnen eine hybride Lösung. Im Gegensatz zu den meisten anderen Frameworks sind Sie nicht darauf beschränkt, Ihre App komplett statisch zu generieren. Stattdessen können Sie einige Seiten serverseitig und einige Seiten statisch generieren lassen.

In der neuen Version machen wir es möglich, diese statisch generierten Seiten zu aktualisieren, ohne einen neuen Build ausführen und Ihre gesamte App neu erstellen zu müssen.

Cool. Es ist gut zu sehen, dass dies auf Framework-Ebene geschieht. Es scheint, dass die vollständige Konzentration auf einen Rendering-Stil für viele Websites nicht praktikabel ist.

Client-Rendering ist am flexibelsten, birgt aber all diese ernsthaften Nachteile wie schlechtere Leistung, schlechtere Zuverlässigkeit, mehr Belastung für Geräte, schlechte SEO usw. Statisches Vorab-Rendering ist am robustesten, schnellsten und sichersten, aber am begrenztsten. Edge-Funktionen zusätzlich zu statischem Rendering beginnen Türen zu öffnen, aber serverseitiges Rendering ist die klassische Mischung aus Flexibilität und Geschwindigkeit, die das Web aus gutem Grund dominiert hat.

Client-Rendering eröffnet auch die Tür für dieses „SPA“-Gefühl (Single Page App). Das mag ich persönlich immer noch. Ich mag das Gefühl ohne Seitenaktualisierung. Es lässt eine Website schnell wirken und eröffnet die Möglichkeit für Seitenübergänge. Gatsby ist berühmt für die Popularisierung von Hydration, bei der Sie den Bonus des vorab gerenderten statischen Inhalts erhalten, der sich dann in eine SPA verwandelt, wenn das JavaScript heruntergeladen wird.

Ich würde gerne sehen, wie das Web den Punkt erreicht, an dem wir all diesen „guten Gefühlsbonus“ einer SPA erhalten, ohne tatsächlich eine SPA bauen zu müssen. Es ist bemerkenswert, wenn Frameworks SPA-Gefühle vermitteln, ohne dass Sie viel davon selbst verwalten müssen, aber trotzdem verwaltet *etwas* es, und dieses Etwas ist eine Menge JavaScript.

Tom Mac Wright hat kürzlich in seinem Artikel „If not SPAs, What?“ darüber geschrieben. Einige heutige Alternativen

Turbolinks … *was ist das absolute Minimum, das Sie tun müssen, um die SPA-Erfahrung zu erhalten, ohne jegliche Kooperation Ihrer Anwendung?*

Turbolinks ist wie… Link klicken, Klick wird abgefangen, eine Ajax-Anfrage für die neue Seite wird gestellt, JavaScript tauscht den Inhalt auf der Seite gegen den neuen Inhalt aus. Super einfach zu implementieren, aber es ist immer noch JavaScript und nicht besonders intelligent, wenn es darum geht, weniger Daten über die Leitung zu senden.

barba.js und instant.page sind alternative Ansätze für dasselbe Problem.

Barba dreht sich alles um Seitenübergänge (mehr Details zu diesem Konzept). instant.page dreht sich alles um das Vorladen/Vorabrendern von Seiten direkt vor dem Klick, so dass, obwohl Sie eine Seitenaktualisierung erhalten, es weniger störend wirkt (insbesondere mit Paint Holding). Beide sind cool, aber keine Eins-zu-Eins-Ersatz für eine SPA. (Selbst mit Paint Holding, Vorabrendern und leichten Seiten glaube ich immer noch nicht, dass die Erfahrung *ganz* so reibungslos ist wie bei einer SPA. Zum Beispiel sehen Sie immer noch den Ladebildschirm der Seite.)

Gibt es also noch etwas anderes in der Entwicklung? Irgendwie. Es gibt <portal>. Möglicherweise zu vereinfacht, aber hier ist es: Portale sind wie iframes. Sie können sogar visuell wie ein iframe dargestellt werden. Das bedeutet, dass das Rendern der URL im Portal bereits abgeschlossen ist. Dann können Sie das Portal zur aktiven Seite „befördern“ und das Portal dabei sogar animieren.

Ich hasse es nicht. Ich kann mir vorstellen, dass jemand eine turbolinksähnliche Bibliothek auf Portalen aufbaut, damit sie „einfach zu bedienen“ sind und eine Website SPA-ähnlicher machen.

Dennoch ist die Animation eines Rechtecks in Position oft nicht das, was man sich von animierten Seitenübergängen wünscht. Schauen Sie sich nur Sarahs Artikel „Native-Like Animations for Page Transitions on the Web“ an. Das wollen die Leute (zumindest die Möglichkeit dazu). Deshalb sagte Jeremy neulich *nicht Portale*, als er schelmisch sagte, dass „*die meisten Single-Page-Apps nur riesige Karussells sind*.“ Er verweist auch auf Jakes Navigation-Transitions-Vorschlag von vor ein paar Jahren.

Ich liebe diesen Vorschlag. Er konzentriert sich auf die Bedürfnisse der Benutzer. Er fragt auch *warum* Menschen zu JavaScript-Frameworks greifen, anstatt das zu nutzen, was Browser bieten. Menschen greifen zu JavaScript-Frameworks, weil Browser noch keine Funktionalität bieten: Komponenten wie Tabs oder Akkordeons; DOM-Diffing; Kontrolle über das Styling komplexer Formularelemente; Navigationsübergänge. Die Probleme, die JavaScript-Frameworks heute lösen, sollten als F&E-Abteilungen für Webstandards von morgen betrachtet werden. (Und umgekehrt glaube ich fest daran, dass das Ziel eines jeden guten JavaScript-Frameworks darin bestehen sollte, sich selbst überflüssig zu machen.)

Was ist also die beste Rendering-Methode? Was auch immer für Sie am besten funktioniert, aber vielleicht ist eine Hierarchie wie diese allgemein sinnvoll

1. So viel statisches HTML wie möglich
2. Edge-Funktionen über statischem HTML, damit Sie alle dynamischen Dinge tun können
3. Serverseitig generiertes HTML, was Sie danach tun müssen
4. Clientseitig nur das rendern, was Sie unbedingt müssen