- Une réflexion qui compare Backbone au début des années 2010 et React en 2025, pour revenir sur la question de savoir à quel point le frontend a réellement progressé en 15 ans
- React paraît sobre et moderne en apparence, mais simule la simplicité grâce à des couches d’abstraction complexes
- Backbone est plus verbeux, mais le flux des événements et la manipulation du DOM sont explicites, ce qui permet même à un développeur débutant de suivre facilement le fonctionnement
- Avec React, le state management, les tableaux de dépendances et les problèmes de closure rendent le débogage difficile si l’on ne comprend pas son fonctionnement interne
- Au final, l’article revient à l’essentiel — « événements + état = UI » — et pose la question de la nécessité d’un nouveau modèle plus simple et plus hackable
15 ans de progrès
- Exemple d’un champ de saisie de mot de passe, l’un écrit avec un framework des années 2010 (Backbone), l’autre avec React après plus de 10 ans d’évolution
- Les deux implémentations ont une longueur comparable et offrent la même fonctionnalité
- React a bénéficié d’innombrables heures de travail de développeurs et du soutien d’un vaste écosystème
- Pourtant, l’auteur estime que la vraie question intéressante n’est pas « à quel point React s’est amélioré », mais plutôt « à quel point il a peu progressé »
- React donne une illusion de simplicité en surface, alors qu’en réalité la complexité de ses abstractions le rend plus difficile à comprendre
- Backbone exprime explicitement un flux simple : événement déclenché → exécution du handler → génération du HTML → insertion dans le DOM
- À l’inverse, React masque son fonctionnement interne, et dès qu’on dépasse les exemples simples, on rencontre des problèmes impossibles à résoudre sans comprendre les mécanismes internes
L’illusion de la simplicité (The Illusion of Simplicity)
- Le code React paraît propre, mais cela vient du choix d’une complexité abstraite plutôt que d’une simplicité explicite
- Backbone est verbeux, mais montre clairement « ce qui se passe et à quel moment »
- Même un développeur débutant peut suivre facilement le flux du code
- Dans React, le state interne et la logique de rendu sont cachés, ce qui provoque souvent des bugs inattendus
- Exemple : si l’on remplace la key d’un élément de liste par son index, React le considère comme un autre composant et réinitialise son état
- Si
value devient undefined, on observe une transition de composant non contrôlé vers contrôlé, ce qui réinitialise la valeur saisie
- Avec
useEffect, les boucles infinies sont aussi un problème fréquent
- Si le tableau de dépendances contient un objet recréé à chaque rendu, React le considère comme modifié
- Pour l’éviter, il faut stabiliser les identités avec
useMemo et useCallback
- Cela oblige à se préoccuper de concepts dont on n’avait pas besoin auparavant
- Il existe aussi le problème des handlers de clic qui référencent un état périmé (stale state)
- Parce que la fonction capture l’état au moment de sa création
- Les solutions consistent à mettre l’état dans le tableau de dépendances, ou à utiliser des mises à jour fonctionnelles comme
setState(x => x + 1)
- Mais dans les deux cas, cela ressemble davantage à des contournements qu’à de vraies solutions
Le prix de la magie (Magic Has a High Price)
- Ces problèmes ne sont pas des cas exceptionnels, mais des situations courantes dans les applications de taille intermédiaire ou plus
- Pour déboguer, il faut comprendre l’algorithme de reconciliation, la render phase et le scheduler (batch update)
- React fonctionne souvent selon une logique de « ça marche même sans savoir pourquoi », mais quand un problème survient, il faut connaître l’intérieur pour le résoudre
- La complexité est telle qu’on entend souvent dire que « pour vraiment comprendre React, il faut en implémenter un soi-même »
- Il existe des tutoriels comme “Build your own React”
- Mais le fait de devoir comprendre le virtual DOM, les priorités de scheduling et le rendu concurrent pour créer un simple validateur de mot de passe a une portée critique évidente
- Backbone et jQuery reposent sur une structure honnête et hackable
- On peut lire et modifier directement le code source
- Leur base fondée sur les méthodes du DOM facilite la compréhension et l’extension
- À l’inverse, les couches d’abstraction de React rendent l’accès à l’interne et la modification plus difficiles
Quelle est la suite ? (So, What's Next?)
- En fin de compte, React comme Backbone cherchent tous deux à résoudre le même problème : « événements + état = UI »
- Dans les applications à grande échelle, la complexité de React peut se justifier, mais pour la plupart des applications petites ou moyennes, elle représente une charge excessive
- Il faut un nouveau modèle d’UI, fondé sur la simplicité et la transparence
- Un système aussi robuste que le DOM, mais plus intuitif
- Une structure, comme Backbone ou jQuery, immédiatement compréhensible et modifiable
2 commentaires
Pour les applications petites à moyennes, j’ai l’impression qu’il vaudrait mieux concevoir des classes JavaScript plutôt que d’utiliser Backbone ou jQuery, afin de mieux se préparer à la suite.
Réapprendre par cœur les templates de jQuery ou de Backbone pour avancer me semble être une régression.
Discussion sur Hacker News
J’ai utilisé Backbone, Angular 1, Ember et React
Il ne faut pas passer à côté des raisons pour lesquelles React est devenu populaire. En matière de composition de composants, de gestion des événements, de gestion d’état et de mises à jour efficaces du DOM, React a résolu des problèmes chroniques des frameworks précédents
Avec Backbone, la gestion du cycle de vie du DOM était complexe, et le fait de devoir définir les gestionnaires d’événements sous forme de chaînes rendait la maintenance difficile. React a simplifié ces problèmes grâce à un flux d’état unidirectionnel et au DOM virtuel
Aujourd’hui, si je voulais utiliser du JS pur, je pense qu’une solution de templates comme lit-html serait bien meilleure que Backbone
Le front-end était complexe avant et l’est toujours aujourd’hui, mais c’est beaucoup moins douloureux maintenant
La complexité d’une application ne vient pas du nombre de composants, mais de la gestion d’état
J’ai souvent eu des problèmes d’interface qui se figeait à cause du flux de données bidirectionnel du Backbone Store. La vraie innovation de React, c’était l’architecture Flux centrée sur un flux de données unidirectionnel
Je pense qu’un bon framework est un outil qui vous conduit naturellement vers un « Piège du succès » (Pit of Success). React a bien rempli ce rôle
Par exemple, des problèmes comme les stale closures, les boucles
useEffectinfinies ou la réinitialisation des champs de saisie à cause d’un changement de clé n’existaient pas dans BackboneLes problèmes de Backbone étaient visibles et faciles à déboguer, alors que ceux de React sont cachés derrière des abstractions
La plupart des applications n’ont pas l’échelle de Facebook, donc une approche explicite et simple peut parfois être préférable
Décréter qu’une technologie populaire est « mauvaise » ressemble à une forme d’arrogance naïve
Bien sûr, la popularité ne garantit pas la qualité, mais penser que tous les excellents ingénieurs du monde entier se sont fait berner est exagéré
Quand les grandes entreprises et le marketing poussent une techno, les CTO l’adoptent, et quand une carrière est en jeu, personne ne dit « ce n’est pas terrible ». Popularité ≠ pertinence
React n’a pas gagné uniquement grâce à sa supériorité technique, mais aussi grâce au marketing de Facebook et à l’auto-renforcement de son écosystème
Même après 15 ans, la longueur et la complexité du code n’ont pas vraiment diminué. C’est simplement devenu complexe autrement
Regarder en arrière n’a rien à voir avec la nostalgie : il s’agit de vérifier si nous avons ajouté une complexité disproportionnée
Le web ressemble toujours à une frontière sauvage des design patterns. Une fois que j’ai accepté ça, je me suis senti plus serein
Au final, il faut réévaluer les trade-offs pour chaque projet
L’argument « React n’est pas nécessaire pour les choses simples » est une erreur classique sur React (React fallacy)
Évaluer React à partir d’exemples simplistes, c’est comme « évaluer un langage à la longueur d’un Hello World »
Si on utilise React aussi pour les choses simples, c’est parce qu’on l’utilise aussi pour les choses complexes. Un ensemble d’outils cohérent est avantageux pour la maintenance
Backbone était « un framework en apparence, mais en réalité un amas de code de glue »
La vraie victoire de React, c’est qu’il n’est plus nécessaire de manipuler directement le DOM, et qu’il permet une gestion d’état réactive. Ces deux points ont fortement amélioré la productivité des développeurs
Ancien lien de tutoriel, version archivée
Aujourd’hui, ce qui m’intéresse davantage, c’est la façon dont les LLM comprennent le code. Une syntaxe déclarative comme JSX est favorable aux LLM
Mais depuis
useEffect, React me semble au contraire avoir perdu en expressivité et en explicitationOn comprend bien pourquoi React est devenu populaire
Le code React est en grande partie composé de JS pur et de HTML, et l’essentiel tient à
useState. C’est intuitif et compréhensible même sans documentationBackbone dépendait de sélecteurs de chaînes comme
.space-y-2, ce qui rendait la maintenance infernale. Il suffisait de changer un nom de classe pour casser la moitié de l’applicationReact a résolu ce problème de manière structurelle
Le code Backbone rend clair « ce qui se passe et à quel moment », alors qu’avec React il faut comprendre le fonctionnement interne
Moi aussi, pour comprendre le moment où React exécute certaines choses, j’ai dû relire plusieurs fois le guide de Dan Abramov sur
useEffectet le blog de Mark EriksonLe code Backbone, même 10 ans plus tard, je le comprenais immédiatement
Il y a 6 ans, notre équipe est passée de Backbone à Angular
Backbone était intuitif et sans magie, donc bien adapté aux juniors, mais au final TypeScript et Angular étaient plus structurés
Aujourd’hui nous utilisons NG20 et nous en sommes satisfaits. Si un jour les navigateurs fournissent plus de fonctionnalités nativement, il est possible que nous revenions à une approche plus simple
Nous programmons toujours au-dessus d’abstractions
Ce qui compte, c’est de savoir si cette abstraction apporte un gain de productivité proportionné à la complexité, et si elle est fiable
Même dans le pire des cas, il faut qu’elle reste déboguable
Les champs de saisie de React gèrent l’annulation (Undo) plus naturellement que Backbone
Backbone annule caractère par caractère, alors que React annule par mot