Der vollständige Leitfaden für Junior-Entwickler zu SSR, SSG und SPA

Jedes Entwicklungstool-Unternehmen und -Team scheint davon auszugehen, dass Junior-Entwickler mit diesen Begriffen vertraut sind.

Als ich anfing zu programmieren, sah ich sie überall: Nuxt ist ein SSR-Framework, Sie können Gatsby für SSG verwenden und Sie können den SPA-Modus aktivieren, wenn Sie dieses oder jenes Flag in Ihrer next.config.js setzen.

Was zum Teufel?

Als ersten Schritt finden Sie hier ein Glossar – auch wenn es Ihnen nicht hilft, die Details zu verstehen:

• CSR = Clientseitiges Rendering
• SPA = Single Page Application
• SSR = Serverseitiges Rendering
• SSG = Static Site Generation

Lasst uns als nächstes etwas Licht ins Dunkel bringen.

Statische Webserver

Ursprünglich war eine Website eine HTML-Datei, die Sie von einem Server angefordert haben.

Ihr Browser würde den Server fragen: „Hey, können Sie mir diese /about-Seite geben?“ und der Server würde mit einer about.html-Datei antworten. Ihr Browser wusste, wie man diese Datei analysiert, und hat eine schöne Website wie diese gerendert.

Wir nennen einen solchen Server einen statischen Webserver. Ein Entwickler hat HTML und CSS (und vielleicht ein bisschen JS) von Hand geschrieben, es als Datei gespeichert, in einem Ordner abgelegt und der Server hat es auf Anfrage bereitgestellt. Es gab keine benutzerspezifischen Inhalte, sondern nur allgemeine, statische (unveränderliche) Inhalte, die für jedermann zugänglich waren.

app.get('/about', async (_, res) => {
  const file = fs.readFileSync('./about.html').toString();
  res.set('Content-Type', 'text/html');
  res.status(200).send(file);
})

Interaktive Web-Apps und anforderungsspezifische Inhalte

Statische Websites sind jedoch langweilig.

Es macht einem Benutzer viel mehr Spaß, wenn er mit der Website interagieren kann. Also haben Entwickler es möglich gemacht: Mit einem Hauch von JS konnte sie auf Schaltflächen klicken, Navigationsleisten erweitern oder ihre Suchergebnisse filtern. Das Web wurde interaktiv.

Dies bedeutete auch, dass die Seite /search-results.html unterschiedliche Elemente enthalten würde, je nachdem, was der Benutzer als Suchparameter gesendet hat.

Der Benutzer würde also etwas in die Suchleiste eingeben, die Eingabetaste drücken und eine Anfrage mit seinen Suchparametern an den Server senden. Als nächstes würde der Server die Suchergebnisse aus einer Datenbank abrufen, sie in gültiges HTML konvertieren und eine vollständige Datei /search-results.html erstellen. Der Benutzer erhielt die resultierende Datei als Antwort.

(Um die Erstellung von anforderungsspezifischem HTML zu vereinfachen, haben Entwickler HTML-Vorlagensprachen erfunden, wie z. B. „Barbars“.)

app.get('/search-results', async (req, res) => {
  const searchParams = req.query.q;
  const results = await search(searchParams);

  let htmlList = '<ul>';
  for (const result of results) {
    htmlList += `<li>${result.title}</li>`;
  }
  htmlList += '</ul>';

  const template = fs.readFileSync('./search-results.html').toString();
  const fullPage = embedIntoTemplate(htmlList, template);

  res.set('Content-Type', 'text/html');
  res.status(200).send(fullPage);
});

Ein kleiner Abstecher zum Thema „Rendering“

Lange Zeit fand ich den Begriff Rendering höchst verwirrend.

In seiner ursprünglichen Bedeutung beschreibt Rendering die Erstellung eines vom Menschen verarbeitbaren Bildes durch den Computer. In Videospielen beispielsweise bezieht sich Rendering auf den Prozess der Erstellung von beispielsweise 60 Bildern pro Sekunde, die der Benutzer als ansprechendes 3D-Erlebnis konsumieren kann. Nachdem ich bereits von Server Side Rendering gehört hatte, fragte ich mich, wie das funktionieren könnte – wie könnte der Server Bilder rendern, damit der Benutzer sie sehen kann?

Aber es stellte sich heraus, und das wurde mir etwas zu spät klar, dass „Rendering“ im Kontext von server- oder clientseitigem Rendering etwas anderes bedeutet.

Im Kontext des Browsers behält „Rendering“ seine ursprüngliche Bedeutung. Der Browser gerendert ein Bild, das der Benutzer sehen kann (die Website). Dazu bedarf es einer Blaupause, wie das Endergebnis aussehen soll. Dieser Entwurf liegt in Form von HTML- und CSS-Dateien vor. Der Browser interpretiert diese Dateien und leitet daraus eine Modelldarstellung ab, das Document Object Model (DOM), das er dann rendern und bearbeiten kann.

Lassen Sie uns dies auf Gebäude und Architektur abbilden, damit wir es etwas besser verstehen können: Es gibt einen Bauplan eines Hauses (HTML & CSS), der Architekt verwandelt ihn in ein kleines physisches Modell auf seinem Schreibtisch (das DOM). dass er es manipulieren kann, und wenn alle mit dem Ergebnis einverstanden sind, schauen sich Bauarbeiter das Modell an und „rendern“ es in ein tatsächliches Gebäude (das Bild, das der Benutzer sieht).

Wenn wir im Kontext des Servers über „Rendering“ sprechen, sprechen wir jedoch über das Erstellen, im Gegensatz zum Parsen, von HTML- und CSS-Dateien. Dies geschieht zunächst, damit der Browser die zu interpretierenden Dateien empfangen kann.

Wenn wir zum clientseitigen Rendering übergehen, meinen wir mit „Rendering“ die Manipulation des DOM (das Modell, das der Browser durch Interpretation der HTML- und CSS-Dateien erstellt). Der Browser wandelt dann das DOM in ein für Menschen sichtbares Bild um.

Clientseitiges Rendering und Single Page Applications (SPAs)

Mit dem Aufkommen von Plattformen wie Facebook benötigten Entwickler mehr und schnellere Interaktivität.

Die Verarbeitung eines Schaltflächenklicks in einer interaktiven Web-App nahm Zeit in Anspruch – die HTML-Datei musste erstellt, über das Netzwerk gesendet und vom Browser des Benutzers gerendert werden.

All that hassle while the browser could already manipulate the website without requesting anything from the server. It just needed the proper instructions — in the form of JavaScript.

So that's where devs placed their chips.

Large JavaScript files were written and sent to the users. If the user clicked on a button, the browser would insert an HTML component; if the user clicked a "show more" button below a post, the text would be expanded — without fetching anything.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Document</title>
  </head>
  <body>
    <div id="root"></div>
    <script>
      document.addEventListener('DOMContentLoaded', () => {
        const root = document.getElementById('root');

        root.innerHTML = `
            <h1>Home</h1>
            <button>About</button>
        `;

        const btn = document.querySelector('button');
        btn.addEventListener('click', () => {
          root.innerHTML = `
            <h1>About</h1>
        `;
        });
      });
    </script>
  </body>
</html>

Though the code snippet suggests the opposite, developers didn't write vanilla JavaScript.

Ginormous web apps like Facebook had so much interactivity and duplicate components (such as the infamous Like-button) that writing plain JS became cumbersome. Developers needed tools that made it simpler to deal with all the rendering, so around 2010, frameworks like Ember.js, Backbone.js, and Angular.js were born.

Of them, Angular.js was the one that brought Single Page Applications (SPAs) into the mainstream.

An SPA is the same as Client-Side Rendering, but it is taken a step further. The conventional page navigation, where a click on a link would fetch and render another HTML document, was taken over by JavaScript. A click on a link would now fire a JS function that replaced the page's contents with other, already preloaded content.

For this to work properly, devs needed to bypass existing browser mechanisms.

For example, if you click on a that's wrapped in a

element, the browser normally sends a POST request to the server and renders the HTML file of the response (an agreed upon standard all browsers conform to). But, since the server had already sent all the instructions, and the browser had now taken control over rendering pages, that behavior needed to be prevented.

Devs invented all kinds of hacks to bypass this and other mechanisms, but discussing those hacks is outside the scope of this post.

Server-Side Rendering

So what were the issues with that approach?

SEO and Performance.

First, if you look closely at the above HTML file, you'll barely see any content in the tags (except for the script). The content was stored in JS and only rendered once the browser executed the