Der Begriff Server-Side Rendering (SSR) wird oft missverstanden, da viele ihn verwenden, um Praktiken zu beschreiben, die vor seiner Entstehung entstanden sind oder sich technisch nicht qualifizieren. Von PHP-Vorlagen bis hin zu den isomorphen Apps von React hat sich die Definition von SSR weiterentwickelt – und damit auch die damit verbundene Verwirrung.
Dieser Artikel befasst sich mit den Ursprüngen von SSR, was es wirklich bedeutet und warum es in der modernen Webentwicklung wichtig ist, den Unterschied zu verstehen.
Zu Zeiten von PHP gab es kein SSR. Dieser Begriff existierte nicht. Es wurde in den 2010er Jahren erstellt. Vorher nannte niemand dieses Zeug SSR.
Wie nannten sie es? Glaubt man Wikipedia, hieß es serverseitiges Scripting (im Gegensatz zu clientseitigem Scripting).
Lustige Tatsache: Wenn Sie sich Wikipedia ansehen, haben sie bis 2021 nicht einmal „SSR“ zum Artikel über serverseitiges Scripting hinzugefügt. Hier ist der Unterschied. Und ganz ehrlich? Ich denke, das ist falsch.
Bis React den Begriff „Rendering“ einführte, haben wir dieses Wort nicht verwendet. Das, was uns am nächsten kam, waren serverseitige Vorlagen. Hier ist ein alter Schnappschuss.
Die Idee war einfach: Sie würden einen statischen Site-Generator oder Server-Scripting verwenden, um Ihre dynamische Webseite zu erstellen.
Einige Leute argumentieren: „Wenn ich Servervorlagen verwende, rendere ich sie auf dem Server.“
Das Rendern in React bedeutet nicht immer, HTML oder DOM zu erstellen. Es erzeugt VDOM (virtuelles DOM). Die Linien verschwimmen, wenn Sie renderToString aufrufen, da die Komponente dann tatsächlich in HTML gerendert wird.
Aus diesem Grund begannen die Leute zu behaupten, ihre PHP-Apps würden SSR ausführen. Aber hier liegt das Problem: Dadurch geht die Unterscheidung zwischen tatsächlichem SSR und regulärem dynamischen Scripting verloren.
Sie können SSR nur für Teile durchführen, die auch auf dem Client gerendert werden könnten.
Zum Beispiel:
const App = () => <div onClick={handleClick}>Hello</div>;
Sie können diese App zweimal ausführen: einmal auf dem Server und einmal auf dem Client.
Aber:
<div><?php echo "Hello"; ?></div>
Dies kann nicht auf dem Client ausgeführt werden. Hier gibt es kein Rendering – keine Unterscheidung zwischen „Client-Seite“ und „Server-Seite“. Das ist einfach altmodisches dynamisches Scripting.
Da niemand mehr diese alten Begriffe verwendet (außer vielleicht in ASP), gebe ich wohl auf und nenne es einfach Server Rendering (SR) vs. Server-Side Rendering ( SSR).
Ein großer Unterschied ist die Flüssigkeitszufuhr.
In der PHP-Welt gibt es keine Flüssigkeitszufuhr, aber sie sind sich trotzdem sicher, dass sie über SSR verfügen. Das ergibt keinen Sinn. Sie können SSR nur haben, wenn Sie ausreichend Flüssigkeit zu sich nehmen.
React hat zwei Schlüsselmethoden:
Angular Universal hatte SSR erst 2023. Was sie hatten, war SR: HTML auf dem Server erstellen, es dann löschen, sobald Skripte geladen waren, und die App als SPA in einem leeren
rendern. Etikett.Das ist nicht dasselbe wie PHP, aber es ist auch nicht dasselbe wie echtes SSR.
Schon früh wurden React-Apps mit Headless Chrome „vorgerendert“, um sie als HTML-Strings zu speichern. Dieser Schnappschuss ging in ein CDN. Technisch gesehen war dafür nicht einmal ein Server erforderlich. ?
Es war ein sinnloses Unterfangen, aber Google hat es irgendwann für SEO empfohlen. Ich habe diesen Artikel einmal aufgespürt, bin mir aber nicht sicher, ob ich ihn wiederfinden kann.
React Server Components (RSC) hat uns gezwungen, dieses Thema noch einmal aufzugreifen.
Technisch gesehen führt RSC kein SSR durch. Das hat viele Leute überrascht.
Das React-Team versuchte es zu erklären, gab aber auf. Das Wesentliche ist, dass Serverkomponenten nur Vorlagen sind – sie erzeugen statisches HTML. Clientkomponenten durchlaufen SSR, um sowohl HTML als auch DOM zu erzeugen.
Inertia.js macht eine ähnliche Unterscheidung. PHP läuft auf dem Server, aber Ihre JavaScript-App wird SSR-fähig, indem sie auf dem Server ausgeführt wird, um HTML zu erzeugen und dann auf dem Client zu hydrieren.
Nein. Wie RSC führt PHP Dynamic Scripting (SR) mit einem Schritt aus, der SSR ausführt.
Wenn Sie eine React-App mit einer Middleware wie Hono ausführen, dynamischen Code in HTML einfügen und später renderToString aufrufen, fühlt es sich ähnlich an. In beiden Fällen handelt es sich um SR mit einer SSR-Stufe.
Deshalb ist es verrückt, wenn Leute behaupten: „Wir haben in den 90er Jahren SSR in PHP gemacht.“
Jedes Mal, wenn ich das anspreche, fragt jemand nach SSG. Es ist mir egal.
Der Begriff Static Site Generation (SSG) existierte tatsächlich schon vor React. SSG bedeutet, HTML zu erstellen – kein Rendern oder Hydratieren erforderlich. Haben Sie HTML erstellt? Herzlichen Glückwunsch, Sie machen SSG.
React-Frameworks führten isomorphe Apps ein und nutzten Hydration, um HTML auf dem Client zu übernehmen, ohne es neu zu erstellen.
Dieser HTML-Code musste von SSR erstellt werden.
Spendet Qwik Feuchtigkeit? Das ist die große Frage.
Qwik-Entwickler sagen Nein, aber ich tendiere zu Ja. Wenn Ihnen Qwik gefällt, müssen Sie ein weiteres Stück SSR abschneiden und es Wiederaufnahmefähigkeit nennen.
Wenn Sie lieber Diskussionen zuhören als lesen, können Sie in dieser Podcastfolge über React Server Components in Go weitere dieser Argumente in Audioform hören
Das obige ist der detaillierte Inhalt vonWas die meisten Leute über den Begriff SSR falsch machen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
![[Web-Frontend] Node.js-Schnellstart](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
