React l’emporte par défaut et ralentit l’innovation front-end

• Aujourd’hui, l’adoption de React se fait par défaut plutôt que pour sa supériorité technique, ce qui ralentit l’innovation dans l’écosystème front-end
• De nombreuses équipes choisissent « React, que tout le monde connaît » sans examiner les contraintes, si bien que les effets de réseau dictent les décisions d’architecture davantage que l’adéquation technique
• Des frameworks innovants comme Svelte, Solid et Qwik proposent de meilleurs modèles de performance, mais restent à l’écart de la compétition grand public faute d’adoption
• React a beaucoup de qualités, mais le vrai problème est que la mentalité du React-par-défaut augmente le coût d’opportunité et empêche d’envisager de meilleures alternatives
• Le message est qu’un écosystème sain a besoin de diversité et de concurrence, et qu’il faut choisir un framework non pas par défaut, mais selon les contraintes et l’adéquation

---

La victoire de React par défaut, et ses limites

• React n’est plus souvent choisi pour sa supériorité technique, mais adopté comme option par défaut
  • Cela renforce l’habitude, dans les équipes, d’utiliser automatiquement React sans évaluer les contraintes du projet
• Les frameworks alternatifs (Svelte, Solid, Qwik), bien qu’ils aient des avantages de performance sur React dans certains scénarios, ne sont pas correctement évalués
• Plus qu’un problème propre à React, c’est la mentalité du React-par-défaut qui crée une structure freinant l’innovation

Le plafond de l’innovation

• Le Virtual DOM de React était pertinent en 2013, mais agit aujourd’hui comme une surcharge inutile
• Les Hooks ont résolu les problèmes des composants en classe, mais ont introduit de nouvelles complexités, comme les tableaux de dépendances et les stale closures
• Les Server Components et le React Compiler tentent d’améliorer les performances, mais il s’agit de moyens de contourner les limites du modèle React
• À l’inverse, les Runes de Svelte, la réactivité fine de Solid et la resumability de Qwik montrent un potentiel supérieur avec des modèles totalement différents

Dette technique

• Choisir React par défaut entraîne des coûts d’exécution inutiles et une charge de gestion des re-renders
• Les développeurs passent du temps sur les dépendances d’effets ou la gestion de l’hydration au lieu de produire de la valeur métier
• Dans les benchmarks, Solid affiche des performances de mise à jour 2 à 3 fois supérieures à celles de React
• Une pensée centrée sur les patterns React affaiblit les fondamentaux du web et renforce l’inertie architecturale

Les frameworks alternatifs

• Svelte : la révolution du compilateur

  • Svelte traite l’essentiel du travail au moment de la compilation et élimine le virtual DOM
  • Les composants se rapprochent davantage de la structure native du web, et la surcharge à l’exécution diminue fortement
  • Mais son taux d’adoption reste faible à cause de la perception selon laquelle « il y a peu d’opportunités professionnelles »
  • The Guardian, Wired, Shawn Wang et d’autres cas montrent qu’après adoption de Svelte, la taille des bundles et les temps de chargement ont fortement diminué, tandis que la productivité de développement s’est améliorée
  • Par exemple, Shawn Wang a réduit la taille de son site de 187KB avec React à 9KB avec Svelte

• Solid : une approche primitive de la réactivité fine

  • Solid combine une réactivité de précision (micro-réactivité) avec la syntaxe JSX
  • Via les signal, il accède directement uniquement au DOM modifié, en évitant complètement le goulot d’étranglement de la reconciliation
  • Il se distingue par ses excellentes performances et la simplicité de sa gestion d’état
  • Les cas d’adoption restent encore limités, mais l’expérience des premières équipes montre des gains majeurs à la fois en efficacité et en simplicité du code

• Qwik : l’innovation de la resumability

  • Qwik se distingue par un démarrage immédiat grâce à la resumability, au lieu de l’hydration traditionnelle
  • Il ne charge progressivement que les fonctionnalités nécessaires au moment voulu, et permet de sérialiser à la fois l’état et le code
  • Il se montre particulièrement performant sur les grands sites, les sessions longues et les réseaux lents
  • Beaucoup d’équipes ne l’ont pas encore essayé, mais celles qui l’ont adopté rapportent de fortes améliorations à la fois sur le temps de chargement initial et l’efficacité des ressources

• La complexité de l’API React et la simplicité des frameworks alternatifs

  • L’API de React comprend des concepts complexes comme les hooks, context, reducer, memoization, etc., ce qui augmente la charge cognitive des développeurs
  • En cas de mauvaise utilisation, le risque de bugs liés aux dépendances et de surconception devient important
  • Par exemple, la panne de Cloudflare du 12 septembre 2025 a aussi été causée par une erreur de configuration du tableau de dépendances de useEffect
  • À l’inverse, des alternatives comme Svelte, Solid et Qwik mettent en avant, avec des API bien plus petites et ciblées, la simplicité et les principes fondamentaux du web
  • Ces trois frameworks disposent tous d’une supériorité technique suffisante, mais la culture du React par défaut fait qu’ils ne sont, dans la plupart des cas, même pas testés

La prison des effets de réseau

• La domination de React crée des barrières auto-renforçantes
• Le marché de l’emploi ne recherche que des « développeurs React », et chaque organisation fige ses bibliothèques de composants et habitudes de développement autour de React
• Les dirigeants cherchant à éviter le risque choisissent naturellement le React jugé sûr, et les établissements de formation s’alignent sur ce choix
• C’est la marque d’un écosystème où la concurrence saine a disparu

Briser les effets de réseau

• Pour sortir de cette situation, un choix conscient est nécessaire
• Les responsables techniques doivent abandonner l’inertie et décider de l’architecture en fonction des exigences, et les entreprises peuvent allouer un budget pilote pour tester des alternatives
• Les développeurs, eux aussi, doivent éviter de s’enfermer dans un seul paradigme et apprendre l’esprit de plusieurs frameworks
• Les établissements de formation doivent renforcer les cours sur des concepts agnostiques vis-à-vis des frameworks, et les contributeurs open source peuvent soutenir davantage les petits écosystèmes
  Le changement ne vient pas tout seul : il faut le provoquer intentionnellement.

Checklist d’évaluation d’un framework

Pour un nouveau projet, les critères suivants peuvent servir de base d’évaluation

• Exigences de performance : chargement initial, efficacité des mises à jour, taille du bundle, et recours ou non à l’optimisation au moment de la compilation
• Compétences de l’équipe et courbe d’apprentissage : tenir compte de l’expérience existante, en sachant qu’il existe aussi des alternatives compatibles avec React comme Solid
• Scalabilité et coût de possession : évaluer les coûts de long terme, y compris la maintenance, la gestion des dépendances et la dette technique
• Adéquation avec l’écosystème : équilibre entre maturité et innovation, essais pilotes sur des tâches non critiques et test du ROI

Objections fréquentes et réponses

• Maturité de l’écosystème : un écosystème plus ancien n’est pas nécessairement mieux adapté aux problèmes d’aujourd’hui. Une forte dépendance aux packages tiers entraîne aussi des effets secondaires comme un fardeau de maintenance, des vulnérabilités de sécurité et l’alourdissement des bundles. À l’inverse, un petit écosystème peut davantage se concentrer sur les fondamentaux du web, et les progrès des outils d’IA permettent de développer plus facilement et plus rapidement des solutions sur mesure.
• Problème de recrutement : la demande devient en soi un critère de recrutement. Il est possible de tester des alternatives dans des domaines non critiques, puis de combler les lacunes par l’apprentissage sur le terrain.
• Bibliothèques de composants : des design systems indépendants des frameworks, ainsi que l’usage de Web Components, permettent de réduire le verrouillage tout en préservant la productivité.
• Stabilité : React lui-même continue d’évoluer sans cesse avec les hooks, les Server Components, etc. Les frameworks alternatifs proposent souvent au contraire des API plus cohérentes.
• Nécessité de validation à grande échelle : autrefois, jQuery aussi était une référence mondiale. Rien ne garantit que les succès du passé restent valables à l’avenir.

Les effets néfastes sur l’écosystème et l’industrie dans son ensemble

• La monoculture React ralentit le développement du web lui-même
• Les talents et les capitaux se concentrent sur la résolution des problèmes de React, tandis que les innovations propres à la plateforme sont retardées
• Les établissements de formation renforcent aussi, avec des cursus centrés sur l’employabilité immédiate, l’apprentissage de compétences peu transférables
• Le développement de la plateforme web elle-même se heurte à la réponse « React suffit », et le manque de diversité de l’écosystème finit, à long terme, par nuire à tout le monde

L’écosystème souhaitable que nous pouvons construire

• La diversité est une condition indispensable à un écosystème sain
• C’est lorsque plusieurs paradigmes se concurrencent et échangent que l’innovation naît
• Les développeurs progressent en apprenant plusieurs façons de penser, et la plateforme web elle-même avance grâce à cette diversité d’expérimentations

• Miser entièrement sur un seul framework crée un point unique de défaillance. Une fois ses limites atteintes, la croissance s’arrête et de meilleures opportunités disparaissent aussi
• Pour chaque projet, il faut choisir en fonction des contraintes techniques et de l’adéquation, sans se reposer uniquement sur React comme valeur par défaut
• Seule la diversité garantit une véritable innovation

• Il est temps de ne plus planter tous la même “graine” (React), mais de participer, par des expérimentations plus diverses entre frameworks, à rendre l’écosystème web plus résilient et plus innovant
• Le choix nous appartient