React or not React ? - commentaires

React or not React ?

Bonjour Hervé,

merci pour le retour (et merci aux copains d'OpenWeb pour les relances sur Twitter :P).

Effectivement, React (et d'autres) sont au cœur de la tempête "Javascript Fatigue" qui fait rage depuis quelques mois. Le problème n'est, à mon avis, pas tant la mutliplication des dépendance (encore que, mais c'est un autre problème je dirai), que la question de la pérénnité de ces frameworks. Dans les langages plus établis, on trouve des solution robustes qui font, sinon l'unanimité, du moins assez fortement consensus dans les communautés de développeurs.

Pour JavaScript, le problème est différents : les navigateurs se livrent une guerre acharnée pour obtenir des moteurs d'éxecution de plus en plus rapides ; le langage est reparti à évoluer dans le bon sens (ES6) ; les nouvelles fonctionnalités navigateurs offrent un plein potentiel. Dans l'effervescence des briques bas-niveau de la conception de nos webapps, il devient compliqué de mettre au point de façon durable un framework au-dessus de fondations aussi mouvantes. On se retrouve donc avec chaque semaine une tripotée de nouveaux outils tous plus malins, plus puissants, plus efficaces que ceux présents encore la veille (et qui faisaient déjà le café et revenir l'être aimé).

Bref, choisir une solution JS frontend robuste, établie, et pérenne, à l'heure actuelle, c'est utopique. Dès que le socle (l'évolution des navigateurs) se stabilisera, les choses se tasseront probablement. Mais, bonne nouvelle, ce n'est probablement pas pour tout de suite ! Il ne nous reste plus qu'à prendre notre mal en patience, ne pas se jeter sur la nouveauté à chaque nouveau projet, et essayer de tirer parti de l'expérience engrangée sur les projets précédents. Surtout, je crois qu'il faut tenir pour acquis que quoi qu'il arrive, un code ne restera jamais en prod en front sans aucune évolution pendant plus de 18 mois (sur un projet vivant, j'entends). Partant de là, travailler avec des solutions jetables dans le temps devient plus acceptable :).

n.b : je recommande à toutes fins utiles la merveilleuse conférence de l'ami Thibault Jouannic sur la veille techno pour les vieux croutons qui illustre finalement bien qu'il n'est pas nécessaire de coller à la nouveauté pour faire de la qualité.

React or not React ?

Merci pour cet article (que je viens lire suite à la relance sur Twitter ;)) qui présente clairement les concepts intéressants de React.

En revanche j'ai l'impression que l'inconvénient principal de React dans la pratique c'est, comme le dit cet article intitulé "Javascript Fatigue", la multiplication des dépendances, non ?

React or not React ?

Vraiment très intéressant et très agréable à la lecture. Merci !...

React or not React ?

Bonjour, merci pour votre article, très intéressant !
Juste une petite remarque : les "notes de bas de page" très nombreuses compliquent grandement la lecture... Et ce contenu n'a pas trop nécessité à être sous cette forme ? Ajouter des tooltips ou simplement des parenthèses ?

React or not React ?

Merci Matthias, super article !
Pour moi la force de React n'est pas tant dans son DOM virtuel (d'autres librairies le font très bien, tu les a nommé : RiotJS, CycleJS, etc.), mais plutôt dans son approche axée autour d'un flux de donnée unidirectionnel (Intéractions -> Actions -> Données -> Rendu) qui fait qu'à tout moment le rendu de la vue est prédictible humainement pour peu qu'on fasse de sa vue une fonction pure (avec bonus de performance si on utilise des données immuables).
En bref : le DOM virtuel fait le café pour les perfs, mais c'est l'architecture autour qui créer une valeur ajoutée en permettant à l'appli d'évoluer sans explosion de complexité, et tout en restant prédictible (donc maintenable).
Je te rejoins sur le fait qu'on a pas forcément besoin de React pour mettre en place une architecture « reactive-like » ou complètement réactive, mais en attendant que le concept se généralise j'apprécie la robustesse de React.
Le grand retour de la programmation fonctionnelle est-il pour bientôt ? ;)

React or not React ?

Boris : pour React Native, on me faisait remarquer à l'écriture de cet article (merci David :)) que si la promesse est belle, il n'en reste pas moins que la courbe d'apprentissage n'est pas lissée : les paradigmes et les patterns (d'interface notamment) sur Mobile sont quand même très différents du Web, et même si la couche de base (React) est la même, l'usage risque d'êetre assez différent malgré tout. Donc j'attends de voir si le futur de React Native est aussi merveilleux que ce qu'on nous vend :P.

D'ailleurs, le support de Facebook est à la fois ce qui m'intéresse et ce qui m'inquiète : la puissane politique liée à un écosystème monoculturel est nocif, particulièrement sur le Web (mais je sais que tu sais :P). L'article de PandaStrike sur le sujet est intéressant.

Et pour les WebComponents, je vais totalement dans le même sens. Peut-être que React ne sera que le tremplin vers l'adoption massive d'un standard. Je l'espère en tous cas :).

MoOx : Je faisais référence aux libs FRP notamment et aux outils qui commencent à les embarquer (Cycle.js, par exemple). Les solutions matûres, au sens large du dév, existent depuis longtemps dans d'autres langages et sur d'autres plateformes. Je pense sincèrement que React ouvre la voie à adapter tous ces patterns sur le Web. J'ai juste dans l'idée que c'est loin d'être fini et que le futur des apps sur le Web va bien au-delà de React :).

React or not React ?

Il aurait été intéressant d'indiquer quels sont justement les solutions "plus matures, plus solides, plus souples [qui] se profilent déjà et méritent tout notre intérêt".

React or not React ?

Un point de vue très intéressant, merci beaucoup, ça me fait réfléchir... React a également un autre avantage, celui de répondre à l'équation économique du système avec à la fois React Native qui offre la possibilité d'une montée en compétence simultanée mobile et Web (si elle n'est pas un mythe) et le support de Facebook qui est une assurance de pérennité (relative, hein, mais pour au moins 3-4 ans) pour de nombreux éditeurs en recherche d'une solution SPA vers laquelle se tourner.

Pour ma part, j'aurais préférer travailler avec des Web Components qui répondent de manière standard à la nécessité d'avoir des composants à états. Mais bon, puisqu'il faut aller plus vite que la musique, allons-y :)

React or not React ?

Merci pour cet article complet et très intéressant