Ce que la plupart des gens se trompent à propos du terme RSS

Le terme Server-Side Rendering (SSR) est souvent mal compris, beaucoup l'utilisant pour décrire des pratiques antérieures à sa création ou qui ne sont pas techniquement qualifiées. Des modèles PHP aux applications isomorphes de React, la définition du SSR a évolué, tout comme la confusion qui l'entoure.

Cet article plonge dans les origines de la RSS, ce qu'elle signifie réellement et pourquoi il est important de comprendre cette distinction dans le développement Web moderne.

Alors voici l'affaire

Nous n’avions pas SSR à l’époque de PHP. Ce terme n’existait pas. Elle a été créée dans les années 2010. Personne n’appelait cela SSR avant cela.

Comment l’appelaient-ils ? Si vous en croyez Wikipédia, cela s'appelait script côté serveur (par opposition aux scripts côté client).

Fait amusant : si vous consultez Wikipédia, ils n'ont même pas ajouté « SSR » à l'article scripts côté serveur avant 2021. Voici la différence. Et honnêtement ? Je pense que c'est faux.

---

Avant la RSS, il y avait...

Jusqu'à ce que React introduise le terme « rendu », nous n'utilisions pas ce mot. La chose la plus proche que nous avions était les modèles côté serveur. Voici un ancien instantané.

L'idée était simple : vous utiliseriez un générateur de site statique ou un script de serveur pour créer votre page Web dynamique.

Certaines personnes affirment : « Eh bien, si j’utilise des modèles de serveur, je les affiche sur le serveur. »

---

Le problème avec ça

Le rendu dans React ne signifie pas toujours produire du HTML ou du DOM. Il produit du VDOM (DOM virtuel). Les lignes sont floues lorsque vous appelez renderToString car le composant est alors réellement rendu au format HTML.

C'est pourquoi les gens ont commencé à prétendre que leurs applications PHP faisaient du SSR. Mais voici le problème : cela perd la distinction entre le SSR réel et les scripts dynamiques classiques.

---

La principale différence

Vous ne pouvez faire du SSR que sur des pièces qui pourraient également être rendues sur le client.

Par exemple :

const App = () => <div onClick={handleClick}>Hello</div>;

Vous pouvez exécuter cette application deux fois : une fois sur le serveur et une fois sur le client.

Mais :

<div><?php echo "Hello"; ?></div>

Cela ne peut pas s’exécuter sur le client. Il n'y a pas de rendu ici, pas de distinction « côté client » ou « côté serveur ». Il ne s’agit que de scripts dynamiques à l’ancienne.

---

SR contre RSS

Comme plus personne n'utilise ces anciens termes (sauf peut-être en ASP), je pense que j'abandonne et je l'appelle simplement Server Rendering (SR) vs. Server-Side Rendering ( RSS).

Une énorme différence est l'hydratation.

Dans le monde PHP, il n'y a pas d'hydratation, mais ils sont toujours sûrs d'avoir SSR. Cela n’a pas de sens. Vous ne pouvez avoir du SSR que si vous êtes hydraté.

---

Hydratation : la clé

React a deux méthodes clés :

• renderToStaticMarkup : produit du HTML que vous n'êtes pas censé hydrater. C'est plus proche des modèles de serveur.
• renderToString : produit du HTML qui s'hydrate sur le client. C'est la RSS.

Angular Universal n'avait pas SSR avant 2023. Ce qu'ils avaient, c'était SR : produire du HTML sur le serveur, puis le supprimer une fois les scripts chargés et rendre l'application en tant que SPA dans un étiqueter.

Ce n’est pas la même chose que PHP, mais ce n’est pas non plus la même chose que le vrai SSR.

---

Les premiers jours

Au début, les applications React étaient « pré-rendues » à l'aide de Chrome sans tête pour les enregistrer sous forme de chaînes HTML. Cet instantané est allé dans un CDN. Techniquement, un serveur n’était même pas nécessaire pour que cela fonctionne. ?

C'était une entreprise inutile, mais Google l'a recommandé à un moment donné pour le référencement. J'ai retrouvé cet article une fois, mais je ne suis pas sûr de pouvoir le retrouver.

---

Pourquoi s’en soucier ?

React Server Components (RSC) nous a obligés à revenir sur ce sujet.

Techniquement, RSC ne fait pas de SSR. Cela a surpris beaucoup de monde.

L'équipe React a essayé de l'expliquer mais a abandonné. L'essentiel est que les composants du serveur ne sont que des modèles : ils produisent du HTML statique. Les composants clients passent par SSR pour produire à la fois du HTML et du DOM.

---

Inertia.js et SSR

Inertia.js fait une distinction similaire. PHP s'exécute sur le serveur, mais votre application JavaScript obtient un SSR en s'exécutant sur le serveur pour produire du HTML, puis en s'hydratant sur le client.

---

Alors, PHP peut-il faire du SSR ?

Non. Comme RSC, PHP fait du script dynamique (SR) avec une étape qui fait du SSR.

Si vous exécutez une application React avec un middleware comme Hono, en injectant du code dynamique dans HTML et en appelant plus tard renderToString, cela semble similaire. Dans les deux cas, c’est du SR avec un pas de SSR.

C'est pourquoi c'est dingue quand les gens prétendent : « Nous avons fait du SSR en PHP dans les années 90. »

---

Et la SSG ?

Chaque fois que j'en parle, quelqu'un pose des questions sur SSG. Je m'en fiche.

Le terme Static Site Generation (SSG) est en fait antérieur à React. SSG signifie produire du HTML – aucun rendu ni hydratation n’est requis. Avez-vous produit du HTML ? Félicitations, vous faites SSG.

---

L'innovation React

Les frameworks React ont introduit des applications isomorphes, utilisant l'hydratation pour adopter le HTML sur le client sans le recréer.

Ce HTML devait être produit par SSR.

---

Qwik et « Reprise »

Qwik fait-il de l'hydratation ? C’est la grande question.

Les développeurs Qwik disent non, mais je penche pour le oui. Si vous aimez Qwik, vous devrez supprimer un autre morceau de SSR et l'appeler Resumability.

---

Si vous préférez écouter les discussions plutôt que lire, vous pouvez entendre davantage de ces arguments sous forme audio dans cet épisode de podcast sur les composants du serveur React dans Go

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!