La discussion sur la sélection du framework WordPress Core JavaScript se poursuit avec la contribution des leaders de la communauté Open Source

La chaîne #core-js Slack de WordPress a organisé ce matin une réunion animée et productive dirigée par Andrew Duthie. La discussion s'est concentrée moins sur des comparaisons de framework spécifiques et plus sur le rôle qu'un framework jouera dans la construction d'interfaces alimentées par JavaScript pour WordPress. Les contributeurs ont été rejoints par des développeurs principaux et des dirigeants des communautés React et Vue, des ingénieurs Chrome et d'autres parties intéressées extérieures à la communauté WordPress.

"Ce chat se concentrera en grande partie sur l'identification des exigences dans la création de fonctionnalités de base, le chevauchement avec les auteurs de plugins et de thèmes, et les modèles pour réduire le verrouillage du framework", a déclaré Duthie. "Idéalement, il s'agit d'un niveau supérieur à celui d'un simple débat sur les mérites de frameworks spécifiques dans le vide, et doit être considéré comme une opportunité de collaboration entre les projets pour tracer la voie à suivre pour WordPress, ce qui offrira flexibilité et résilience aux futurs désabonnements."

Duthie a commencé par demander quel rôle un framework devrait jouer dans le flux de travail d'un développeur WordPress et a également demandé aux contributeurs du framework d'offrir leurs points de vue sur les recommandations d'interfaces extensibles. Cette question a donné aux participants l'occasion d'intervenir sur des sujets tels que la prise en charge des composants Web, l'interopérabilité des blocs indépendants du framework pour Gutenberg et la manière dont cela pourrait affecter l'écosystème de plugins de WordPress.

"Je suis un peu en désaccord avec l'idée que quel que soit le noyau (dans ce cas Gutenberg) utilisé pour alimenter certaines des subtilités de la construction d'une application avec état va être la norme de facto pour le développement de plugins", a déclaré Matias Ventura, ingénieur chez Gutenberg. "Le cadre réel ici, en termes généraux, sera ce que WordPress expose et les API."

Avec une approche indépendante du framework pour la construction de Gutenblocks, la bibliothèque sur laquelle le noyau décide de s'appuyer n'a pas à devenir la norme de facto pour les développeurs de plugins, mais beaucoup en dehors de l'équipe Gutenberg pensent que cela finira inévitablement de cette façon dans la pratique. Des équipes entières d'ingénieurs attendent cette décision et s'engagent à adopter le framework sur lequel WordPress parie.

"Pour donner une idée de l'impact de la décision de WP sur un framework sur les développeurs en aval, je suis développeur à l'Université de Boston et notre plan est de nous concentrer sur le framework choisi par WP, même si Gutenberg a une API complètement agnostique", a déclaré Adam Pieniazek. . "Nous sommes principalement une boutique WP (~ 1 000 installations de sites WP alimentent la plupart / une grande partie de notre présence Web publique) et finissons par créer d'énormes personnalisations au-dessus de WP qui nécessitent souvent de plonger dans le noyau pour voir ce qui se passe réellement en arrière-plan . Personnellement, j'aime plus Vue que React, mais si WP décide de React, BU se concentrera sur le renforcement de l'expertise dans React lorsque nous aurons besoin de jeter un coup d'œil / déboguer au-delà de l'API. Cela ne signifie pas que nous n'utiliserons pas également Vue, mais ce ne sera pas notre objectif principal.

Les commentaires de Pieniazek font écho à ceux du cofondateur de Gravity Forms, Carl Hancock, qui a déclaré que son équipe était prête à adopter la bibliothèque choisie par WordPress.

"Les gens vont finir par adopter la plupart des utilisations de base malgré les arcs-en-ciel et les papillons que certains prétendent en ce qui concerne la création d'une couche d'abstraction afin que les développeurs de plugins/thèmes puissent utiliser ce qu'ils veulent", a déclaré Hancock dans le #core- js plus tôt cette semaine.

De nombreux participants extérieurs à la communauté WordPress semblaient être d'accord avec une approche indépendante du framework et aucun n'était désireux d'imposer un framework unique à tous les développeurs travaillant avec WordPress. La préoccupation restante est de savoir comment cela fonctionne pratiquement et si cela place les développeurs dans la position confuse d'utiliser un framework au-dessus d'un framework.

"Puisque Gutenberg lui-même va devenir une plate-forme pour laquelle construire, le meilleur niveau de séparation est si le framework est utilisé pour construire le noyau, mais n'est pas exposé en tant qu'API pour bloquer les constructeurs", a déclaré l'ingénieur AMP Paul Bakaus. "Cela donne le choix de remplacer la fondation sous-jacente chaque fois que nécessaire."

L'ingénieur de Gutenberg, Riad Benguella, a résumé l'approche dont l'équipe a discuté :

Je pense que ce que nous essayons de communiquer est quelque chose comme :

– WordPress Core va utiliser ce framework X en interne
– Si vous voulez l'utiliser, nous pensons que c'est bien
– Si vous voulez utiliser autre chose, vous pouvez aussi facilement que vous utiliseriez le framework choisi par le Core

Benguella a également déclaré que l'un des objectifs de Gutenberg est "de jeter les bases de la manière dont nous étendrons l'interface utilisateur de WordPress à l'avenir". Une fois qu'il sera expédié, l'équipe se tournera probablement vers d'autres parties de wp-admin et les construira de la même manière.

"Si toutes les parties de l'interface utilisateur de WP peuvent être étendues via une interface standard, qu'il s'agisse d'une simple API" data down, events up "ou d'un WC attendu, je pense que cela séparerait clairement les préoccupations de" quel cadre utiliser pour le noyau ' par rapport à 'quel cadre utiliser pour le développement d'extensions' », a déclaré le créateur de Vue.js, Evan You.

Lorsqu'on lui a demandé son avis sur le fait que React devienne un cadre principal pour WordPress, le responsable de React, Dan Abromov, a hésité à plaider en faveur de l'adoption de la bibliothèque par WordPress. Sa réponse a souligné la nécessité d'avoir une approche indépendante du cadre pour étendre Gutenberg et les futures révisions de l'interface WP.

"Je ne connais pas vraiment bien WordPress, il m'est donc difficile de dire si c'est un bon choix pour le cas d'utilisation ou non", a déclaré Abramov. "En général, nous utilisons React pour les interfaces utilisateur hautement interactives et constatons qu'il s'adapte bien à la taille de l'application. Je suis également heureux de répondre aux questions techniques à ce sujet. Mais je pense qu'en général, les gens ont des opinions bien arrêtées sur, par exemple, les modèles par rapport à l'expressivité, et je ne pense pas que forcer React à tout le monde soit la meilleure façon.

"Je ressens aussi la même chose", a déclaré Evan You. "Imposer un cadre unique à tout le monde, quel qu'il soit, n'est pas une bonne idée à l'OMI, car cela aliénera le groupe de développeurs qui ne sont pas dans ce cadre et impose un plus grand risque de stabilité à long terme."

Abramov a également déclaré que les gens sont déjà "très amers et divisés" sur le sujet de la sélection d'un cadre. Il a également tweeté un sentiment similaire avant la réunion.

Quand je lis des fils de discussion (par exemple sur WordPress), j'ai l'impression que les gens perçoivent chaque équipe comme hostile aux autres. C'est faux.

– Dan (@dan_abramov) 26 septembre 2017

Pensez-y comme s'occuper d'un jardin. Vous êtes les bienvenus chez nous. D'autres jardins sont super aussi

– Dan (@dan_abramov) 26 septembre 2017

"Je pense qu'il est important (et techniquement faisable) de séparer" quel framework utiliser pour le noyau "et" quel framework les développeurs de la communauté utilisent pour les extensions "", a déclaré Evan You.

"Oui, je pense qu'il y a un objectif ici d'être sans opinion sur ce que nous exposons aux auteurs de plugins, tant que les API/interfaces que nous exposons sont suffisamment flexibles (et faciles) pour créer les interfaces utilisateur et les interactions dont ils ont besoin pour mettre en œuvre, », a déclaré Andrew Duthie.

Le sujet de la prise en charge de l'interopérabilité des composants Web pour Gutenblocks a également fait partie des discussions lors de la réunion.

"Bien qu'ils soient moins puissants que la plupart des frameworks actuels à ce stade, ils sont susceptibles de devenir une norme W3C, garantissant qu'ils resteront et évolueront", a déclaré Felix Arntz. "De plus, une fois que la prise en charge du navigateur est entièrement là, il y a moins de fonctionnalités à implémenter par un cadre réel construit au-dessus."

Le représentant de Polymer.js, Justin Fagnani, a déclaré qu'il n'était pas d'accord sur le fait qu'ils sont "moins puissants" et a noté que les composants Web sont déjà une norme du W3C.

"Je pense que WP est également particulièrement bien placé pour aider à faire avancer la prise en charge des composants Web de manière native partout", a déclaré le développeur central d'EventEspresso, Darren Ethier. "Presque tous les frameworks ont désormais la capacité de fonctionner avec la spécification de composant Web. C'est juste une question de bonne mise en œuvre.

Plusieurs participants ont fait référence à custom-elements-everywhere.com, un site qui affiche les progrès des frameworks JS populaires sur la communication des éléments personnalisés d'une manière qui favorise l'interopérabilité. Matias Ventura a demandé aux développeurs principaux de React et Vue comment les composants Web (et leur avenir) s'intègrent actuellement dans chaque framework.

"Dans React, nous avons une certaine prise en charge des composants Web, mais nous n'en avons pas fait une grande priorité car les cas d'utilisation semblaient minces dans le passé, d'autant plus que l'ajout de composants Web n'a pas beaucoup de sens dans une application propriétaire où vous contrôler l'ensemble de la pile - mais nous avons néanmoins un certain soutien pour eux et je suis heureux d'envisager d'en ajouter d'autres, maintenant ou à l'avenir », a déclaré Sophie Alpert.

"Au niveau supérieur, je pense que des frameworks comme React/Vue fournissent ce qui n'est pas vraiment abordé dans les composants Web : des mises à jour DOM efficaces et déclaratives réagissant aux changements d'état", a déclaré Evan You. "C'est aussi pourquoi Polymer existe au-dessus des WC. J'ai toujours reconnu la valeur de WC en tant qu'interface d'interopérabilité.

Dans l'ensemble, les participants à la réunion étaient respectueux, collaboratifs et désireux d'apporter leur expertise pour aider les contributeurs WordPress à trouver la meilleure voie à suivre dans le processus de sélection du framework. La discussion se poursuivra lors de la réunion de la semaine prochaine et probablement dans les commentaires d'un prochain article Make/Core résumant la réunion.