Le guide complet du développeur junior sur SSR, SSG et SPA-js tutoriel-php.cn

The Junior Developer

Chaque entreprise et équipe d'outils de développement semble supposer que les développeurs juniors connaissent ces termes.

Quand j'ai commencé à coder, je les ai vus partout : Nuxt est un framework SSR, vous pouvez utiliser Gatsby pour SSG, et vous pouvez activer le mode SPA si vous définissez tel ou tel indicateur dans votre next.config.js.

Qu'est-ce que c'est ?

Dans un premier temps, voici un glossaire – même s'il ne vous aidera pas à comprendre les détails :

CSR = Rendu côté client
SPA = Application à page unique
SSR = Rendu côté serveur
SSG = Génération de sites statiques

Ensuite, jetons un peu de lumière dans l'obscurité.

Serveurs Web statiques

Au départ, un site Web était un fichier HTML que vous demandiez à un serveur.

Votre navigateur demanderait au serveur : « Hé, pouvez-vous me remettre cette page /à propos ? » et le serveur répondrait avec un fichier about.html. Votre navigateur a su comment analyser ledit fichier et a rendu un beau site Web comme celui-ci.

Nous appelons un tel serveur un serveur Web statique. Un développeur a écrit manuellement du HTML et du CSS (et peut-être un peu de JS), l'a enregistré sous forme de fichier, l'a placé dans un dossier et le serveur l'a livré sur demande. Il n'y avait pas de contenu spécifique à l'utilisateur, seulement du contenu général, statique (immuable) accessible à tous.

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

Copier après la connexion

Applications Web interactives et contenu spécifique à la demande

Les sites Web statiques sont cependant ennuyeux.

C'est beaucoup plus amusant pour un utilisateur s'il peut interagir avec le site Web. Les développeurs ont donc rendu cela possible : avec une touche de JS, elle pouvait cliquer sur des boutons, développer les barres de navigation ou filtrer ses résultats de recherche. Le Web est devenu interactif.

Cela signifiait également que la page /search-results.html contiendrait différents éléments en fonction de ce que l'utilisateur avait envoyé comme paramètres de recherche.

Ainsi, l'utilisateur tapait dans la barre de recherche, appuyait sur Entrée et envoyait une requête avec ses paramètres de recherche au serveur. Ensuite, le serveur récupèrerait les résultats de la recherche dans une base de données, les convertirait en HTML valide et créerait un fichier /search-results.html complet. L'utilisateur a reçu le fichier résultant en réponse.

(Pour simplifier la création de code HTML spécifique à une requête, les développeurs ont inventé des langages de modèles HTML, tels que guidons.)

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);
});

Copier après la connexion

Un petit détour sur le "rendu"

Pendant très longtemps, j'ai trouvé le terme rendu très déroutant.

Dans son sens originel, le rendu décrit l'ordinateur créant une image traitable par l'homme. Dans les jeux vidéo, par exemple, le rendu fait référence au processus de création, disons, de 60 images par seconde, que l'utilisateur pourrait consommer comme une expérience 3D engageante. Je me suis demandé, ayant déjà entendu parler du Rendu côté serveur, comment cela pourrait fonctionner : comment le serveur pouvait-il restituer des images que l'utilisateur pourrait voir ?

Mais il s'est avéré, et je m'en suis rendu compte un peu trop tard, que le « rendu » dans le contexte du rendu côté serveur ou côté client signifie une chose différente.

Dans le contexte du navigateur, « rendu » garde son sens originel. Le navigateur rend une image que l'utilisateur peut voir (le site Web). Pour ce faire, il lui faut un plan de ce à quoi devrait ressembler le résultat final. Ce plan se présente sous la forme de fichiers HTML et CSS. Le navigateur interprétera ces fichiers et en dérivera une représentation de modèle, le Document Object Model (DOM), qu'il pourra ensuite restituer et manipuler.

Mappons cela aux bâtiments et à l'architecture pour mieux le comprendre : il y a un plan d'une maison (HTML et CSS), l'architecte le transforme en un modèle physique à petite échelle sur son bureau (le DOM) donc qu'il peut le manipuler, et lorsque tout le monde est d'accord sur le résultat, les ouvriers du bâtiment regardent le modèle et le « transforment » en un bâtiment réel (l'image que l'utilisateur voit).

Quand on parle de « rendu » dans le contexte du Serveur, cependant, on parle de création, par opposition à l'analyse, de fichiers HTML et CSS. Ceci est fait en premier pour que le navigateur puisse recevoir les fichiers à interpréter.

Passons au rendu côté client, lorsque nous parlons de « rendu », nous entendons manipuler le DOM (le modèle que le navigateur crée en interprétant les fichiers HTML et CSS). Le navigateur convertit ensuite le DOM en une image visible par l'homme.

Rendu côté client et applications à page unique (SPA)

Avec l'essor de plateformes comme Facebook, les développeurs avaient besoin d'une interactivité de plus en plus rapide.

Le traitement d'un clic sur un bouton dans une application Web interactive prenait du temps : le fichier HTML devait être créé, il devait être envoyé sur le réseau et le navigateur de l'utilisateur devait le restituer.

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>

Copier après la connexion

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