React se présente lui-même comme une bibliothèque d’interface utilisateur. Pas un framework, pas un outil full-stack, pas un socle d’architecture. Cette distinction, loin d’être anecdotique, conditionne la manière dont on structure un projet JavaScript, les dépendances qu’on embarque et la liberté (ou le fardeau) laissée aux développeurs.
La confusion persiste parce que React est devenu le centre de gravité d’un écosystème massif. Quand on parle de « React » au quotidien, on désigne souvent React plus un routeur, plus un bundler, plus un gestionnaire d’état, voire un méta-framework comme Next.js. La bibliothèque seule ne couvre qu’une fraction de ce périmètre.
A lire en complément : Comment Internet a-t-il affecté l’interaction sociale ?
Inversion de contrôle : le critère technique qui sépare bibliothèque et framework
La frontière entre bibliothèque et framework repose sur un principe d’architecture logicielle : l’inversion de contrôle. Avec une bibliothèque, c’est le développeur qui appelle le code. Avec un framework, c’est le framework qui appelle le code du développeur.
Angular impose un cycle de vie, un système d’injection de dépendances, un routeur intégré, un module HTTP, des conventions de nommage. Le développeur s’insère dans un cadre prédéfini. React ne fait rien de tout cela.
A voir aussi : Quel type de réseau est le web ?
React expose une API de composants et un mécanisme de rendu via le DOM virtuel. Il ne prescrit ni la structure des dossiers, ni la gestion du routing, ni la couche de données, ni le tooling de build. Le développeur reste maître du flux d’exécution principal. Il importe React, l’utilise dans son code, et décide quand et comment le rendu se déclenche au sein de son application.
Ce point n’est pas cosmétique. Il explique pourquoi deux projets React peuvent avoir des architectures radicalement différentes, alors que deux projets Angular se ressemblent structurellement.
Ce que React ne fournit pas (et qu’un framework JavaScript inclut)
Pour mesurer concrètement l’écart, il suffit de lister ce qu’un framework front-end typique embarque nativement et que React laisse au choix du développeur :
- Le routing : React ne gère aucune navigation entre pages. React Router, TanStack Router ou le système de fichiers de Next.js comblent ce vide, mais aucun n’est fourni par la bibliothèque elle-même.
- La gestion d’état globale : au-delà du state local d’un composant, React ne propose pas de solution intégrée pour partager un état complexe entre composants distants. Redux, Zustand, Jotai ou Recoil sont des choix externes.
- Le rendu côté serveur : React peut fonctionner sur le serveur, mais il ne fournit ni serveur HTTP, ni stratégie de rendu hybride. C’est Next.js ou Remix qui orchestrent le SSR et les React Server Components.
- Les conventions de projet : aucun CLI officiel n’impose une arborescence. Create React App a longtemps servi de point d’entrée, mais il n’a jamais été prescriptif sur l’architecture applicative.
En comparaison, Angular intègre un routeur, un client HTTP, un système de formulaires, un compilateur dédié et une CLI qui génère des modules selon une convention stricte. Vue.js, bien que plus léger qu’Angular, propose officiellement Vue Router et Pinia pour la gestion d’état.
React et les méta-frameworks : la frontière devient floue
La distinction bibliothèque/framework autour de React se complique depuis l’émergence des méta-frameworks. Next.js, construit sur React, ajoute le routing par système de fichiers, le rendu serveur, la génération statique, les API routes et, plus récemment, l’App Router avec les React Server Components.
Quand un développeur utilise Next.js, il travaille dans un environnement fortement prescriptif. Next.js impose des conventions que React seul n’impose jamais : structure de dossiers, séparation composants serveur/client, stratégies de cache. L’inversion de contrôle s’applique pleinement.
C’est précisément cette réalité qui alimente la confusion. La majorité des projets React en production s’appuient sur un méta-framework. React seul ne suffit plus pour la plupart des applications web modernes. Le site officiel de React recommande lui-même d’utiliser un framework comme Next.js ou Remix pour démarrer un nouveau projet.
Cette recommandation est révélatrice. React reconnaît implicitement que son périmètre de bibliothèque UI ne couvre pas les besoins d’une application complète. La bibliothèque a besoin d’un cadre autour d’elle pour devenir opérationnelle à l’échelle d’un produit.
Pourquoi cette distinction compte pour un projet web
Qualifier React de framework ou de bibliothèque n’est pas un débat sémantique réservé aux puristes. Ce positionnement a des conséquences directes sur la gouvernance technique d’un projet.
Liberté d’architecture et coût de décision
Choisir React comme bibliothèque signifie assumer un coût de décision élevé à chaque couche de l’application. Quel routeur adopter, quel gestionnaire d’état, quel outil de build, quelle stratégie de rendu. Chaque choix ouvre un arbre de dépendances, de documentation et de maintenance distinct.
Un framework tranche ces questions en amont. Le développeur gagne en vitesse de démarrage et en cohérence, mais perd en flexibilité. Avec React, c’est l’inverse : la flexibilité est maximale, mais la cohérence repose entièrement sur les décisions de l’équipe.
Recrutement et montée en compétence
Sur un projet Angular, un nouveau développeur retrouve des conventions familières d’un projet à l’autre. Sur un projet React, l’architecture varie d’une équipe à l’autre, parfois radicalement. Deux développeurs « React » peuvent avoir des compétences très différentes selon qu’ils ont travaillé avec Next.js, Remix, Vite ou un setup Webpack personnalisé.
Cette hétérogénéité complique l’onboarding et la portabilité des compétences entre projets.
Bibliothèque React ou framework React : ce que dit la documentation officielle
Le site fr.react.dev se présente explicitement comme « la bibliothèque pour des interfaces utilisateurs web et natives ». Pas de mention de framework. React se définit par ce qu’il fait : rendre des composants, gérer leur état local, réconcilier le DOM.
Dyma et d’autres plateformes de formation utilisent parfois le mot « framework » quand elles parlent de React avec son écosystème complet. Cette distinction entre React-bibliothèque et React-écosystème est la source principale du malentendu.
Le terme « framework React » décrit en réalité l’assemblage de React avec des outils tiers qui, ensemble, remplissent le rôle d’un framework. React lui-même reste une brique. La confusion vient du fait que personne n’utilise cette brique seule en production.
Appeler React un framework par commodité n’est pas une erreur grave au quotidien. En revanche, au moment de choisir une stack technique, de dimensionner une équipe ou de planifier la maintenance d’un projet sur plusieurs années, comprendre que React délègue l’architecture à son écosystème évite des surprises coûteuses.
