Avantages et inconvénients de la réaction de Facebook par rapport aux composants Web (polymère)

Quels sont les principaux avantages de React sur Facebook par rapport aux spécifications à venir des composants Web et inversement (ou peut-être une comparaison plus poussée d'une pomme à l'autre serait-elle à la bibliothèque Polymer de Google )?

Selon cette conférence JSConf EU et la page d'accueil de React, les principaux avantages de React sont les suivants:

• Découplage et cohésion accrue à l'aide d'un modèle de composant
• Abstraction, composition et expressivité
• Événements virtuels DOM et synthétiques (ce qui signifie fondamentalement qu'ils ont complètement ré-implémenté le DOM et son système d'événements)
  • Active les éléments d'événements HTML5 modernes sur IE 8
  • Rendu côté serveur
  • Testabilité
  • Liaisons à SVG, VML et <canvas>

Presque tout ce qui est mentionné est intégré nativement dans les navigateurs via des composants Web, à l'exception de ce concept de DOM virtuel (évidemment). Je peux voir comment le DOM virtuel et les événements synthétiques peuvent aujourd'hui être bénéfiques pour prendre en charge les anciens navigateurs, mais ne pas jeter une énorme quantité de code de navigateur natif un peu comme se tirer une balle dans le pied à long terme? En ce qui concerne les navigateurs modernes, n’est-ce pas beaucoup de frais généraux inutiles / de réinvention de la roue?

Voici quelques choses que je pense React est manquant que les composants Web se chargeront de vous. Corrige moi si je me trompe.

• Prise en charge du navigateur natif (lire "garanti pour être plus rapide")
• Écrire un script dans un langage de script, écrire des styles dans un langage de style, écrire du balisage dans un langage de balisage.
• Encapsulation de style avec Shadow DOM
  • React a plutôt ceci , ce qui nécessite l'écriture de CSS en JavaScript. Pas beau.
• Reliure à double sens

Mise à jour:  cette réponse semble être assez populaire , donc j'ai pris un certain temps pour nettoyer un peu, ajouter un peu de nouvelles informations et de clarifier quelques petites choses que je pensais ne suffisait pas claire. Veuillez commenter si vous pensez que quelque chose d'autre nécessite des éclaircissements ou des mises à jour.

La plupart de vos préoccupations sont vraiment une question d'opinion et de préférence personnelle, mais je vais essayer de répondre aussi objectivement que possible:

Natif vs compilé

Écrivez JavaScript en JavaScript vanille, écrivez CSS en CSS, écrivez HTML en HTML.

À l'époque, il y avait de vives discussions pour savoir s'il fallait écrire  manuellement Assembly natif ou utiliser un langage de niveau supérieur tel que C pour que le compilateur génère le code Assembly à votre place. Même avant cela, les gens refusaient de faire confiance aux assembleurs et préféraient écrire le code machine natif à la main ( et je ne plaisante pas ).

Pendant ce temps, aujourd'hui , il y a beaucoup de gens qui écrivent HTML dans Haml ou Jade , CSS Sass ou moins et JavaScript CoffeeScript ou tapuscrit . C'est là. Ça marche. Certaines personnes préfèrent, d'autres non.

Le point est qu'il n'y a rien de fondamentalement mauvais dans pas du code JavaScript en JavaScript vanille, CSS et HTML CSS en HTML. C'est vraiment une question de préférence.

DSL internes et externes

 À la place, l’encapsulation de styles à l’aide de Shadow DOM React nécessite l’écriture de CSS en JavaScript. Pas beau.

Joli ou pas, il est certainement expressif. JavaScript est un langage très puissant, beaucoup plus puissant que CSS (même avec n’importe quel préprocesseur CSS). Cela dépend en quelque sorte de si vous préférez les DSL internes ou externes pour ce genre de choses. Encore une fois, une question de préférence.

(Remarque: je parlais des styles en ligne dans React auxquels il était fait référence dans la question initiale.)

Types de DSL - explication

Mise à jour: En lisant ma réponse quelque temps après l'avoir écrite, je pense que je dois expliquer ce que je veux dire ici. DSL est un langage spécifique à un domaine. Il peut être interne (en utilisant la syntaxe du langage hôte telle que JavaScript - comme par exemple React sans JSX, ou les styles en ligne de React mentionnés ci-dessus), ou externe (en utilisant une syntaxe différente. que le langage hôte - comme dans cet exemple, serait d'inclure CSS (un DSL externe) dans JavaScript).

Cela peut prêter à confusion parce que certaines publications utilisent des termes différents des mots "interne" et "externe" pour décrire ce type de DSL. Parfois, "incorporé" est utilisé au lieu de "interne" mais le mot "incorporé" peut signifier différentes choses - par exemple, Lua est décrit comme "Lua: un langage extensible incorporé", où imbriqué n'a rien à voir avec les DSL incorporés (internes) quel sens c'est tout le contraire - un DSL externe) mais cela signifie qu'il est incorporé dans le même sens que, par exemple, SQLite est une base de données incorporée. Il y a même eLua où "e" signifie "incorporé" dans un troisième sens - qu'il est destiné aux systèmes embarqués! C'est pourquoi je n'aime pas utiliser le terme «DSL intégré», car des choses comme eLua peuvent être des «DSL» qui sont «intégrés» de deux manières différentes sans être du tout un «DSL intégré»!

Pour aggraver les choses, certains projets introduisent encore plus de confusion dans la composition. Par exemple. Les modèles Flatiron sont décrits comme "sans DSL", alors qu’il s’agit en fait d’un exemple parfait de DSL interne dont la syntaxe est la suivante:map.where('href').is('/').insert('newurl');

Cela dit, j’ai écrit que "JavaScript est un langage très puissant, bien plus puissant que le CSS (même avec l’un des préprocesseurs CSS). Cela dépend de la préférence que vous accordez aux DSL internes ou externes pour ce genre de choses. une question de préférence. " Je parlais de ces deux scénarios:

Un:

/** @jsx React.DOM */
var colored = {
  color: myColor
};
React.renderComponent(<div style={colored}>Hello World!</div>, mountNode);

Deux:

// SASS:
.colored {
  color: $my-color;
}
// HTML:
<div class="colored">Hello World!</div>

Le premier exemple utilise ce qui a été décrit dans la question comme suit: "écriture CSS en JavaScript. Pas joli." Le deuxième exemple utilise Sass. Bien que je convienne que l’utilisation de JavaScript pour écrire des feuilles de style CSS n’est peut-être pas jolie (pour certaines définitions de "jolie"), mais il ya un avantage à le faire.

Je peux avoir des variables et des fonctions dans Sass, mais sont-elles étendues lexicalement ou dynamiquement? Sont-ils typés statiquement ou dynamiquement? Fortement ou faiblement? Qu'en est-il des types numériques? Type de coersion? Quelles valeurs sont la vérité et quelles sont la fausseté? Puis-je avoir des fonctions d'ordre supérieur? Récursion? Appels de queue? Fermetures lexicales? Sont-ils évalués en ordre normal ou en ordre applicatif? Y a-t-il une évaluation paresseuse ou enthousiaste? Les arguments des fonctions sont-ils passés par valeur ou par référence? Sont-ils mutables? Immuable? Persistant? Qu'en est-il des objets? Des classes? Des prototypes? Héritage?

Ce ne sont pas des questions triviales et pourtant je dois connaître leurs réponses si je veux comprendre le code Sass ou Less. Je connais déjà ces réponses pour JavaScript, cela signifie donc que je comprends déjà tous les DSL internes (comme les styles inline dans React) à ces mêmes niveaux. Par conséquent, si j'utilise React, je ne dois connaître qu'un seul ensemble de réponses à ceux-ci (et de nombreuses autres similaires). ) questions, tandis que quand je utilise par exemple. Sass et Handlebars, je dois alors connaître trois ensembles de ces réponses et comprendre leurs implications.

Cela ne veut pas dire qu'une façon ou l'autre est toujours meilleure, mais chaque fois que vous introduisez une autre langue dans le mix, vous payez un prix qui peut ne pas sembler aussi évident à première vue, et ce prix est une complexité.

J'espère avoir clarifié ce que je voulais dire à l'origine.

Liaison de données

Reliure à double sens

C'est un sujet vraiment intéressant et en fait aussi une question de préférence. Deux voies n'est pas toujours préférable à un sens. C'est une question de comment voulez-vous modéliser l'état mutable dans votre application. J'ai toujours considéré les liaisons bidirectionnelles comme une idée quelque peu contraire aux principes de la programmation fonctionnelle, mais la programmation fonctionnelle n'est pas le seul paradigme qui fonctionne. Certaines personnes préfèrent ce type de comportement et les deux approches semblent bien fonctionner dans la pratique. Si vous êtes intéressé par les détails des décisions de conception liées à la modélisation de l'état dans React, regardez la présentation de Pete Hunt (liée à la question) et celle de Tom Occhino et Jordan Walke  qui l'expliquent très bien dans mon avis.

Mise à jour: voir aussi un autre discours de Pete Hunt: Soyez prévisible, pas correct: programmation DOM fonctionnelle .

Mise à jour 2: Il convient de noter que de nombreux développeurs se disputent contre le flux de données bidirectionnel ou la liaison bidirectionnelle, certains l'appellent même un anti-modèle. Prenons, par exemple, l’ architecture d’application Flux qui évite explicitement le modèle MVC (qui s’est avéré difficile à faire évoluer pour de grandes applications Facebook et Instagram) au profit d’un flux de données strictement unidirectionnel (voir Piste Hacker: Repenser le développement d’applications Web à Facebook sur Facebook) . Tom Occhino, Jing Chen et Pete Hunt pour une bonne introduction). En outre, beaucoup de critiques contre AngularJS (L'infrastructure Web la plus répandue, basée sur le modèle MVC, connue pour sa liaison de données bidirectionnelle) inclut des arguments contre ce flux de données bidirectionnel. Voir:

• Des choses que j'aimerais avoir sur Angular.js de Ruoyu Sun
• Vous avez ruiné HTML par Danny Tuppeny
• AngularJS: The Bad Parts de Lars Eidnes
• Quel est le problème avec Angular.js par Jeff Whelpley ("La liaison de données bidirectionnelle est un anti-motif.")
• Pourquoi vous ne devriez pas utiliser Angular.js de Egor Koshelko ("La liaison de données bidirectionnelle n’est pas comment gérer les événements en principe.")

Mise à jour 3: Un autre article intéressant qui explique avec précision certains des problèmes évoqués ci-dessus est Déconstruire le flux de ReactJS - Ne pas utiliser MVC avec ReactJS par Mikael Brassman, auteur de RefluxJS (une bibliothèque simple pour une architecture d’application de flux de données unidirectionnelle inspirée par Flux).

Mise à jour 4: Ember.js s'éloigne actuellement de la liaison de données bidirectionnelle et, dans les futures versions, il sera unidirectionnel par défaut. Voir: L'avenir de Ember parler par Stefan Penner du Symposium Embergarten à Toronto le 15 Novembre 2014.

Mise à jour 5: Voir aussi: RFC The Road to Ember 2.0 - discussion intéressante dans la demande d'attraction de Tom Dale :

"Lorsque nous avons conçu la couche de gabarit d'origine, nous avons pensé qu'il n'était pas très dommageable de rendre toutes les liaisons de données bidirectionnelles: si vous ne définissez pas de liaison bidirectionnelle, c'est une liaison unidirectionnelle de facto!

Nous avons depuis réalisé (avec l'aide de nos amis de React), que les composants veulent pouvoir transmettre des données à leurs enfants sans être obligés de rester vigilants face à des mutations égarées.

De plus, la communication entre les composants est souvent exprimée de la manière la plus naturelle sous forme d'événements ou de rappels . C'est possible dans Ember, mais la prédominance des liaisons de données bidirectionnelles amène souvent les gens à utiliser des liaisons bidirectionnelles comme canal de communication . Les développeurs Ember expérimentés ne commettent pas (en général) cette erreur, mais c’est une erreur facile à commettre. " [Soulignement ajouté]

Native vs. VM

Prise en charge du navigateur natif (lire "garanti pour être plus rapide")

Maintenant enfin quelque chose qui n’est pas une question d’opinion.

En fait, ici, c’est exactement l’inverse. Bien sûr, le code "natif" peut être écrit en C ++, mais selon vous, en quoi les moteurs JavaScript sont-ils écrits?

En fait, les moteurs JavaScript sont vraiment étonnants dans les optimisations qu’ils utilisent aujourd’hui - et non plus seulement en V8, mais SpiderMonkey et même Chakra brillent de nos jours. Et gardez à l'esprit qu'avec les compilateurs JIT, le code est non seulement aussi natif que possible, mais il existe également des opportunités d'optimisation de l'exécution qui sont tout simplement impossibles à exploiter dans tout code compilé de manière statique.

Quand les gens pensent que JavaScript est lent, ils veulent généralement dire que JavaScript accède au DOM. Le DOM est lent. Il est natif, écrit en C ++ et pourtant, il est très lent à cause de la complexité qu’il doit implémenter.

Ouvrez votre console et écrivez:

console.dir(document.createElement('div'));

et voyez combien de propriétés un divélément vide qui n'est même pas attaché au DOM doit implémenter. Ce ne sont que les  propriétés de premier niveau qui sont des "propriétés propres" c'est-à-dire. non hérité de la chaîne de prototypes:

en ligne de la musique en ligne, en mémoire, en mémoire, en charge, en charge, en charge, en charge oncontextmenu, onclose, onclick, onchange, oncanplaythrough, oncanplay, oncancel, onblur, onabort, vérification orthographique, isContentEditable, contentEditable, outerText, innerText, accessKey, caché, webkitdropzone, draggable, dialogable,firstElementChild, enfants, nextElementSibling, précédent, dernier article, système, onwebkitfullscreen, est conçu pour le stockage des documents, contenant des disques, des disques, des disques, des disques et des cartouches clientHeight, clientWidth, clientTop, clientLeft, offsetParent, offsetHeight, offsetWidth, offsetTop, offsetLeft, localName, prefix, namespaceURI, id, style, attributs, tagName, parentElement, textContent, baseURI, propriétaireDocument, nextSibling, nextSibling, previousSibling, précédent parentNode, nodeType, nodeValue, nodeNameoncopy, onbeforepaste, onbeforecut, onbeforecopy, webkitShadowRoot, ensemble de données, classList, className, outerHTML, innerHTML, scrollHight, scrollHidth, scrollTop, scrollLeft, clientHeight, clientWop, clientTop, clientTop, client namespaceURI, id, style, attributs, tagName, parentElement, textContent, baseURI, ownerDocument, nextSibling, previousSibling, lastChild, firstChild, childNodes, parentNode, nodeType, nodeValue, nodeNameoncopy, onbeforepaste, onbeforecut, onbeforecopy, webkitShadowRoot, ensemble de données, classList, className, outerHTML, innerHTML, scrollHight, scrollHidth, scrollTop, scrollLeft, clientHeight, clientWop, clientTop, clientTop, client namespaceURI, id, style, attributs, tagName, parentElement, textContent, baseURI, ownerDocument, nextSibling, previousSibling, lastChild, firstChild, childNodes, parentNode, nodeType, nodeValue, nodeNameparentElement, textContent, baseURI, ownerDocument, nextSibling, previousSibling, lastChild, firstChild, childNodes, parentNode, nodeType, nodeValue, nodeNameparentElement, textContent, baseURI, ownerDocument, nextSibling, previousSibling, lastChild, firstChild, childNodes, parentNode, nodeType, nodeValue, nodeName

Nombre d’entre eux sont en fait des objets imbriqués - pour voir les propriétés de second niveau (propres) d’un natif vide divdans votre navigateur, voyez ce violon .

Je veux dire sérieusement, la propriété onvolumechange sur chaque nœud div? Est-ce une erreur? Nope, il s’agit simplement d’une ancienne version du modèle d’événement traditionnel DOM de niveau 0 héritée de l’un des gestionnaires d’événements "qui doit être prise en charge par tous les éléments HTML , en tant qu’attributs de contenu et attributs IDL" dans la section 6.1.6.2 de la spécification HTML. par W3C - aucun moyen de le contourner.

En attendant, ce sont les propriétés de premier niveau d'un faux DOM divdans React:

props, _owner, _lifeCycleState, _pendingProps, _pendingCallbacks, _pendingOwner

C'est une différence, n'est-ce pas? En fait, il s’agit de l’objet entier sérialisé en JSON ( LIVE DEMO ), car il est possible de le  sérialiser en JSON car il ne contient aucune référence circulaire - ce qui est impensable dans le monde des DOM natifs ( où il ne ferait qu’une exception ):

{
  "props": {},
  "_owner": null,
  "_lifeCycleState": "UNMOUNTED",
  "_pendingProps": null,
  "_pendingCallbacks": null,
  "_pendingOwner": null
}

C’est à peu près la raison principale pour laquelle React peut être plus rapide que le navigateur natif DOM - car il n’a pas à implémenter ce désordre .

Regardez cette présentation de Steven Luscher pour voir ce qui est plus rapide: un DOM natif écrit en C ++ ou un faux DOM entièrement écrit en JavaScript. C'est une présentation très juste et amusante.

Mise à jour: Ember.js, dans les versions futures, utilisera un DOM virtuel fortement inspiré de React pour améliorer les performances. Voir: L'avenir de Ember parler par Stefan Penner du Symposium Embergarten à Toronto le 15 Novembre 2014.

Pour résumer: les fonctionnalités des composants Web telles que les modèles, la liaison de données ou les éléments personnalisés présenteront de nombreux avantages par rapport à React, mais tant que le modèle d'objet de document ne sera pas considérablement simplifié, les performances n'en feront pas partie.

Mise à jour

Deux mois après avoir posté ces réponses, certaines nouvelles étaient pertinentes ici. Comme je viens de l'écrire sur Twitter , la dernière version de l' éditeur de texte Atom écrit par GitHub en JavaScript utilise React de Facebook pour obtenir de meilleures performances, même si selon Wikipedia "Atom est basé sur Chromium et écrit en C ++", de sorte qu'il contrôle entièrement l'implémentation native du DOM C ++ (voir The Nucleus of Atom ) et est assuré de prendre en charge les composants Web, car il est livré avec son propre navigateur Web. Il s’agit d’un exemple très récent de projet réel qui aurait pu utiliser tout autre type d’optimisation généralement indisponible pour les applications Web. Pourtant, il a choisi d’utiliser React, lui-même écrit en JavaScript, pour obtenir les meilleures performances, même si Atom Pour commencer, React n’a pas été conçu. Ce n’était donc pas un changement anodin.

Mise à jour 2

Todd Parker a fait une comparaison intéressante avec WebPagetest pour comparer les performances des exemples TodoMVC écrits en Angular, Backbone, Ember, Polymer, CanJS, YUI, Knockout, React et Shoestring. C'est la comparaison la plus objective que j'ai vue jusqu'à présent. Ce qui est important ici, c'est que tous les exemples respectifs ont été écrits par des experts dans tous ces cadres. Ils sont tous disponibles sur GitHub et peuvent être améliorés par quiconque pense que certains codes pourraient être optimisés pour être exécutés plus rapidement.

Mise à jour 3

Dans les versions futures, Ember.js inclura un certain nombre de fonctionnalités de React dont il est question ici (y compris un lien virtuel DOM et une liaison de données unidirectionnelle, par exemple), ce qui signifie que les idées issues de React sont déjà en train de migrer vers d'autres frameworks. Voir: RFC The Road to Ember 2.0 - discussion intéressante dans la demande d'attraction de Tom Dale (Date de début: 2014-12-03): "Dans Ember 2.0, nous adopterons un modèle de" DOM ​​virtuel "et de flux de données qui englobe le meilleures idées de React et simplifie la communication entre les composants. "

De plus, Angular.js 2.0 implémente de nombreux concepts présentés ici.

Mise à jour 4

Je dois élaborer sur quelques points pour répondre à ce commentaire d'Igwe Kalu:

"il n’est pas judicieux de comparer React (JSX ou la sortie de la compilation) au code JavaScript pur, lorsque React se réduit finalement à un code JavaScript pur. [...] Quelle que soit la stratégie utilisée par React pour l’insertion DOM, elle peut être appliquée sans utiliser React. Cela dit, n’ajoute aucun avantage particulier à l’examen de la fonctionnalité en question, à part sa commodité. " (commentaire complet ici )

Au cas où ce ne serait pas assez clair, dans une partie de ma réponse, je comparais les performances d'exploitation directement sur le DOM natif (implémenté en tant qu'objets hôte dans le navigateur) par rapport au faux DOM / virtuel de React (implémenté en JavaScript). Le point que je tentais de faire est que le DOM virtuel mis en œuvre en JavaScript peut surperformer le réel DOM implémenté en C ++ et pas que React peut surpasser JavaScript ( ce qui serait évidemment pas beaucoup de sens car il est écrit en JavaScript). Mon argument était que le code C ++ "natif" n'est pas toujours plus rapide que le code JavaScript "non natif". L’utilisation de React pour illustrer ce point n’est qu’un exemple.

Mais ce commentaire a touché une question intéressante. En un sens, il est vrai que vous n’avez besoin d’aucun framework (React, Angular ou jQuery) pour quelque raison que ce soit (comme les performances, la portabilité, les fonctionnalités) car vous pouvez toujours recréer ce que le framework fait pour vous et réinventer la roue - si vous pouvez justifier le coût, c'est-à-dire.

Mais - comme Dave Smith a mis bien dans Comment rater le point lorsque l'on compare les performances du framework web : « Lorsque l'on compare deux frameworks web, la question ne peut mon application être rapide avec le cadre X. La question est sera mon application est rapide avec cadre X."

Dans ma réponse de 2011 à: Quelles sont certaines des raisons techniques empiriques de ne pas utiliser jQuery? J'explique un problème similaire: il n'est pas impossible d'écrire du code de manipulation DOM portable sans une bibliothèque comme jQuery, mais les utilisateurs le font rarement.

Lorsqu'ils utilisent des langages de programmation, des bibliothèques ou des frameworks, les utilisateurs ont tendance à utiliser les méthodes les plus commodes ou les plus idiomatiques, et non les méthodes parfaites mais peu pratiques. La valeur réelle de bons frameworks facilite ce qui serait autrement difficile à faire - et le secret est de rendre les bonnes choses commodes. Le résultat est toujours doté de la même puissance que la forme la plus simple du lambda calcul ou la machine de Turing la plus primitive, mais l’expressivité relative de certains concepts signifie que ces mêmes concepts ont tendance à s’exprimer plus facilement ou plus du tout, et que les bonnes solutions ne sont pas seulement possibles, elles sont également largement mises en œuvre.

Mise à jour 5

Réagir + Performance =? L'article de Paul Lewis de juillet 2015 montre un exemple où React est plus lent que le code JavaScript à la vanille. Il est écrit à la main pour une liste infinie d'images Flickr, ce qui est particulièrement important pour les mobiles. Cet exemple montre que tout le monde devrait toujours tester les performances pour un cas d'utilisation spécifique et pour des plates-formes et des périphériques cibles spécifiques.

Merci à Kevin Lozandier de l' avoir porté à mon attention .

Le polymère est génial. Réagir est génial. Ce n'est pas la même chose.

Polymer est une bibliothèque permettant de créer des composants Web rétrocompatibles.

React est le V dans MVC. C'est la vue, et rien d'autre. Pas par lui-même au moins.

React n'est pas un cadre.

React + Flux + Node + (Gulp ou Grunt) est plus comparable à un framework, mais 3 de ces choses ne font pas partie de Réaction.

Il existe de nombreuses technologies, modèles et styles architecturaux que les développeurs suivent, mais ce n’est pas un framework.

C'est triste que personne n'ait pris le temps de dire la chose la plus simple possible, qu'il ne faille pas les comparer. Ils se chevauchent, mais ils sont plus différents que les mêmes.

Ils vous permettent tous deux de définir des composants Web, mais de différentes manières. Au-delà de ce sont des outils très très différents.

Les gars de React ont une assez bonne explication sur la comparaison entre React et Web Components:

Essayer de comparer et de contraster React avec WebComponents aboutit inévitablement à des conclusions spécieuses, car les deux bibliothèques sont conçues pour résoudre des problèmes différents. Les composants Web offrent une forte encapsulation pour les composants réutilisables, tandis que React fournit une bibliothèque déclarative qui maintient le DOM en synchronisation avec vos données. Les deux objectifs sont complémentaires. les ingénieurs peuvent combiner les technologies. En tant que développeur, vous êtes libre d’utiliser React dans vos composants Web, d’utiliser WebComponents dans React, ou les deux.

Une autre réponse à un point spécifiquement:

Écrivez JavaScript en JavaScript vanille, écrivez CSS en CSS, écrivez HTML en HTML.

Rien ne vous empêche d'écrire du code JavaScript dans, par exemple, CoffeeScript, TypeScript, ClojureScript ou quoi que ce soit d'autre. C'est purement une question de préférence.

HTML est le meilleur DSL pour les documents HTML statiques . Mais cela ne fournit rien pour le HTML dynamique. Et dans le navigateur, le meilleur langage pour rendre HTML dynamique est Javascript, pas du HTML pur avec une manipulation DOM ad hoc ou un langage de modèle tel que Handlebars, qui ne sont même pas des demi-langues.

Pour CSS, si votre CSS est statique, vous l'écrivez comme d'habitude. S'il doit être dynamique en fonction de certaines valeurs d'exécution, il en va de même pour HTML: Javascript est le meilleur moyen de le rendre dynamique.

Je n'ai pas utilisé de composants Web, mais il semble qu'ils nécessitent l'ajout d'une logique de mutation codée manuellement aux gestionnaires d'événements.

extrait de Polymer exemple:

 <script>
   Polymer({
     counterChanged: function() {
       this.$.counterVal.classList.add('highlight');
     },
 ...

Le but de React est de réduire la complexité en éliminant la logique de mutation. Au lieu de cela, vous régénérez naïvement un DOM virtuel et laissez l’algorithme diff de React déterminer ce qui doit changer dans le DOM réel.

À mon avis, le principal inconvénient de React est qu’il n’est pas basé sur les normes Web. React est un outil très puissant en ce moment, mais comme il contourne une grande partie de ce que le navigateur fournit chaque fois que possible, les décisions qui semblaient logiques maintenant n'auront probablement plus aucun sens dans les années à venir, car les fonctionnalités intégrées du navigateur continuent à améliorer. J'aimerais donc parler de cela et de son impact sur différents aspects des applications Web.

Performance

Les gens aiment bien affirmer que l'avantage de React est qu'il réinvente complètement le modèle d'événement et le modèle DOM complet, et que le modèle DOM standard existant est lourd et coûteux, et ce qui ne l'est pas, mais au final, je n'ai pas trouvé les performances de Réagis pour être meilleur que ce que je peux tirer d’une application bien écrite de Backbone ou de Polymer. En fait, dans la plupart de mes expériences professionnelles, les performances de React ont été un peu moins bonnes. Cela ne veut pas dire que React est lent ... Ce n'est tout simplement pas le choix de performance à la pointe de la technologie que nous pensions tous être avant de mettre la main dessus.

Dans la réponse de rsp, il souligne que le modèle DOM de React pour une division est beaucoup plus léger que la division DOM native, ce qui est certainement vrai. Cependant, pour que React soit utile, cette division 'virtuelle' doit finir par devenir une véritable division à un moment donné. Donc, dans ma vision du monde, il ne s’agit pas d’un div React ou d’un div autochtone. C'est un div React + un div natif contre juste un div natif. La surcharge de DOM dans la version de React n'est pas anodine, et si les normes abandonnent certains de ces attributs inutiles et permettent aux noeuds DOM natifs d'être beaucoup plus légers, soudain, cette surcharge va sembler très coûteuse.

Dans l'un de mes lieux de travail précédents, nous avions des applications dans Polymer et d'autres dans React. Une des premières applications Polymer a finalement été réécrite dans React car c’était ce que la société avait de standard, et sur la base des mesures que j’ai prises, la version React de cette même application a utilisé environ 30% de mémoire supplémentaire par rapport à la version Polymer. et bien que la différence fût marginale, la version Polymer fut également rendue en moins de temps. Une chose à considérer ici est que nous parlons d'applications écrites par des personnes, et que les personnes ne sont pas parfaites. Il est donc possible que l'implémentation React de cette application ne tire pas parti de tout ce dont React est capable. Mais je pense qu’au moins une partie de cela a à voir avec les frais généraux que React encourt en ayant sa propre version du DOM.

React réinvente l'intégralité du DOM à l'aide de son propre modèle, puis utilise celui-ci pour optimiser ses performances. Une vue est rendue dans un DOM virtuel et projetée dans le vrai DOM. Quand il y a un changement et que la vue doit être mise à jour, la vue est à nouveau fraîchement restituée dans un DOM virtuel, et cet arbre est comparé à l'arbre précédent pour déterminer quels nœuds doivent être modifiés dans le vrai DOM pour refléter ce changement. dans la vue. Bien qu'il s'agisse d'une approche très intelligente pour réaliser des mises à jour DOM efficaces, il est fastidieux de maintenir toutes ces arborescences DOM virtuelles et de les différencier pour déterminer ce qu'il faut changer dans le DOM réel. À l’heure actuelle, cette surcharge est largement compensée par les avantages en termes de performances, mais à mesure que le DOM natif s’améliorera au fil du temps, l’échelle évoluera dans la direction opposée. Je m'inquiète de la façon dont les applications React pourraient vieillir, et si dans 3 ans, ils seront beaucoup plus lents que les choses qui traitent plus directement avec les DOM. Cette approche virtuelle du DOM est un peu un marteau-pilon, et d’autres bibliothèques comme Polymer ont été capables de mettre en œuvre des approches très efficaces pour traiter le DOM de manière beaucoup plus subtile.

Mise à jour pour améliorer les performances: l' une des bibliothèques que j'ai rencontrées il y a quelque temps fait ce que je pense être un meilleur travail de gestion des mises à jour du DOM. C'est la bibliothèque de Google Incremental Dom, et je pense que le fait de fonctionner avec le dom sur place et de ne pas créer de "copie virtuelle" est une approche beaucoup plus nette, avec beaucoup moins de surcharge de mémoire. Voir plus ici: http://google.github.io/incremental-dom/#about

Composants déclaratifs vs impératifs

Lorsque vous parlez de la composition de votre application, vous entendez toujours tous les avantages de la déclaration de vos composants. Dans la vision du monde de React, tout est beau et déclaratif. Vous écrivez du code JavaScript qui renvoie le balisage et React le colle pour vous. Et c'est très bien si vous avez affaire à une toute nouvelle application qui utilise uniquement React et rien d'autre. Vous pouvez écrire un composant et tant que vous êtes à l'intérieur d'un morceau du DOM appartenant à React, il suffit simplement de placer cette balise sur la page pour utiliser votre composant.

Mais dès que vous prenez ces composants et les utilisez en dehors de React, les choses se compliquent. Étant donné que la manière dont les composants React sont transformés en balises est totalement différente de celle fournie par les normes Web, React ne sait comment vous donner un moyen déclaratif de consommer ces composants. Si je veux placer des composants React dans une vue Backbone existante utilisant des modèles de guidon, vous devez restituer une div factice dans votre modèle avec une classe ou un ID que vous pouvez utiliser comme poignée, puis écrire un code JavaScript impératif pour trouver cette div factice et la monter. votre composant en elle. Vous avez une application Express.js utilisant des modèles côté serveur? Eh bien, c'est cette même chanson et danse. Une page JSP? Vous riez, mais il y a une tonne d'applications qui les utilisent encore. Sauf si vous êtes une sorte de démarrage sans code existant, vous Il va falloir écrire de la plomberie pour réutiliser vos composants React dans de nombreuses applications. Pendant ce temps, Polymer réalise des composants via la norme Web Components et, en utilisant la spécification Custom Element, Polymer est en mesure de créer des composants que le navigateur sait exactement comment utiliser. Je peux insérer un composant Polymer dans une page JSP, un modèle Express.js, une vue ASP.NET, une vue Backbone ... à l’intérieur d’un composant React. Partout où vous pouvez utiliser HTML, vous pouvez utiliser un composant Polymer. Les personnes qui travaillent à la réutilisation se tournent vers les normes Web, car les normes sont le contrat qui facilite la compatibilité des éléments. YouTube continue de créer de plus en plus de choses dans Polymer (source: Polymer réalise des composants par le biais de la norme Web Components et, à l'aide de la spécification Custom Element, Polymer est capable de créer des composants que le navigateur sait naturellement utiliser. Je peux insérer un composant Polymer dans une page JSP, un modèle Express.js, une vue ASP.NET, une vue Backbone ... à l’intérieur d’un composant React. Partout où vous pouvez utiliser HTML, vous pouvez utiliser un composant Polymer. Les personnes qui travaillent à la réutilisation se tournent vers les normes Web, car les normes sont le contrat qui facilite la compatibilité des éléments. YouTube continue de créer de plus en plus de choses dans Polymer (source: Polymer réalise des composants par le biais de la norme Web Components et, à l'aide de la spécification Custom Element, Polymer est capable de créer des composants que le navigateur sait exactement comment utiliser. Je peux insérer un composant Polymer dans une page JSP, un modèle Express.js, une vue ASP.NET, une vue Backbone ... à l’intérieur d’un composant React. Partout où vous pouvez utiliser HTML, vous pouvez utiliser un composant Polymer. Les personnes qui travaillent à la réutilisation se tournent vers les normes Web, car les normes sont le contrat qui facilite la compatibilité des éléments. YouTube continue de créer de plus en plus de choses dans Polymer (source: Je peux insérer un composant Polymer dans une page JSP, un modèle Express.js, une vue ASP.NET, une vue Backbone ... à l’intérieur d’un composant React. Partout où vous pouvez utiliser HTML, vous pouvez utiliser un composant Polymer. Les personnes qui travaillent à la réutilisation se tournent vers les normes Web, car les normes sont le contrat qui facilite la compatibilité des éléments. YouTube continue de créer de plus en plus de choses dans Polymer (source: Je peux insérer un composant Polymer dans une page JSP, un modèle Express.js, une vue ASP.NET, une vue Backbone ... à l’intérieur d’un composant React. Partout où vous pouvez utiliser HTML, vous pouvez utiliser un composant Polymer. Les personnes qui travaillent à la réutilisation se tournent vers les normes Web, car les normes sont le contrat qui facilite la compatibilité des éléments. YouTube continue de créer de plus en plus de choses dans Polymer (source:http://react-etc.net/entry/youtube-is-being-rebuilt-on-web-components-and-polymer ), et je ne peux qu'imaginer que l'aspect basé sur les normes de Polymer en est la raison. Ce lecteur YouTube situé au milieu de la page YouTube pourrait être transformé en un composant prenant une source de contenu en tant que propriété, et soudainement, toute personne souhaitant intégrer le lecteur YouTube à sa page peut utiliser littéralement le même code de lecteur utilisé par YouTube. , et ils peuvent le faire simplement en collant une étiquette dans leur page.

Sommaire

Je peux voir qu'il y a des aspects intéressants de React en ce moment. Si tout ce que vous utilisez est React, vous pouvez créer des widgets et des composants et les réutiliser de manière déclarative. Mais je pense que React aurait été beaucoup mieux s'il avait utilisé certaines des normes des composants Web pour atteindre ses objectifs, au lieu de créer un navigateur dans un navigateur et de mettre en place un mécanisme complexe pour tout synchroniser.