- React reste le framework UI le plus utilisé, mais ces dernières années, la confusion, les polémiques et la méfiance ont augmenté dans la communauté ; l’absence de communication entre l’équipe officielle et les développeurs externes, combinée à un marketing maladroit, a amplifié les inquiétudes
- React 19 est sorti en version stable, avec l’ajout de fonctionnalités majeures comme les Server Components, le nouveau hook
use et l’intégration des formulaires, mais la politique « framework uniquement recommandé » et la structure centrée sur Next.js ont suscité beaucoup de mécontentement
- Des malentendus et du FUD se sont propagés, comme « React ne peut plus être utilisé correctement qu’avec Next.js » ou « le support du client-only va bientôt disparaître », alors qu’en réalité le rendu côté client ne disparaîtra jamais et que les RSC comme les fonctionnalités serveur restent entièrement optionnels
- La politique orientée framework de l’équipe React vise à standardiser les performances et l’architecture, tout en améliorant l’expérience utilisateur, mais le manque de considération pour les SPA et les architectures variées, ainsi qu’une documentation officieuse ou peu accueillante, ont accentué la confusion dans la communauté
- Ce n’est que récemment que diverses approches comme les SPA basées sur Vite ou Parcel ont été intégrées à la documentation officielle, mais le manque d’explications officielles sur les Server Components (RSC) et la faiblesse de la communication persistent
Introduction et objectif
- En 2025, la communauté React traverse une phase complexe mêlant succès, méfiance et controverse
- L’objectif de cet article est de revenir sur l’évolution de React, sa direction de développement et le contexte de ses principales décisions, afin de dissiper le FUD et la confusion
Parcours de l’auteur et historique de participation à la communauté
- Sans être membre de l’équipe React, il est fortement impliqué dans l’écosystème React depuis 2015
- Mainteneur de bibliothèques de la famille Redux, notamment Redux Toolkit, et acteur important de la communauté
- Participation à de nombreux tutoriels React/Redux, blogs, conférences et podcasts
- Rôles d’administration et de modération dans des communautés majeures comme Reactiflux Discord et le subreddit /r/reactjs
- Expérience de collaboration avec l’équipe React, par exemple comme alpha-testeur du hook
useSyncExternalStore, ainsi que participation à plusieurs groupes de feedback internes
- Contributions techniques variées à React DevTools, sourcemaps, Replay DevTools, etc.
-
Biais et limites à signaler
- Il reconnaît qu’il n’a pas toujours raison et que certaines explications peuvent être partiellement inexactes en raison des limites d’information, de malentendus ou du travail de synthèse
- En tant que mainteneur de Redux, son expérience de React est également principalement centrée sur les outils internes et les SPA
- Son expérience pratique du SSR, des RSC, du très grand trafic ou de l’i18n est limitée
- Il connaît bien les sujets débattus en profondeur dans la communauté, mais cela peut créer un certain décalage avec le quotidien d’un développeur d’applications plus généraliste
- Ses expériences personnelles, positives comme négatives, avec l’équipe React influencent aussi son point de vue
- Il affirme s’efforcer de présenter les faits aussi fidèlement que possible lorsqu’il explique le contexte historique et structurel
Brève histoire de React
- Développé en interne chez Facebook (aujourd’hui Meta) entre 2011 et 2012, puis open source en 2013
- Jusqu’à récemment, tout le développement central a été piloté par l’équipe React de Facebook/Meta
- Les concepts fondamentaux (composants, props, state, flux de données) sont restés, tandis que l’implémentation, les API et le champ d’application ont continuellement évolué
createClass → classes ES6 → composants fonctionnels avec prise en charge des Hooks- Extension à de nombreuses plateformes : mobile avec React Native, WebGL avec react-reconciler (react-three-fiber), CLI avec ink, etc.
- Refonte complète de l’architecture interne autour de « Fiber » (innovation structurelle et de performance)
- Introduction des Hooks en 2018 pour apporter état et effets aux composants fonctionnels
- Avec sa stratégie de « bibliothèque UI minimale (le V de MVC) », React a laissé à la communauté l’architecture, les frameworks de haut niveau, le build et la gestion d’état
- Cela a favorisé l’émergence de très nombreuses bibliothèques tierces et d’outils de build : Redux/Mobx/Zustand (état), Styled-Components/Emotion/CSS Modules (style), React Query/Apollo/SWR(RTK Query) (données), Webpack/Vite/Parcel, etc.
- Cette flexibilité est un atout, mais elle impose de choisir les bibliothèques nécessaires selon les projets, ce qui entraîne diversité des codebases, fatigue et absence de standard
-
Outils de build et CRA
- Au début, une configuration complexe de Webpack/Babel était indispensable
- Create React App (CRA) : CLI basée sur Webpack+Babel, masquant la complexité et permettant de créer un projet avec une seule commande, selon une logique de boîte noire
- La récupération de données et la gestion d’état dépendaient d’outils tiers séparés
- Le SSR (rendu côté serveur) existait dès les débuts, mais devait être implémenté manuellement
- Ensuite sont apparus des frameworks comme Next.js (SSR/routage basé sur le système de fichiers, data fetching), Gatsby (sites statiques, GraphQL) et Remix (loaders de données côté serveur)
-
React Server Components (RSC) et bascule vers les frameworks
- Fin 2020, présentation du prototype React Server Components (RSC), marquant une évolution architecturale visant à standardiser dans React les composants asynchrones et le data fetching serveur
- Pendant le développement, certains membres de l’équipe React ont rejoint Vercel et ont collaboré avec Next.js pour produire la première implémentation de l’App Router et des RSC
- Entre 2020 et 2023, refonte complète de la documentation officielle de React (react.dev), avec des tutoriels interactifs et une référence API renforcée
-
Évolution des recommandations officielles
- Par le passé, la documentation officielle recommandait de démarrer avec une SPA basée sur CRA, puis orientait vers Next, Gatsby, etc. en cas de besoin de SSR ou de site statique
- La nouvelle documentation (react.dev) recommande fortement l’usage d’un framework pour le routage, le data fetching et l’intégration du build, et ne cite que Next.js comme implémentation des RSC
- À partir de 2022 environ, CRA a de fait cessé d’être vraiment maintenu (sans être officiellement deprecated au départ, mais progressivement remplacé dans la communauté)
- Dans la documentation officielle comme dans la communauté, des formules telles que « Next.js, c’est le vrai React 18 » ont renforcé l’idée d’un lien très fort avec Next.js
React et les entreprises qui le portent
-
Meta (Facebook)
- React a toujours été un projet possédé et dirigé par Facebook/Meta
- Bien qu’open source, son développement effectif a été assuré par l’équipe React de Meta, avec des réunions clés et une feuille de route largement pilotées en interne
- Les nouvelles fonctionnalités sont validées et testées dans plusieurs équipes applicatives internes à Meta avant publication externe
- L’équipe React a bénéficié d’une grande liberté de développement et a piloté elle-même sa feuille de route et sa vision
- En interne, il fallait néanmoins démontrer en quoi les résultats et le projet contribuaient au business de Meta
- Meta utilise activement sa propre infrastructure serveur ainsi que ses propres technologies, comme GraphQL et Relay, et emploie React différemment de la communauté sur des aspects comme le routage ou la gestion d’état
- En conséquence, l’usage de bibliothèques tierces externes est moins fréquent chez Meta
-
Vercel, Next.js et React
- Vercel est à la fois une plateforme d’hébergement d’applications web et l’entreprise derrière le framework Next.js
- Son modèle économique consiste à diffuser des frameworks comme Next afin d’encourager l’hébergement sur la plateforme Vercel
- Son CEO, Guillermo Rauch, a très tôt accordé une grande confiance à la philosophie de rendu de React et y a fortement investi
- En 2021, Sebastian Markbage, alors leader de l’équipe React, a quitté Meta pour rejoindre Vercel, suivi notamment par Andrew Clark et Tom Occhino
- Les membres passés chez Vercel ont implémenté des fonctionnalités clés comme React Server Components (RSC) et le Next.js App Router à la fois côté React et côté Next.js
- Des ingénieurs de Vercel ont également apporté des contributions concrètes au cœur de React et aux fonctionnalités de rendu serveur
- En 2025, l’équipe React est répartie entre Meta et Vercel (Meta restant le principal pilier, mais Vercel contribuant aussi à des implémentations majeures du cœur), avec aussi quelques contributeurs externes
Les modes d’utilisation de React
-
Architectures standard
- React lui-même prend en charge des approches variées comme SPA, SSR, SSG ou hybride
- SPA : l’arbre React complet est rendu côté client dans une page HTML vide
- SSR : génération d’un HTML dynamique côté serveur à chaque requête
- SSG : génération anticipée de HTML statique au moment du build
- Combinaisons possibles avec plusieurs langages ou frameworks comme Python/Django, Ruby/Rails, PHP/WordPress, etc.
- Depuis environ 2015, le mode SPA (rendu côté client) était la norme, mais avec des compromis sur la vitesse du chargement initial, la taille du bundle JS ou le comportement natif du navigateur
- Le data fetching était initialement implémenté manuellement, souvent dans Redux, puis a été simplifié par l’apparition de hooks et bibliothèques dédiés comme React Query, Apollo, SWR ou RTK Query
- Des frameworks comme Next.js et Remix ont élargi les usages de React en standardisant le SSR, le SSG, le routage basé sur le système de fichiers et la structuration du data fetching
- Tendance générale vers des architectures fondées sur le SSR, incluant rendu serveur, prefetching et code splitting
- L’équipe React cherche à éviter le phénomène de « data fetching waterfall » et recommande des patterns d’optimisation tels que le prefetching au niveau des routes
-
État de l’usage des outils de build et des frameworks
- Principaux outils/frameworks :
- Next.js (SSR/SSG/RSC/SPA)
- Remix / React-Router v7 (SSR/SSG/SPA)
- Vite (SPA, outil de build, prise en charge de plugins pour divers frameworks)
- Create React App (SPA)
- Vite est né dans l’écosystème Vue, mais prend en charge React, Svelte et bien d’autres → plugin officiel React, standard de fait pour les outils de build de frameworks
- Remix et React-Router évoluent eux aussi récemment vers une structure de prise en charge SSR/SSG basée sur Vite
- Résumé des statistiques de téléchargement :
- Next.js domine très largement l’usage
- Le plugin React de Vite connaît une forte croissance et occupe la deuxième place
- CRA (
react-scripts) est en baisse depuis 2023, mais conserve encore un volume d’usage significatif
- Remix bénéficie d’un fort bouche-à-oreille, mais sa taille globale reste limitée, tandis que React Router progresse lentement vers son mode framework
- Gatsby est désormais loin derrière Next, Vite et CRA, et a même été dépassé récemment par Astro (site statique multi-framework)
- Astro n’est pas spécialisé React, mais son ampleur est comparable à celle de Remix
- En additionnant l’usage de Vite et de CRA, on atteint un niveau comparable à Next → la demande pour les approches SPA reste donc élevée
Les React Server Components (RSC) et leur relation avec les frameworks
-
Origine du développement des RSC et coopération avec Vercel
- L’infrastructure interne de Meta reposait déjà sur une architecture serveur maison, ce qui a limité le développement et les tests des RSC (React Server Components)
- Les RSC sont une conception tournée vers l’avenir portée directement par l’équipe React, née de sa vision indépendante, et non d’une consigne ou d’une demande de Meta ou de Vercel
- L’équipe React a proposé sa vision des RSC à Vercel, qui a rejoint le projet comme terrain d’expérimentation et partenaire de soutien
- Des membres clés du cœur de React, comme Sebastian Markbage et Andrew Clark, sont passés de Meta à Vercel, et l’équipe Next.js a construit l’App Router, première application concrète des RSC
- Dans ce processus, Next.js a été presque entièrement repensé et réimplémenté
- D’autres frameworks comme Shopify(Hydrogen) ou Remix ont bien participé à des tests et tentatives de coopération initiaux, mais sans engagement majeur ensuite
- Au final, seul le Next.js App Router s’est imposé comme une implémentation RSC réellement “production-ready” ; d’autres frameworks comme React Router, Parcel ou Waku travaillent encore à leur intégration, mais l’usage populaire reste dominé par Next
-
Structure d’intégration des RSC avec frameworks et bundlers
- La question « pourquoi les RSC ont-ils absolument besoin d’un framework ou d’un bundler ? » revient souvent
- Le SSR classique (
renderToString, renderToPipeableStream) peut s’exécuter partout, mais les RSC sont structurellement bien plus complexes
- Interprétation des directives
'use client' et 'use server' dans le code
- Nécessité d’automatiser la séparation et l’enregistrement des composants client et serveur
- Intégration étroite indispensable avec un bundler capable d’analyser et compiler tout le graphe de modules, comme Webpack ou Vite
- Le cœur de React ne fournit que la logique essentielle des RSC et les API de sérialisation des données ; le fonctionnement concret, le routage ou les appels aux endpoints relèvent du framework
- Chaque framework se distingue par sa manière d’utiliser, d’architecturer et d’implémenter les RSC
- Next.js App Router applique ses propres règles sur le layout, le routage, etc.
- Parcel, Waku, React Router et d’autres introduisent chacun une conception différente
- En résumé :
- Les RSC sont une fonctionnalité hybride intégrée au cœur de React, mais leur usage réel exige impérativement l’intégration d’un bundler ou d’un framework
- Les avantages des RSC ne deviennent exploitables en pratique que si le framework les prend en charge
Inquiétudes et confusion dans la communauté
-
1. L’inquiétude selon laquelle « Vercel a pris le contrôle de React »
- Le fait que Vercel emploie des membres importants de l’équipe React et que Next.js soit mis en avant dans la documentation et les exemples a nourri l’idée que « Vercel pilote le développement de React »
- En réalité, c’est l’équipe React qui a porté la vision des RSC et la structure du Next App Router, Vercel ayant surtout joué un rôle de soutien et de terrain d’expérimentation
- Plus qu’une prise de contrôle de React par Vercel, il s’agit plutôt d’une situation où une partie du core React a rejoint Vercel pour concrétiser cette vision
-
2. Le malentendu selon lequel « React ne fonctionne plus que dans Next »
- Comme Next.js est mis en avant comme seule implémentation RSC de production, ce malentendu s’est installé
- La documentation officielle de React mentionne pourtant d’autres frameworks ainsi que des usages sans framework
- Next n’est qu’un framework basé sur React ; React reste pleinement utilisable seul ou avec d’autres outils
-
3. La crainte de voir React disparaître des applications client
- L’accent mis sur les fonctionnalités serveur (RSC, SSR, etc.) nourrit des inquiétudes sur l’abandon du support des applications SPA côté client
- Les capacités de rendu côté client de React ne disparaîtront jamais
- De grandes codebases comme celles de Meta en font elles-mêmes un usage massif
- L’équipe React reste très attentive à la compatibilité et à l’accompagnement des migrations
-
4. « Pourquoi React force-t-il l’usage d’un framework ? »
- L’équipe React recommande par défaut les frameworks en raison de leurs avantages de productivité et de performance, notamment pour le data fetching, le routage et l’intégration du SSR
- Sa position est que la configuration manuelle (SPA sur mesure) est inefficace à long terme et que les frameworks représentent le standard de l’industrie
- Dans la pratique, les modes d’usage sont pourtant variés, et cette recommandation paraît trop uniforme
- Les SPA restent valables pour des raisons concrètes : barrière d’entrée pour les débutants, entreprises contraintes sur l’hébergement serveur, simplicité de l’hébergement SPA, etc.
- Le fait que la documentation officielle traite les approches « sans framework » comme secondaires a renforcé le sentiment d’exclusion dans la communauté
-
5. Limites de la documentation officielle et débat sur ses améliorations
- Avec la mise à l’écart officielle de CRA (
react-scripts), la mention tardive d’outils alternatifs comme Vite a accentué la confusion
- Les approches “sans framework” comme les SPA sont désormais reconnues officiellement et disposent aussi de guides (documentation la plus récente en 2025)
- La communauté et certaines figures de l’écosystème, comme Evan You, ont également critiqué le retard de la documentation officielle à mentionner des outils de build majeurs comme Vite
- Dans sa version améliorée, la documentation la plus récente recommande aussi les SPA, Vite/Parcel/RSPack, et propose des guides de choix pour les routeurs et le data fetching
-
6. Manque de documentation et d’explications officielles sur les RSC
- Par rapport aux ressources externes de Next.js, Vercel et d’autres, la documentation officielle de React reste insuffisante sur les RSC et leurs concepts
- On n’y trouve que des informations fragmentaires dans la référence API, sans véritable guide global sur les concepts et leur mise en œuvre
- La communauté et des figures importantes comme Dan Abramov fournissent activement des explications complémentaires, mais l’absence d’officialisation continue d’entretenir la confusion
- Le besoin d’ajouter dans la documentation des sections sur les concepts, l’architecture, les cas d’usage et la FAQ des RSC est régulièrement souligné
Synthèse des principales inquiétudes
- L’idée que l’insistance sur les frameworks et les fonctionnalités serveur serait motivée par les intérêts de Vercel s’est enracinée dans la communauté, alors qu’elle ne correspond pas à la réalité
- La communication de l’équipe React et certaines formulations de la documentation officielle ont toutefois contribué à alimenter ce malentendu
- Les capacités de rendu côté client de React seront maintenues à l’avenir ; les fonctionnalités serveur (RSC/SSR, etc.) ne sont qu’une option, et les approches existantes comme les SPA restent utilisables
- Les inquiétudes et la confusion de la communauté s’expliquent aussi en partie par le manque de communication de l’équipe React et la faiblesse des activités de relations développeurs (DevRel)
- Il faudrait des prises de position officielles, un travail de clarification et une meilleure reconnaissance de la diversité des patterns existants
- La recommandation d’« utiliser un framework » partait d’une intention positive, mais elle est perçue comme trop uniforme et comme marginalisant des modes d’usage variés
- Après 2025, la documentation officielle s’est améliorée pour reconnaître et guider aussi les SPA et les builds personnalisés, mais l’intégration des retours de la communauté a pris beaucoup de temps
- La documentation officielle doit encore être renforcée sur les concepts clés des RSC (React Server Components), leurs arbitrages et leurs implications
- Cela aiderait la communauté à mieux comprendre le sujet et à éviter des controverses inutiles
Conclusion
- Le texte répond à diverses questions sur la manière dont React a évolué, les influences et les objectifs qui orientent son développement, ainsi que sur la façon dont les différents modes d’usage se sont installés dans l’écosystème actuel
- Il cherchait à dissiper la confusion et le FUD (peur, incertitude et doute) apparus autour de la direction prise par l’équipe React et de ses changements
- Même si l’on n’adhère pas à l’orientation technique choisie ou que l’on ne voit pas l’intérêt d’utiliser les RSC ou de grands frameworks, les intentions et la direction de l’équipe React restent largement défendables
- Les choix de l’équipe React sont nés d’une volonté sincère de standardiser les performances et d’améliorer l’UX de la communauté, mais une communication peu accueillante et une documentation peu claire ont nourri une confusion inutile
- Le besoin de mieux respecter la diversité des usages réels — SPA, frameworks, outils de build variés — et d’améliorer la documentation officielle se renforce
- À l’avenir, une meilleure prise en compte des retours de la communauté, une documentation plus ouverte aux architectures variées et une communication transparente seront essentielles au développement sain de React
16 commentaires
React donne l'impression d'être une bibliothèque inachevée à laquelle il manque quelque chose... Par exemple, quand on voit tout ce qui est accumulé dans la documentation officielle de
useEffect... on ne peut qu'être sidéré... Construire autant de terriers de lapin comme ça, puis adopter une attitude du genre « débrouillez-vous pour bien l'utiliser », je ne comprends pas... J'ai souvent l'impression qu'ils bricolent des rustines sans vraiment réfléchir.En voyant les incidents chez AWS, je me suis dit une fois de plus...
Si tu n’es pas capable de proposer des améliorations, alors tu es junior
React Native a une ambiance assez similaire. Pour React, c’est Next.js ; pour React Native, c’est Expo. La documentation officielle recommande aussi d’utiliser le framework Expo, et l’ancienne méthode via CLI est désormais difficile à trouver.
En fait, il y a assez peu de sujets sur les enjeux du développement frontend web ici... Malgré ça, le fait que Next.js soit mentionné aussi souvent ces derniers temps me paraît assez révélateur.
On a l'impression que c'est surtout les Server Components qui posent problème, et que le reste va plutôt bien~
Côté JS/front-end, j’aimerais qu’on rase complètement l’écosystème une bonne fois pour toutes et qu’on reparte de zéro. Et qu’on crée aussi un framework qui intègre proprement tout ça, y compris la gestion d’état. Trop de choix ? Ce n’est pas de la liberté, c’est juste de l’irresponsabilité.
Dire qu’un framework est plus pratique et le fait que React abandonne lui-même CRA, c’est un sujet d’un tout autre ordre, à mon avis. J’ai trouvé ça un peu étrange que la nouvelle documentation de React dise d’emblée d’installer Next, donc je n’étais visiblement pas le seul à le ressentir.
Je pensais que Vercel et l’équipe de développement de React étaient distincts, mais en réalité leurs liens sont plus étroits que je ne le croyais.
Je fais du prototypage de jeux avec React, où je n’ai besoin que des interactions UI, de quelques calculs d’état internes et de l’affichage de l’état. Par rapport à il y a quelques années, quand create-react-app était sur le point d’être écarté de la documentation officielle, j’ai eu l’impression que récemment il était plus difficile de s’appuyer sur la documentation officielle pour faire l’installation. Je pense que l’article que j’avais écrit à l’époque peut être un peu pertinent.
Le fait même que les RSC aient été développés dès le départ sur une base Next.js ne semble pas différent en soi.
Si on ajoute à ça le fait que Next.js fonctionne de plus en plus difficilement en dehors de l’environnement de Vercel,
je ne sais pas exactement ce que pense l’équipe React en interne, mais on en arrive à une logique du type : les RSC, c’est l’avenir ! Mais pour faire tourner les RSC, on recommande Next.js, et pour Next.js, utilisez Vercel. Alors dire que cela n’a aucun lien avec les intérêts de Vercel… hum…
Même en affirmant qu’il s’agit d’un malentendu, au final les gens ne peuvent que ressentir que Vercel a phagocyté React, et est-ce qu’ils ont vraiment réagi rapidement pour dissiper ce malentendu ?
À l’heure actuelle, le site officiel de React tourne sur Vercel, et non sur les serveurs de Meta.
Je suis d’accord.
J’ai eu l’impression que Svelte, dans lequel Vercel investit également, est plus petit, donc je ne sais pas si c’est pour ça, mais je n’ai pas ressenti ce genre de vendor lock-in ; je me demande aussi d’où vient cette différence.
Svelte est seulement sponsorisé par Vercel, ce n’est pas Vercel qui le dirige. En revanche, Next est carrément piloté par Vercel.
Même dans le cas du dépôt GitHub, Next relève de l’organisation Vercel, alors que ce n’est pas le cas de Svelte.
Et sur Next.js, Vercel apparaît dans la mention de copyright du pied de page du site officiel, alors que ce n’est pas le cas pour Svelte.
On dirait que l’embauche de Rich Harris par Vercel relevait en fait d’une forme de soutien.
https://vercel.com/blog/vercel-welcomes-rich-harris-creator-of-svelte Oui, il s’agit d’un recrutement qui relève fortement du mécénat. L’idée est de lui verser un salaire pour qu’il puisse se consacrer à plein temps au développement de Svelte. Du côté de Vercel, il a aussi été clairement précisé que Svelte reste un projet indépendant.