Le changement de paradigme de React

React est en période de transition, abandonnant l’approche 100% client au profit d’une autre où le serveur est un acteur majeur du rendu des interfaces.

Pourquoi ? Intéressons-nous aux principaux symptômes qui témoignent de cette transformation.

L’arrivée des Server Components

Encore présentés comme expérimentaux à l’heure où cet article est rédigé, cela fait déjà quelques années que le sujet est sur la table, et qu’il semble fortement influencer la roadmap et le contenu des releases.

Voici les motivations derrière cette fonctionnalité tel que décrite dans la spécification :

Les Server Components abordent un certain nombre de défis rencontrés dans React à travers une grande variété d’applications. Nous avons d’abord cherché des solutions ciblées à ces problèmes, car cela peut souvent mener à des solutions plus simples. Cependant, nous n’étions pas satisfaits des approches auxquelles nous aboutissions. Le problème fondamental était que les applications React étaient centrées sur le client et ne profitaient pas suffisamment du serveur. Si nous pouvions permettre aux développeurs de tirer parti de leur serveur plus facilement, nous pourrions résoudre tous ces problèmes et offrir une approche plus puissante pour construire des applications, petites ou grandes.

Ces défis se divisent en deux grandes catégories. Tout d’abord, nous voulions faciliter pour les développeurs l’obtention de bonnes performances par défaut. Ensuite, nous voulions simplifier la récupération de données dans les applications React.

(Note : traduction du texte original en anglais, voir source.)

En allant plus loin dans la spécification, on comprend un autre point important : les Server Components sont vues comme une API complémentaire aux frameworks SSR (Server-Side Rendering) : L’équipe React travaille avec les frameworks et comptent sur eux pour permettre une mise à disposition facile de cette nouvelle fonctionnalité.

(...), l’utilisation des Server Components nécessitera une intégration avec le système de routage et le bundler d’une application. Pour aider la communauté à comprendre comment cela peut fonctionner, nous nous concentrerons dans un premier temps sur l’ajout de la prise en charge des Server Components dans un ou plusieurs frameworks.

Cela justifie sûrement les deux points qui vont suivre.

Le semi-abandon de Create React App

Ancien outil privilégié pour démarrer une SPA (Single-Page Application) React, il est maintenant considéré par la communauté comme déprécié, bien que ça n’ai jamais été acté officiellement.

Voici un extrait d’un tweet de Dan Abramov (éminent développeur chez Meta) qui donne un peu de contexte sur le désintérêt de ses créateurs  :

Quand je réfléchissais à l’avenir possible de Create React App, il était évident qu’une approche uniquement client n’avait plus de sens. C’est bien trop limitant.

Pourquoi produisons-nous toujours un fichier HTML vide si React peut pré-rendre en HTML ? Pourquoi ne puis-je pas créer un blog en utilisant map() sur des fichiers markdown sur mon disque ?

[...]

Voici le point essentiel : la génération actuelle de frameworks modernes (notamment Next.js et Gatsby) fonctionne déjà ainsi.

Ils vous permettent de commencer de manière 100 % statique et client. Génération HTML, routage basé sur les fichiers, navigation de type SPA et vrai code côté client (autant que vous le souhaitez). C’est la base.

Cependant, si vous voulez utiliser le serveur pour une route dynamique – comme lire à partir d’une base de données au lieu d’un fichier – ils vous le permettent facilement. Il suffit de modifier quelques lignes de code. Vos pages existantes restent statiques/client.

Ces frameworks impliquent donc moins de verrouillage technologique.

Je me suis rendu compte que construire cela reviendrait à créer une version plus limitée de ce que Next.js ou Gatsby offrent déjà. Cela ferait exactement les mêmes choses, mais ne permettrait pas d’en faire plus.

Les frameworks modernes sont hybrides. Ils permettent de construire des SPA et bien plus encore.

(Note : traduction du texte original en anglais, voir source.)

Les nouvelles recommandations de la doc

La documentation React présente maintenant les frameworks SSR comme la solution par défaut pour démarrer une nouvelle application React.

Vous pouvez tout à fait utiliser React sans framework – c’est ainsi que vous utiliseriez React pour une partie de votre page. Cependant, si vous construisez une nouvelle application ou un site entièrement avec React, nous recommandons d’utiliser un framework.

Voici pourquoi.

Même si vous n’avez pas besoin de routage ou de récupération de données au départ, vous voudrez probablement ajouter des bibliothèques pour cela. À mesure que votre bundle JavaScript grossit avec chaque nouvelle fonctionnalité, vous pourriez avoir à découper le code pour chaque route individuellement. À mesure que vos besoins en récupération de données se complexifient, vous rencontrerez probablement des “waterfalls” réseau client-serveur qui ralentiront votre application. Si votre audience inclut des utilisateurs avec de mauvaises connexions réseau et des appareils bas de gamme, vous devrez peut-être générer du HTML à partir de vos composants pour afficher du contenu rapidement – soit sur le serveur, soit pendant la phase de construction. Modifier votre configuration pour exécuter une partie de votre code sur le serveur ou pendant la construction peut être très compliqué.

[…]

(Note : traduction du texte original en anglais, voir source.)

C’est assez clair : l’équipe derrière React ne considère plus la SPA comme un paradigme viable pour la plupart des applications web.

En se reposant sur les bénéfices apportés par les frameworks, l’équipe React souhaite mettre en avant une nouvelle approche, plus orientée serveur.

Est-ce que les SPAs sont derrière nous ?

Ce changement de politique n’a pas vraiment d’influence sur la validité de l’approche. Cela fait des années que le développement web frontend s’articule principalement autour de librairies SPA, et si l’approche SSR comble certains de leurs problèmes, tout ça n’est pas nouveau.

Les frameworks SSR et les Server Components ajoutent une couche de complexité supplémentaire à des outils déjà décriés pour leur complexité, justifiant l’émergence d’autres librairies plus simples comme Svelte ou htmx.

Nul doute que ce sont des solutions bénéfiques pour beaucoup d’applications. 

Mais pas pour toutes ! Si vous n’avez pas besoin de SEO, et que ni la taille de votre bundle ni l’optimisation de la récupération des données ne sont des préoccupations importantes, vous n’en avez probablement pas besoin. Choisissez les outils qui sont bons pour vous.