Gutenberg: Choisir le framework JavaScript pour Gutenberg (~ WordPress)

Mon vote est avec VueJS

Je choisis VueJS

Vue a une grande communauté et devrait être le choix à venir.

Angulaire JS

Je voterai pour VueJS. Comme indiqué ci-dessus, c'est un débutant convivial et utilisé avec succès avec Laravel. Cela en fait le choix parfait.

Je voterai aussi pour Vue JS

Veuillez noter que crier simplement "Je préfère Vue" ou "Je veux XY" n'aide pas vraiment à prendre une décision ici. Si vous souhaitez voter, je vous suggère d'utiliser des réactions emoji ou quelque chose du genre au lieu d'encombrer un fil qui pourrait éventuellement servir de lieu pour documenter les résultats lors de l'évaluation de différents cadres.

J'irai avec Vue. Il est plus facile d'apprendre et de s'adapter. De plus, c'est moins controversé que Preact.

À la question de la "dépendance de la personne clé" qui se pose de temps en temps, n'est-ce pas ce que sont tous les plugins de fonctionnalités WordPress ou toutes les technologies inconnues? Koop a construit l'ancienne gestion des médias, Weston a fait une tonne de travail de personnalisation, Matías et quelques autres travaillent sur Gutenberg, à peu près tous les changements majeurs apportés à WordPress au cours des dernières années ont eu un petit groupe de personnes qui y travaillent. ou le comprendre.

Je pourrais regarder cela de la mauvaise façon, mais "la dépendance de la personne clé" pour tout choix semble être un hareng rouge. Avec l'adoption, la dépendance aux personnes clés est entièrement éliminée. WordPress était autrefois un projet de dépendance de personne (s) clé (Mike et Matt) également. Je pense que c'est un argument faible pour éviter l'adoption.

Encore une fois, je pourrais penser à cela complètement faux, mais c'est un fil conducteur de pensée que je vois surgir de temps en temps et je ne comprends pas son importance apparemment élevée.

Pour ajouter au commentaire de

Je voterais pour VueJS! C'est de loin le plus facile à adapter par la communauté.

Je pense que les composants Web (sans Polymer, mais avec lit-html ou similaire si un DOM virtuel est nécessaire) devraient être considérés sérieusement. Utiliser la plate-forme et les standards est bien meilleur que n'importe quelle bibliothèque ou framework! Permet une structure de composants robuste et future sûre, qui est naturellement interopérable avec tous les frameworks. (Vue, Angular, React - à un degré différent actuellement: https://custom-elements-everywhere.com/)

• https://blog.revillweb.com/why-web-components-are-so-important-66ad0bd4807a
• https://medium.com/@velmu/go -long-on-web-components-b1e0689f64e4

Je suis heureux d'aider ce projet à essayer Vue ou un composant Web si nécessaire.

Consultez également le PR # 2463 pour Gutenberg _ "Interopérabilité des blocs indépendante du framework (Vanilla, Vue)" _

Je suggérerais de se pencher vers Vue.js pour plusieurs raisons.

1. Expérience avérée dans le cadre PHP Laravel.
2. Semble être facile à ramasser et à adopter pour que plus de gens puissent contribuer.
3. Si nous nous éloignons de React, faisons-en un changement net et définitif (en utilisant Preact, nous nous accrochons (React) dans un sens).

Juste mon avis, mais cela semble être le meilleur choix et de nombreuses autres personnes semblent favoriser Vue et c'est au moins quelque chose à considérer de toute façon.

Vue semble avoir une plus grande dynamique et un meilleur support communautaire que Preact. Il résout plus de problèmes (car il est livré avec la gestion des états) et a une courbe d'apprentissage plus douce. La documentation est _excellent_.

Ma préoccupation avec Preact est que cela ressemble trop à React pour se sentir légalement en sécurité (les brevets de React pourraient couvrir Preact), et trop différent de React pour être un simple port (il y a assez de différences pour casser les bibliothèques d'aide, les plugins, etc.).

Vue tout le chemin bébé !!

• [x] [Gitlab] (https://about.gitlab.com/2016/10/20/why-we-chose-vue/)
• [x] [HN] (https://news.ycombinator.com/item?id=14410190)
• [x] [PixelJets] (http://pixeljets.com/blog/why-we-chose-vuejs-over-react/)

Github Stars -> Ici
Serait absolument ravi pour les développeurs WordPress si Vue.js 🖖

Vue a développé une grande communauté au fil du temps ainsi que des mises à jour / mises à niveau régulières du cadre.

PS. rejoignez https://chat.vuejs.org pour une expérience communautaire géniale .. des développeurs vraiment dopeass là-bas :)

@jbreckmckye Je ne veux pas faire dérailler la conversation, mais comprenez-vous en quoi consiste la clause brevet? Il s'agit de protéger Facebook contre les poursuites en matière de brevets d'autres entreprises. Par exemple, disons que mon entreprise fabrique des réfrigérateurs intelligents et que nous utilisons React dans l'interface utilisateur. Disons que nous avons un brevet à ce sujet, puis FB commence à enfreindre ce brevet ... si nous poursuivons, nous ne pouvons plus utiliser de réaction.

Cela n'a rien à voir avec les brevets en réaction (ce que je ne suis même pas sûr que Facebook a ... sinon, préact, vue et quiconque avec un cadre similaire aurait été poursuivi en justice maintenant)

En tant que membre principal de Vue.js, je voudrais aborder le problème du facteur de bus. Nous savons que c'est actuellement un point très soulevé, nous mettons maintenant des mesures en place pour répondre à certaines des préoccupations.

1) Compte org Vue.js pour npm, afin que nous puissions publier plus facilement en équipe
2) Gérer en interne les détails pour faire fonctionner les choses (sites Web, etc.)
3) Initialiser un collectif ouvert, pour séduire les contributeurs et accompagner la communauté grandissante. https://medium.com/the-vue-point/vue-is-now-on-opencollective-1ef89ca1334b
4) L'écosystème Vue s'est rapidement développé et de plus en plus de contributions au référentiel de base proviennent de la communauté elle-même. https://www.youtube.com/watch?v=993X1kiisFE
5) En regardant les dépôts officiels de Vue, vous pouvez voir qu'en fait beaucoup d'entre eux sont maintenant fortement maintenus par d'autres membres de l'équipe principale plus qu'Evan

Dans l'ensemble, Vue.js se développe rapidement et le «facteur de bus» a considérablement diminué. Comme le note @philiparthurmoore , Evan aura toujours une grande implication et c'est une bonne chose.

Il semble y avoir beaucoup de fans de VueJS ici. Quelqu'un a-t-il réellement migré une grande base de code de React vers Vue? À quoi ressemble le chemin de la migration?

D'après ce que je peux voir, Preact semble être un choix beaucoup plus pragmatique étant donné qu'il est compatible API avec React. Alors que la migration vers Vue nécessiterait une réécriture beaucoup plus étendue.

@patrickgalbraith C'est en fait la mauvaise raison de considérer Preact. Il doit être jugé sur ses mérites et non parce qu'il est plus facile d'y migrer. Je peux voir les problèmes suivants avec Preact

• Communauté plus petite par rapport à VueJS
• Odeurs de code - La transition vers une bibliothèque très similaire peut forcer de mauvaises pratiques (pour la raison évidente qu'il s'agit du chemin le plus rapide)
• S'en tenir à Preact, c'est comme s'en tenir à React de toute façon (lisez-le sur un fil de discussion)

Je n'ai utilisé Preact que de manière limitée, c'est donc ce que je pense.

@ blake-newman Merci d'être passé et d'avoir clarifié cela. 💯

Il doit être jugé sur ses mérites et non parce qu'il est plus facile d'y migrer.

Ouaip. C'est une décision à long terme.

@patrickgalbraith si tout le projet était terminé, alors je considérerais que c'est un argument

Comme le projet en est encore à ses débuts, comme @ahmadawais , c'est moins un problème.

De plus, Vue, React et Preact ont des paradigmes très similaires. Vous pouvez facilement basculer entre les deux, il y aura des différences.

Il existe également, bien que probablement pas totalement pratiques dans ce cas, des outils qui peuvent aider à la paix migratoire. https://github.com/SmallComfort/react-vue

Bien qu'il ne s'agisse pas de comparer les mêmes outils, cet article soulève de grands points à considérer. https://medium.com/unicorn-supplies/angular-vs-react-vs-vue-a-2017-comparison-c5c52d620176

@ blake-newman n'en est-il vraiment qu'aux premiers stades, étant donné qu'il reste plus de 6 mois de développement? Gardez également à l'esprit que Calypso a également plus de deux ans.

Quoi qu'il en soit, je suis sûr que ce ne sera pas un problème car, compte tenu de ce que vous avez dit, il est facile de basculer entre React et Vue.J'ai hâte de voir la pull-request.

Le pochoir semble également prometteur.

https://github.com/ionic-team/stencil-starter

Mon avis est que ces 2 points constituent un argumentaire fort pour Vue:

• Débutant sympathique et ..
• Énorme soutien de la communauté

Les deux sont, à mon avis, 2 des piliers fondamentaux du projet WordPress.

Je suis peut-être seul, mais j'ai suivi de près le Patreon d'Evan au cours des six derniers mois environ, et il disait que s'il ne pouvait pas obtenir de financement, il aurait besoin de travailler plus.

C'est un risque réel lorsqu'un projet a un faible financement ET qu'il est rédigé par une seule personne (il y a moins de six mois). Ses chiffres Patreon ont en fait diminué récemment. Si le gars principal dit qu'il pourrait ne pas être en mesure de travailler dessus si les finances ne s'alignent pas, alors les finances sont un risque très réel. Le choix du cadre d'un grand projet à long terme reposant sur le fait qu'un (impressionnant) développeur peut payer un loyer SF est un gros problème.

Bien sûr, Vue pourrait être généreusement soutenu par d'autres entreprises, mais il est difficile de le savoir.

L'adoption par la communauté ne garantit pas non plus la longévité du cadre, les gars. Si vous ne l'avez pas remarqué, les frameworks «meurent» tout le temps.

Cela dit, je suis impressionné qu'un membre de l'équipe principale de Vue se soit présenté pour résoudre le problème du seul contributeur / le facteur de bus, même par son nom, et a donné quelques raisons pour lesquelles le problème de développement unique pourrait être moins problématique. Mais c'était un vrai problème dans un passé très récent.

je vote pour Vue

• API simple / vous pouvez apprendre les choses les plus basiques en moins d'une semaine
• implémentation de flux simple via vuex
• résultats rapides: P
• communauté grandissante
• MIT

Un autre vote pour Vue, pour toutes les raisons exposées ci-dessus. Mes excuses à tous ceux qui ont activé les notifications par e-mail!

@ michaelbdavidson7 , Vue aura finalement la contribution d'Evan et la campagne Patreon était de l'aider à faire un plus grand travail Vue. Il ne reçoit pas assez via Patreon et entreprend d'autres travaux que je ne pense pas compromettre Vue. Comme @ blake-newman (un contributeur principal de Vue) l'a suggéré (et Evan lui-même il y a quelques mois), Vue ne dépend plus d'une seule personne. Autant WordPress ne dépend pas d'une seule personne. Nous avons Matt, oui, mais WordPress peut continuer dans une certaine incarnation sans Matt (désolé Matt;)). La même chose est vraie pour Vue (désolé Evan;)).
@ahmadawais qui, selon moi aussi, n'est pas précis concernant la "dépendance de la personne clé".

Si cet objectif est atteint, je peux passer moins de temps à penser aux canaux de monétisation privés (par exemple, prendre des contrats de support / conseil) et travailler davantage sur du contenu qui profite à toute la communauté Vue ...

^ Cet objectif n'a pas été atteint et n'est même pas proche. En supposant qu'il pensait ce qu'il a dit, il pensait peut-être encore à la passation de marchés, et si cela change, cela devrait être considéré comme un développement très récent. C'est toujours là-haut en ce moment. Si la personne clé passe un contrat pour payer le loyer, il risque de ne pas continuer à travailler sur le cadre, et si cela change, cela a changé très récemment.

Tous les gars qui crient juste des frameworks par leur nom n'ont rien appris ces dernières années lol.

@ michaelbdavidson7 L'objectif a été atteint pour aider Evan à y travailler à plein temps. L'objectif supplémentaire est là pour l'aider à soutenir davantage et en partie la communauté. C'est ainsi que naît la campagne collective ouverte, qui a pour seul but de soutenir la communauté.

Je soulignerai également que la campagne Patreon n'est pas la seule source de revenus via les contributions, malheureusement Patreon ne convient pas à toutes les entreprises à travers lesquelles sponsoriser. Ainsi, certaines contributions sont payées et facturées séparément.

La raison pour laquelle le nombre a diminué, c'est parce que l'un des sponsors venait de Chine, et il y a une limite au montant d'argent qui peut être dépensé de la Chine en un an. Ce n'est que temporaire et nous espérons que cela reviendra au soutien.

Les autres canaux de revenus qu'Evan obtient en faisant des ateliers ne sont pas seulement utiles pour la communauté mais aussi pour lui. De cette façon, il peut obtenir une exposition directe pour aider à apprendre comment la bibliothèque sera et est utilisée. Ce n'est donc pas aussi grave qu'il y paraît.

Vue est durable, et je ne parle pas au nom d'Evan, mais je suis sûr qu'il est très satisfait de la situation financière actuelle.

Une chose que j'ai appréciée à propos de React était sa documentation d'accessibilité . Je pense que c'est quelque chose dont il faut être conscient et dont il faut tenir compte lors de la réflexion sur de nouveaux cadres. Il existe des principes d'accessibilité mentionnés ici qui s'appliquent à toute application Web écrite de manière défensive, mais il peut être utile de disposer d'une documentation spécifique au cadre.

Vue.js a un problème d'accessibilité ouvert . Un rapide coup d'œil sur Preact et je ne vois pas grand-chose; est-il sûr de supposer que la documentation de React s'applique?

En fin de compte, ce serait formidable d'avoir un cadre qui rend les tests programmatiques pour tout le monde simples et automatiques afin que nous puissions éliminer la majorité des erreurs et des avertissements.

Si vous voulez une transition facile juste à cause de la licence, une option que vous pouvez envisager est InfernoJS. https://github.com/infernojs/inferno, il offre presque la même API avec une empreinte plus petite et une exécution plus rapide. Son licence MIT. Je suis l'un des responsables de l'inferno et je pourrais aider à la transition.

@Havunen merci d'être passé. Je regardais dans Inferno l'autre jour, je ne l'ai pas encore essayé. Ça a l'air prometteur de toute façon!

Pour le contexte, l'auteur d'Inferno a été embauché par Facebook

Je vote pour markoJS http://markojs.com/

Gutenberg utilise de nouvelles fonctionnalités de React 16, c'est-à-dire des portails et éventuellement des fragments , que Inferno et Preact ne supportent pas, ce qui pourrait être pris en compte lorsque l'on parle de bibliothèques de type React si l'utilisation de ces fonctionnalités est critique pour gutenberg.

Je suggère DIO 8 principalement parce que c'est la chose la plus proche de React 16 à ce stade en termes d'API.

Cela dit, cela pourrait être une bonne expérience curieuse de configurer Gutenberg en aliasant les bibliothèques de type React mentionnées et de voir si elles fonctionnent sans aucun changement / problème pour quiconque le souhaite.

Je ne sais pas s'ils sont exactement les mêmes, mais pour les portails, il y a vue-portal développé par @LinusBorg , l'un des membres de l'équipe principale vue :)

@youknowriad J'ai été embauché par Facebook. @Havunen et l'équipe derrière Inferno font un excellent travail sans moi. Le travail qu'ils font sur Inferno est génial et le projet vaut le coup d'œil sur Inferno si vous en avez l'occasion :)

Je suis l'un des auteurs de Marko.js et je voudrais jeter Marko.js sur le ring pour examen. Un certain nombre de membres de notre communauté nous ont contactés et nous ont signalé ce problème GitHub. Marko.js a une licence MIT compatible open source et elle est utilisée pour construire eBay.com et il a une communauté forte et croissante. Cela apporte un certain nombre des bonnes idées de React et Vue, mais nous avons déployé beaucoup d'efforts pour rendre les choses plus simples et plus rapides (grâce à des optimisations au moment de la compilation) et nous avons supprimé le passe-partout partout où nous le pouvions. Je voulais juste souligner quelques-unes des fonctionnalités ci-dessous:

Composants de l'interface utilisateur

Le modèle de composant de Marko est très similaire sur le plan conceptuel à celui de React (entrée, état, liaison d'événement, événements du cycle de vie, rendu DOM virtuel, diffing / patch DOM, etc.). Une transition à Calypso ne nécessiterait pas beaucoup de frais généraux cognitifs. Marko prend également en charge les composants d'interface utilisateur à fichier unique. Voici à quoi ressemble un composant d'interface utilisateur Marko:

class {
  onInput(input) {
    this.state = { 
      count: input.count || 0 
    };
  }
  increment() {
    this.state.count++;
  }
}

style {
  .count {
    color:#09c;
  }
}

<div.count>${state.count}</div>
<button on-click('increment')>
  Click me!
</button>

Syntaxe

Marko n'utilise pas JSX, mais un sur-ensemble de HTML qui prend en charge les expressions JS. Il est très similaire au HTML, mais pas complètement limité au HTML comme le fait Vue. Cela donne une syntaxe plus agréable pour des choses comme les boucles et les conditions et rend plus clair où les expressions sont utilisées par rapport à une chaîne HTML standard. Nous pensons que les modèles Marko.js sont extrêmement lisibles et maintenables (Marko prend également en charge une syntaxe concise basée sur l'indentation).

Rendu côté serveur

Je ne sais pas à quel point c'est important pour WordPress, mais Marko prend également en charge le rendu côté serveur haute performance sous Node.js avec prise en charge du rendu asynchrone et en streaming.

Lectures complémentaires:

• Marko contre React
• Shootout de rendu côté serveur avec Marko, Preact, Rax, React et Vue
• Pourquoi Marko est-il rapide?
• 10 superbes fonctionnalités Marko
• Meetup: Construire l'interface utilisateur - une comparaison de React, Vue et Marko (du créateur Marko) - Vidéo | Diapositives

Je vote pour Marko !! 🙂

Si quelqu'un de l'équipe WordPress (@ahmadawais? @M? @Swissspidy?) Aimerait avoir une discussion rapide pour répondre à des questions sur Marko, nous, l'équipe Marko, serions heureux de le faire. : call_me_hand: 😸

@Je l'ai commenté sur le blog de @m , mais je voulais le publier ici sous une forme plus publique:

Je recommande l'écosystème Ember comprenant à la fois Ember et Glimmer.js.
Pour les composants Web plus petits tels que la suppression des éditeurs et d'autres comportements de contenu, Glimmer offre une excellente expérience et crée une baisse des composants Web qui peuvent s'exécuter en dehors d'un cadre.

Pour des projets plus importants comme Guttenberg et Calypso où le routage, la gestion complexe de l'état, le contrôle d'accès, la gestion de contenu et bien plus encore entrent en jeu: Ember fournit le meilleur ensemble d'outils et d'écosystème
Avec un grand nombre de contributeurs: les modèles d'ensemble, les addons et le système de construction d'Ember aident à maintenir les applications performantes et maintenables à mesure que les applications évoluent.
Les moteurs Ember et les modules complémentaires in-repo aident à garder les éléments optionnels de l'application modulaires et installables pour les utilisateurs finaux.

Ember est largement utilisé par d'autres systèmes de gestion de contenu et cet effort peut être développé, appris et partagé.
Comme mentionné dans un commentaire précédent sur le blog de @m , Ghost utilise Ember pour son administrateur et son éditeur, mais Ember est également utilisé avec Drupal headless, Cardstack et des sociétés de contenu comme Conde Nast , Bustle , etc.
Cela signifie que des fonctionnalités communes telles que les listes de balises, les éditeurs basés sur des composants (en particulier l' éditeur Mobiledoc ), etc. sont disponibles dans le cadre de l' écosystème Ember Addon .

D'une expérience de communauté et de développeur, Ember correspond le mieux à l'écosystème Wordpress (en tant que développeur ayant travaillé dans Wordpress pendant plus de 5 ans).
Ember a de nombreuses meilleures pratiques intégrées, bien documentées ou disponibles via des addons; cela réduit la question de savoir "est-ce que cela fonctionnera avec mon application" et aide à mieux réduire les éventuels bogues de sécurité ou de performances.
Ember est construit sur des abstractions personnalisables, ce qui signifie que la complexité peut être abstraite des développeurs finaux et que le code difficile peut être limité dans sa portée pour rendre la personnalisation facile et amusante.
Les addons Ember correspondent étroitement aux plugins et aux thèmes Wordpress car ils sont détectés automatiquement et ont une configuration par défaut prête à l'emploi, mais peuvent être personnalisés pour répondre aux besoins de l'utilisateur final.
Il existe un outil de curation pour Ember Addons appelé Ember Observer pour vous aider à trouver les addons les plus populaires, les mieux maintenus et les plus stables.

Calypso et Guttenberg sont de grands projets ambitieux avec des besoins matures. La communauté Ember a des solutions matures pour l'accessibilité, l'internationalisation et d'autres exigences des applications Web modernes.

Je fais partie de l'équipe d'apprentissage Ember.js et travaille en étroite collaboration avec les principaux contributeurs, j'aimerais parler ou organiser une conversation avec d'autres membres de l'équipe Ember sur la façon dont Ember et Glimmer pourraient répondre à vos besoins.

J'ai remarqué qu'il était mentionné sur les portails React et je voudrais ajouter 2 ¢ supplémentaires qu'Ember a un addon bien entretenu appelé Ember Wormhole pour fournir cette fonctionnalité et de nombreux addons s'appuient sur cela pour fournir des fonctionnalités telles que des dialogues, des changements de tête de document , et plus.

Je voterais pour Marko pour son support de rendu asynchrone natif et ses performances rapides côté serveur. !!!

@ patrick-steele-idem & @mlrawlings - merci d'être passé. Je sais pertinemment que MarkoJS est très puissant. Bien que je n'ai pas eu l'occasion de l'utiliser dans un projet, j'ai dirigé un projet dans lequel les développeurs utilisaient MarkoJS pour son moteur de rendu d'animation rapide, en quelque sorte. C'était très différent et impressionnant.

Je vais creuser plus.

J'ai travaillé avec Ember.js à la fois dans une très grande organisation d'entreprise où des applications fonctionnaient dans d'autres applications et dans une très petite startup avec de petites applications autonomes. Les opinions et les conventions fortes d'Ember.js ont contribué à maintenir une base de code productive et maintenable à mesure que les équipes et les applications se développent. Cela permet non seulement de partager du code (via des moteurs ou des addons) entre les projets, mais permet également à un développeur qui a appris les conventions d'être productif et de contribuer à pratiquement n'importe quelle application Ember.

Le plus grand avantage d'Ember a été sa stabilité sans stagnation. Sans avoir à changer aucun de nos modèles, nous avons obtenu d'énormes avantages en termes de performances lors de la sortie de la nouvelle version d'Ember, qui avait totalement remanié le moteur de rendu sous nous. Les niveaux d'abstraction semblent parfaits pour les applications Web modernes et riches qui peuvent se développer et doivent évoluer dans un avenir lointain.

Lorsque des modifications sont nécessaires, la migration est au cœur des préoccupations et les guides de désapprobation vous aident à chaque étape du processus (plus récemment en utilisant les transformations JavaScript AST / CST pour mettre à niveau automatiquement les applications).

Les autres applications Web populaires qui utilisent Ember non mentionnées par @rtablada incluent Twitch.tv , le tableau de bord Heroku , Travis CI et Discourse .

@SaladFork merci pour la mise à jour, j'ai commencé par nommer principalement des entreprises dans le domaine de la gestion de contenu.

Voici quelques exemples d'applications Ember open source à grande échelle:

• Travis CI
• Hospital Run - Un système EMR (Electronic Medical Record) conçu pour une utilisation hors ligne, en particulier dans les cas de faible connectivité en Afrique
• Fantôme

Je ne sais pas dans quelle mesure il peut entrer dans les détails, mais je cingle @tehviking pour voir s'il pourrait partager une partie de la récente transition de son équipe d'une application de React à Ember.

Je voterais pour Marko pour ses performances, sa flexibilité et sa syntaxe très claire et facilement compréhensible!

+1 pour Marko également. Ayant bien travaillé sur le front-end avant de commencer à perdre les cheveux et à devenir gris (comme, il y a longtemps), c'est le framework / la bibliothèque front-end que je cherchais depuis toutes ces années. C'est une grande raison pour laquelle j'aime travailler chez eBay avec @ patrick-steele-idem et @mlrawlings aussi.

Marko JS a mon vote. Extrêmement sous-estimé compte tenu de sa facilité d'utilisation et de ses performances.

J'adore marko-widget avec marko efficace. cadre tout simplement exceptionnel et maigre. C'est beaucoup plus rapide que les autres frameworks. Le benchmark est ici

Je vote pour MarkoJS, nous étions un magasin de guidons depuis de nombreuses années.

Lorsque nous avons fait le choix stratégique de passer aux micro-services et à une architecture basée sur des composants pour notre plate-forme, nous recherchions le bon cadre pour avoir un équilibre entre le rendu côté serveur et le rendu client. Nous sommes une plate-forme qui a des petites annonces sur 6 marchés différents, y compris des marchés émergents comme l'afrique du sud et le mexique, où les données sont une grande préoccupation et nous avons besoin d'un site qui honore vraiment les exigences de navigation de l'utilisateur sur des appareils de quelques années et utilisant également moins de données. En outre, l'utilisateur naviguera sur le site dans les deux sens jusqu'à ce qu'il trouve un article qu'il aime acheter, ce qui signifie que nous devons avoir un rendu de serveur très rapide lorsque l'utilisateur navigue.

Après mûre réflexion, nous avons choisi MarkoJS avec le fait qu'il prend en charge:

1. Rendu de serveur rapide avec de bonnes performances de serveur
2. Pousse le premier octet dès que possible
3. Possibilité de créer des composants mineurs et de les rendre de manière asynchrone au fur et à mesure que les données sont prêtes
4. Capacité à construire une architecture de composants plug and play
5. Maximisez le rendu du client avec une architecture identique ou meilleure de React / Vue.
6. Tests pilotés par les composants qui peuvent être utilisés non seulement pour tester le rendu, mais également l'état du composant

(Une histoire à succès d'eBay Classifieds)

+1 pour Angular (PAS AngularJS).

La CLI angulaire est de loin le meilleur de tous les frameworks, et avec des plans de migration en magasin pour une migration transparente entre les versions, elle conviendrait très bien.

De plus Angular est très bien adopté dans le domaine des entreprises, où WordPress pourrait utiliser un peu d'amour si WordPress continue à se développer en tant que plate-forme pour les consultants et les pigistes, et cesse d'être juste une course vers le bas.

Il possède une solide communauté de développeurs de tous niveaux. L'équipe principale est toujours formidable de discuter avec qui elle travaille pour Google ou non. WordPress est en grande partie (pour la plupart des développeurs de haut niveau) une communauté dans laquelle ils sont impliqués, donc je dirai que sur le plan de la communauté, Angular s'adapte parfaitement

J'ai récemment fait une conférence sur Vue dans les environnements rendus par serveur ( diapositives ici ), et après avoir travaillé avec Vue dans un environnement .NET au cours des derniers mois, je suis convaincu qu'il n'y a pas d'autre option pour travailler dans des environnements comme ça. Vous obtenez un très bon combo de pouvoir composant ce qui doit être intégré dans JS pour une forte interactivité tout en permettant au back-end de continuer à contrôler principalement le site.

Ce qui signifie qu'il est à peu près parfait pour construire sur ce que WordPress a maintenant. Toute autre bibliothèque JS rendue par le serveur nécessitera probablement un nœud. Vue non; vous pouvez enregistrer un composant comme <gutenberg-editor> et demander à WordPress d'envoyer littéralement <gutenberg-editor> dans le HTML. Vue peut utiliser le HTML envoyé par WordPress pour démarrer la page. C'est un peu comme les composants Web à cet égard, et ne nécessite pas un autre élément de la technologie BE pour obtenir le rendu du serveur.

C'est l'une des raisons pour lesquelles un framework comme Laravel l'a choisi par défaut: il est super facile à intégrer dans des back-ends non-Node. Je pense que WordPress devrait l'adopter pour les mêmes raisons.

J'ai voté pour Vuejs .
Le même cas avec @borantula sur son commentaire

Mon CTO a présenté Vuejs à l'équipe - des nouveaux arrivants sur le front-end, et ils y entrent rapidement, maintenant ils sont satisfaits de Vuejs. Mon équipe utilise WordPress dans de nombreux projets.
Actuellement, nous utilisons Vuejs et Custom Element pour créer le front-end d'un projet qui utilise WordPress dans le backend. Cela fonctionne très bien.

Comme @ blake-newman et Evan l'ont dit, Vuejs ne dépend plus d'une seule personne clé, on peut donc dire que les CONS mentionnés par @ahmadawais n'existent plus.

MARKO fonctionne bien dans notre application Web. Le rendu progressif fonctionne comme un charme.

Je ne peux rien dire à propos de Preact ou MarkoJS (fortement référencé dans les commentaires) mais je peux parler de Vue comme je l'ai présenté à notre équipe (travaillant principalement sur php + jQuery à l'époque) il y a un an et cela change progressivement leur compréhension de javascript, sortir de l'état d'esprit jQuery.

Je pense que ce serait un bon choix non seulement pour Gutenberg, mais aussi pour l'objectif à long terme de WordPress, la transition vers une plate-forme plus orientée API avec plus de javascript sur les interfaces. C'est une courbe d'apprentissage plus facile et la familiarité encouragera d'autres développeurs WP à intervenir également.

J'ai vu comment VueJS prospère dans la communauté Laravel et est presque devenu un choix de facto pour la plupart, je pense que ce sera également comme ça dans la communauté WordPress.

Backbone.js

/ s

Je voulais apporter mon soutien à MarkoJS.

Il y a deux ans, j'ai déplacé l'infrastructure de mon entreprise d'ExpressJS et Jade (maintenant PUG) vers Marko JS. Mon entreprise souhaitait créer des composants compliqués et réutilisables dans tout notre écosystème. Les développeurs voulaient de la rapidité et de la réutilisabilité. Les concepteurs voulaient une charge de conception réduite. Nous n'avons pas regardé en arrière depuis.

Nous avons maintenant plusieurs sites Web orientés clients écrits en Marko et un système CMS complet.

Finalement, j'ai choisi MarkoJS pour ce qui suit:

• Rendu de serveur rapide même avec des frameworks comme Koa et / ou ExpressJS
• Gère le rendu asynchrone des données de page
• Capacité à créer des composants plug and play pour un écosystème plus vaste
• De meilleures performances que React / Vue
• Syntaxe de modèle extrêmement simple

Je tiens également à souligner que l'équipe MarkoJS a littéralement été formidable. @ patrick-steele-idem et @mlrawlings ont toujours été à bord pour créer de nouvelles idées, résoudre des problèmes et aider les individus.

👍 pour MarkoJS

Preact est une bibliothèque compatible React-API, ce qui signifie que Preact bénéficie directement de l'écosystème de React et du grand nombre de packages / composants OSS disponibles. L'écosystème de Vue est beaucoup plus petit en comparaison. La documentation des packages / composants Vue tiers est en chinois.

S'il vous plaît, plus de "Je vote XYZ", ils ne font rien pour ajouter à la conversation à part envoyer des réponses inutiles aux personnes abonnées à ce problème

🔥 Angulaire

• PRO: le plus grand concurrent à React
  Pour plusieurs personnes. la question est souvent "Angular ou React?" / "Réagir ou angulaire?". La communauté Angular est sans doute la plus grande parmi les alternatives React et se développe rapidement.

• PRO: beaucoup de ressources d'apprentissage
  En plus des documents et guides officiels de l'API, Angular possède probablement le plus grand écosystème de matériel pédagogique, d'articles de blog, de livres et de nombreux cours vidéo, à la fois gratuits et commerciaux sur toutes les principales plates-formes d'apprentissage, ainsi que Google GDE l'enseignant dans des ateliers et des conférences.

• PRO: s'intègre bien avec Redux
  Soit directement, soit via RxJS habilité Ngrx (soutenu par un membre de l'équipe Angular)

• PRO: Meilleur support d'outillage de sa catégorie

  • CLI a bien plus de fonctionnalités que les autres

  • Très bon support de l'éditeur dans VS Code en particulier avec le service de langue

  • Écrit pour TypeScript, offre la meilleure expérience TypeScript

• PRO: riche en fonctionnalités, avisé et organisé par défaut
  La séparation logique via les modules angulaires (NgModule), ainsi que les fonctionnalités standard pour les formulaires, les appels HTTP, le routage, etc. facilitent la lecture du code et la contribution des autres développeurs

• PRO: Meilleure intégration avec RxJS
  Utile pour de nombreux flux d'API et de nombreux flux d'événements sur une seule page en général

• PRO: Système DI (Dependency Injection) intégré
  Utile pour créer des points d'extensibilité et peut-être même un système de plugins, surtout lorsqu'il est combiné avec RxJS

• PRO: Coche de nombreuses autres cases couvertes par d'autres bibliothèques

  • Bibliothèques d'interface utilisateur avec licences permissives
    Il y a PrimeNg, Angular Material 2, ngx-bootstrap et bien d'autres ...

  • Chargement paresseux
    Prise en charge intégrée des itinéraires de chargement différé et prise en charge manuelle des modules de chargement différé

  • CSS spécifique aux composants
    Garantit que le CSS est limité au composant, chargé uniquement lorsque le composant est chargé et a des hooks pour le CSS global

  • Rendu côté serveur
    Travaille déjà avec Node et ASP .NET Core, et obtient une meilleure concentration ces jours-ci

  • Essai
    Angular fournit des assistants de test indépendants du framework de test unitaire qui rendent les tests unitaires très faciles. Ils génèrent des tests par défaut à partir de la CLI en utilisant Jasmine, qui peuvent être facilement basculés vers Jest. Ils fournissent également un Protractor optionnel de wrapper Selenium pour faciliter les tests E2E (même si vous n'en avez pas vraiment besoin, j'utilise Selenium .NET pour mes applications Angular, rien de spécifique à Angular, mais ils essaient de le rendre encore plus facile).

  • Prise en charge mobile / PWA
    Google est le plus grand partisan des PWA, et le support est déjà affiché dans Angular CLI avec Service Workers et Universal (support côté serveur), et Ionic (support Cordova) et NativeScript (applications natives)

• PRO: Focus sur la prise en charge du navigateur
  Avec une page polyfills dédiée dans la documentation et l'insertion de polyfills (commentés) par défaut dans CLI, Angular vous tient au courant des polyfills exacts dont vous avez besoin, disons IE <= 11, vous n'avez donc pas besoin de charger un polyfill beaucoup plus grand réglé sans raison. C'est parce qu'ils se soucient de la prise en charge du navigateur.

• PRO: soutien de grandes entreprises
  Angular est l'une des rares bibliothèques discutées ici (la seule?) Qui est soutenue par une grande entreprise.
  En soutenant ici, pas seulement une entreprise qui l'a utilisé dans quelques projets et a contribué à l'écosystème, mais en étant des responsables officiels qui paient les développeurs et les rédacteurs techniques pour qu'ils travaillent à plein temps et investissent dans les leaders de la communauté (GDE et DevRel dans le cas de Google).
  Ce n'est pas un PRO, car il est livré avec une licence MIT sans clauses supplémentaires, sans notes de révocation, ou tout autre élément qui peut être déroutant ou effrayant pour certaines personnes.

J'ai implémenté Vuejs pour certains projets tels que les plugins, l'API REST. Je dois dire que c'est facile à apprendre, qu'il a beaucoup de fonctionnalités, une énorme communauté et son écosystème est également bon.

De nos jours, Vuejs se développe rapidement. Ce sera un choix judicieux si Vuejs est intégré au code WordPress.

@cyberwani @thephilip @evoratec et autres.

@ntwb a déjà répondu au commentaire suivant:

S'il vous plaît, plus de "Je vote XYZ", ils ne font rien pour ajouter à la conversation à part envoyer des réponses inutiles aux personnes abonnées à ce problème

Alors, arrêtez de faire des commentaires inutiles. Pour montrer votre soutien, vous pouvez utiliser des emojis github pour aimer un commentaire favorisant votre bibliothèque.

Vue.

À propos, il y a Alibaba derrière Vue maintenant, ainsi que le projet Weex Apache qui permet à Vue api sur mobile.

Je mettrais vraiment un peu de modération ici, trop de fan boys sans arguments clairs

Ceci est le dernier avertissement, la prochaine étape est que nous commençons à supprimer les commentaires ...

Moi, moi-même, je n'ai pas utilisé Marko, Preact ou Vue.js, je ne connais aucun d'entre eux pour être honnête, j'aimerais entendre et lire ce que la communauté WordPress a à dire sur ces frameworks, chacun d'eux, les mérites techniques de chacun, l'écosystème environnant de chacun, l'outillage de construction et, enfin et surtout, les personnes et les communautés derrière ces projets. 😄

Je ne veux pas lire "Mon vote est pour XYZ", si vous souhaitez ajouter un vote, faites défiler vers le haut et ajoutez une réaction emoji _thumbs up_ à votre cadre de choix qui a déjà été mentionné ci-dessus. 👍

Il n'a pas fallu longtemps pour que deux nouveaux commentaires apparaissent depuis mon précédent commentaire 😞

À cette fin ... Si votre commentaire a été ajouté après https://github.com/WordPress/gutenberg/issues/2733#issuecomment -329705942 et que tout ce que vous avez dit est _ "Je vote pour XYZ" _ ou envoyez un SMS à cela effet vos commentaires ont de très grandes chances d'être supprimés , les futurs commentaires du même acabit seront également supprimés .

Si vous revenez sur ce problème et que vous vous demandez pourquoi votre commentaire a été supprimé, voici pourquoi

@ahmadawais J'ai quelques commentaires.

La migration de Gutenberg de React vers ...?

En ce qui concerne:

@patrickgalbraith C'est en fait la mauvaise raison de considérer Preact. Il doit être jugé sur ses mérites et non parce qu'il est plus facile d'y migrer. Je peux voir les problèmes suivants avec Preact

• Communauté plus petite par rapport à VueJS
• Odeurs de code - La transition vers une bibliothèque très similaire peut forcer de mauvaises pratiques (pour la raison évidente qu'il s'agit du chemin le plus rapide)
• S'en tenir à Preact, c'est comme s'en tenir à React de toute façon (lisez-le sur un fil de discussion)

Je pense que lorsque vous avez un projet avec un nombre non négligeable de lignes de code, vous devez être très prudent. Les ingénieurs aiment réécrire des choses, apprendre de nouveaux langages et de nouveaux frameworks, et pensent qu'ils feront un meilleur travail s'ils peuvent réécrire ce code ... Joel a parlé du danger des réécritures il y a très longtemps .
L'utilisation de Preact vous fera gagner beaucoup de temps. Vous pouvez sous-estimer le temps qu'il faudra pour passer à un tout nouveau cadre. Je ne sais pas pourquoi vous avez écrit "C'est en fait la mauvaise raison pour envisager Preact". En tant qu'ingénieur, les coûts et les délais de mise sur le marché figurent en bonne place sur la liste des critères que j'utilise pour évaluer et choisir des solutions.
Si le problème est vraiment le brevet Facebook, Preact le résout en minimisant les coûts. Preact est plus performant que React et même Vue: une empreinte plus petite et un rendu d'exécution plus rapide. Vérifiez également l'écriture d'Addy Osmani dessus .

Je ne sais pas comment vous avez évalué la taille de la communauté Preact. Si nous parlons de l'écosystème et des composants disponibles, l'utilisation de Preact vous permet d'utiliser la plupart des composants open-source de React. Donc, pour une question pratique, vous avez des gens qui, même s'ils ne travaillent pas explicitement sur Preact, continuent de produire du code dont vous pouvez profiter. Vous pouvez toujours considérer l'écosystème de React comme faisant partie de l'écosystème de Preact.

Pourquoi Vue est toujours votre option préférée?

Je pense que le 3ème point ici "Rester avec Preact, c'est comme rester avec React de toute façon" est probablement la raison principale pour laquelle vous hésitez à choisir Preact. Ai-je tort? Quel est le problème avec React à côté de son brevet?

Regardant la vue d'ensemble

J'ai lu que tout ce que vous choisirez pour Gutenberg sera également utilisé pour Calypso.
Gutenberg n'utilise React que sur le frontend. Lorsque vous regardez le rendu côté serveur, la situation devient plus complexe mais Preact semble toujours une option de migration plus facile.

Je pense que vous devez examiner vos critères. Si vous envisagez sérieusement une réécriture et que conserver le rendu isomorphe est important, MarkoJS semble en

Si je suis parti de zéro et que j'étais prêt à ignorer l'écosystème React, MarkoJS est une évidence.

Je regarde les performances et MarkoJS ne semble pas avoir de rivaux . 40x plus rapide que React, 10x plus rapide que Vue et 6x plus rapide que Preact est fou. Dans mon livre, 30% d'améliorations ne sont pas pertinentes, mais lorsque vous avez une amélioration supérieure à 10x, vous devez sérieusement y prêter attention.
Lorsque vous avez une présence modeste et réussie et que vous pouvez utiliser 10 serveurs au lieu de 100, ou 2 au lieu de 20, cela fait une grande différence.

La divulgation complète Je n'ai aucun attachement émotionnel soit préact ou MarkoJS. Je pense simplement qu'ils ont plus de sens que les alternatives d'une perspective d'ingénierie.

Bonne chance avec votre décision 😃

@ChrisCinelli ce sont des nombres ssr ...

Je suis du monde Drupal (nous regardons ce numéro: D) donc je n'ai aucun intérêt à cela. Mais en lisant les commentaires, il est évident qu'il y a environ 5 frameworks "top" ici et tout le monde aime celui qu'ils ont choisi donc ils lui donneront des accessoires.

L'aspect vitesse est hors de propos de nos jours, vraiment. Les deux seuls facteurs qui devraient être pris en compte sont a) voulez-vous vraiment tout réécrire et b) comment se déroulera la transition pour les développeurs React et comment apprendra le fw gagnant pour les nouveaux développeurs.

Il existe des couches préact-compat, inferno-compat ... pour une transition facile mais les performances en souffriront. D'un autre côté, cela rendra la transition gracieuse au fil du temps, tout ne doit pas être réécrit en même temps. Du point de vue professionnel, c'est une évidence. Du point de vue communautaire et du futur, cela ne fait aucune différence.

Maintenant, le DX est là où tout se trouve. Toute personne expérimentée dans les fw réactifs ne devrait avoir aucun problème à passer à un nouveau fw simplement parce que les concepts sont les mêmes, seule la syntaxe diffère. Mais le novice, c'est celui qui compte. Comme il est difficile / facile d'être productif dans un nouveau fw. Il est difficile / facile de lire et de comprendre le code existant. Et cela repose uniquement sur a) une bonne documentation et b) la communauté (forums, SO, chatrooms, blogs ..).

Je ne dirai pas quel FW je préférerais car, comme je l'ai dit, je ne suis pas un gars de WP. Mais je voulais donner mon 2c pour garder la tête froide quand il s'agit d'une décision aussi importante qui influencera des milliers de développeurs à travers le monde.

@ntwb : Je n'ai pas supprimé mon commentaire mais je pense que la suppression des commentaires, même ceux des fans boys, est une sorte de censure.

Pourquoi:

Si votre commentaire a été ajouté après le # 2733 (commentaire) et que tout ce que vous avez dit est "Je vote pour XYZ" ou un texte à cet effet, vos commentaires ont de très grandes chances d'être supprimés, les futurs commentaires du même acabit seront également supprimés .

Je vois beaucoup de commentaires de fans boys ci-dessus. Pourquoi restent-ils?
Cela semble un double standard.

Angulaire, c'est un choix clair. Je pense que Roy et Meligy font des points fantastiques et les soutiennent à 100%. WordPress entre dans le domaine de l'entreprise non seulement en cours d'utilisation, mais également en termes de méthodologie de son développement.

Je vais lier une source amusante: https://vuejs.org/v2/guide/comparison.html et en particulier: "... la complexité d'Angular est en grande partie due à son objectif de conception de ne cibler que les grands et complexes applications...". Cette simple déclaration frappe le clou sur la tête. WordPress est, et sa direction future continuera d'être, une application complexe et robuste.

@ChrisCinelli Simplement parce que c'est à ce moment-là que nous avons demandé aux gens de s'abstenir de dire "je vote pour xyz", je comprends cependant d'où vous venez mais je pense que supprimer ces commentaires serait de mauvaise forme, je n'aime pas le fait que je devais supprimer l'un d'entre eux

Je n'ai pas apporté cela plus tôt parce que je ne voulais pas attaquer des frameworks que je n'ai pas recommandés (après avoir recommandé Angular ci-dessus), mais juste pour être complet, il y a quelque chose qui doit être effacé avec Preact et d'autres bibliothèques de type React . Je vais le mettre ici, et c'est à WordPress de décider si c'est un problème.

Ce qui suit est une citation d' un article rédigé par un mandataire en brevets / propriété intellectuelle sous licence React, (le surlignage en gras est copié à partir de la source):

J'ai eu beaucoup de "bien, alors utilisons tous [un autre cadre ici]." Attends une seconde. Si les brevets Facebook couvrent React (différent, composant, etc.), ces brevets couvrent probablement Preact / Vue / et al.

Mais React vous accorde un brevet! Avec un cadre alternatif, vous êtes un contrefacteur dès le premier jour. Tout dépend de la question de savoir si Facebook a des brevets et de son désir de les appliquer, mais si vous voulez faire la guerre au nième degré, une alternative à React est plus risquée .

Maintenant, si ma compréhension est correcte, WordPress ne quitte pas React parce qu'il s'inquiète de la licence elle-même, mais seulement de devoir transmettre cette licence à ses utilisateurs, et donc d'apporter la confusion et la nécessité de défendre la décision à lui-même.

En ce qui concerne une alternative à React, il pourrait y avoir moins à défendre si la licence alternative est permissive, mais il pourrait aussi y avoir une certaine confusion sur WordPress.

C'est à WordPress de décider s'il s'agit ou non de quelque chose à craindre.

@ChrisCinelli merci pour vos critiques constructives. Je l'accueille les mains ouvertes.

En tant qu'ingénieur, je sais que le coût et le temps sont en tête de liste. Mais voici le truc. Ce n'est pas un projet d'une entreprise particulière. Les objectifs ici sont différents.

Le but est de trouver un JS FW qui soit bon pour la communauté. Gutenberg n'a pas encore lancé. Si cela fonctionne, Preact aurait été clairement le gagnant.

Pour le moment, nous devons nous occuper de ceci:

• JS FW est facile à adopter pour l'ensemble de la communauté
• JS FW que nous choisissons doit avoir sa propre communauté et son propre écosystème
• Une expérience éprouvée avec un logiciel de production FOSS basé sur PHP est un plus. Vue + Laravel
• Choisir JS FW en fonction de ses mérites et pas seulement parce qu'il est plus facile de migrer vers

En 11 ans que j'ai passé avec WordPress, et qu'en tant que contributeur principal régulier, je pense que choisir Preact créerait beaucoup de désordre. La courbe d'apprentissage est déjà énorme pour les développeurs intermédiaires / nouveaux.

Les mettre à travers le désordre de la compatibilité Preact-React dès le début de cette nouvelle phase d'amélioration de WordPress peut les amener à quitter la communauté WordPress et à apprendre autre chose avec la courbe d'apprentissage similaire. (_HINT_: Laravel + Vue au lieu de WordPress + Preact + React) Et BTW oubliez-vous que c'est ce qui se passe avec Drupal 8?

Veuillez ne pas supprimer les commentaires civils. Il existe manifestement un besoin ou un désir impérieux d'exprimer une opinion sur cette question. Je vois cela comme une bonne chose car les gens disent qu'ils se soucient de WordPress et qu'ils veulent être entendus. Rappelez-vous que la communauté WordPress, pas seulement ses développeurs, a été dirigée vers Github pour donner son avis. Si nous ne pouvons vraiment, vraiment pas tolérer les commentaires +1, ajoutez un décompte en haut qui préserve les noms d'utilisateur.

Si vous recherchez simplement une discussion raisonnée, alors beaucoup de commentaires «Je vote pour X, Y ou Z» peuvent sembler du bruit, mais il y a un modèle clair qui émerge des personnes soutenant Vue.js. Je pense que nous avons une centaine ou quelques centaines de personnes qui contribueront au code de Gutenberg, mais des dizaines de milliers qui écriront des plugins et des thèmes qui interagissent avec lui. Le succès de Gutenberg ne sera pas seulement l'expérience de l'utilisateur final, mais aussi l'expérience des développeurs. Ce n'est pas la seule chose, mais une chose importante qui fait le succès de WordPress est qu'il est facilement extensible.

Bien que je n'ai pas de cadre spécifique à l'esprit, je dirais qu'une chose que nous devons garder à l'esprit est que la prise en charge des navigateurs commence à se mettre en place avec les composants Web, un cadre qui utilise des composants Web ou au moins leurs propres composants construits comme ils seraient à l'épreuve du temps. Il existe également des polyfills pour apporter des composants Web aux navigateurs qui ne le prennent pas en charge.

J'ai été mentionné plus tôt et je suis juste venu ici pour désactiver les notifications, mais je vais peser un peu.

Si vous créez une application d'une seule page à partir de zéro, le temps presse et que vous voulez un cadre bien pris en charge, documenté et testable, j'ai beaucoup d'expériences concrètes qui montrent qu'il est beaucoup moins coûteux en temps et en trésor de allez avec Ember.

Si vous créez plus d'une PWA ou si vous déposez des composants dans une page rendue par le serveur, Ember est un mauvais choix, et je peux voir pourquoi quelque chose comme Vue serait attrayant.

J'ajouterai que d'un côté des choses axé sur les conventions, j'ai créé quelques PWA avec> 90 scores de phare en utilisant Ember.

Sur notre dernier projet où nous devions le faire, le processus a pris moins d'une heure pour obtenir ce score phare et déployer l'application avec le rendu côté serveur activé.

Le cache SSR et service worker nécessaire pour obtenir des scores de phare élevés peut être un processus très délicat.
Avec Ember, ce processus est très simple et ne nécessite que l'installation de quelques addons bien documentés et maintenus (pour la plupart des applications).
D'après mon expérience, Preact est livré avec ces deux fonctionnalités prêtes à l'emploi dans Preact CLI, mais il existe des conventions (P) React populaires qui peuvent casser les résultats SSR.
Avec Vue, la documentation officielle recommande d'utiliser Nuxt.js ou de suivre le guide SSR complet ; tous deux introduisent plus de modèles qui doivent être suivis au-delà de la documentation de base de Vue.

Ne dites rien à personne, mais attendons de supprimer les commentaires sur des problèmes à moins qu'ils ne soient grossiers ou abusifs. J'obtiens totalement les gens qui veulent aider et concentrer la conversation, mais nous ne devrions pas entrer dans la spirale de la suppression des commentaires.

Je ne suis pas sûr de ce qui est "bien documenté" à propos d'Ember par rapport à VueJS @rtablada .

Personnellement, j'aurais un problème pour démarrer Ember par rapport à Vue ou même à React.

@ahmadawais Tout le monde oublie que cette décision aura un grand impact et que vous voudrez quand même changer de cadre dans quelques années. Vous aimeriez donc utiliser la bonté du cadre moderne mais ne pas y être lié pour la vie et la mort. Cela semble impossible? Ce n'est pas!

Il y a quelque temps, j'ai eu un problème similaire et après des recherches et des tentatives, je trouve une solution qui tente de relier l'eau au feu. En quelques mots - les éléments personnalisés du composant Web, la technologie d'emballage que vous aimez (par exemple, Vue, React, Angular) et l'exposition de l'API DOM standard.

Dans une telle solution, vous aurez plusieurs composants et chacun d'eux a:

• cadre que vous aimez (mais bien sûr de préférence un seul)
• API DOM standard que d'autres composants peuvent facilement utiliser. Vous pouvez même le manipuler via JavaScipt simple

Comme je travaillais avec Vue à ce moment-là, j'ai écrit l'adaptateur de Custom Element pour Vue - https://github.com/karol-f/vue-custom-element - vous avez donc une compatibilité supérieure (par exemple, l'événement $ emit send standard DOM de Vue qui peut être capturé via JS ou par exemple React / Angular) et compatibilité IE9 +.

Je recommande de regarder une telle solution comme vous:

• sera à l'épreuve du temps
• ne sera lié à aucun cadre que vous choisissez aujourd'hui
• vos utilisateurs verront les éléments HTML standard et pourront interagir avec eux avec le framework qu'ils aiment ou même avec JS ordinaire
• Il n'y aura pas d'initialisation manuelle de Vue car le navigateur vous le dira et le composant auto-init s'il est sur la page (vous pouvez même charger le composant paresseux de cette manière)

et beaucoup plus.

Une telle solution n'est pas liée à Vue - vous pouvez utiliser n'importe quel autre framework que vous aimez. Les éléments personnalisés de Web Component sont également des fonctionnalités de navigateur standard et ne disparaîtront nulle part!

Cordialement!

Je pense que nous avons une centaine ou quelques centaines de personnes qui contribueront au code de Gutenberg, mais des dizaines de milliers qui écriront des plugins et des thèmes qui interagissent avec lui. Le succès de Gutenberg ne sera pas seulement l'expérience de l'utilisateur final, mais aussi l'expérience des développeurs. Ce n'est pas la seule chose, mais une chose importante qui fait le succès de WordPress est qu'il est facilement extensible.

Citant le commentaire ci-dessus de @dmccan car c'est un point si important pour le support de Vue.

WordPress a démocratisé plus que la simple publication. Je me demande combien de carrières et d'entreprises technologiques réussies ont été lancées en raison de l'accessibilité de WordPress. Le mien, bien sûr.

Je vais jeter mon chapeau en faveur de VueJS. Le meetup JavaScript local ici est codirigé par l'un des membres de l'équipe de base de VueJS et il semble que ce soit celui avec lequel les personnes qui y ont participé pourraient s'intégrer beaucoup plus rapidement que les autres. Mon expérience précédente était avec AngularJS et j'ai trouvé que VueJS était incroyablement plus facile à apprendre et commençait simplement à coder même si je partais de zéro.

Je vois que certaines personnes parlent d'entreprise et donc Angular, mais bien que WordPress puisse avoir besoin d'un peu d'amour dans ce domaine, je pense que la décision devrait être basée sur, la fonctionnalité et autres, la facilité d'intégration des développeurs. Avec les discussions que nous avons vues sur les méta-boîtes et ainsi de suite, amener les auteurs de plug-ins à «Gutenberg-ify» leur travail au lieu de simplement abandonner si / quand l'éditeur classique disparaît.

Quelques autres points à mentionner à propos de Vue.js : (Juste des pensées personnelles, d'autres bibliothèques, FW et options sont appréciées et ont à coup sûr leurs propres fonctionnalités et avantages uniques)

• PRO Il ne nécessite pas nécessairement un transpilateur ou de forcer son utilisation et peut s'exécuter directement sur le Web comme le peut

Cela aiderait étonnamment les développeurs de plugins à s'intégrer à l'interface utilisateur de Wordpress. Ils peuvent attacher une nouvelle instance de vue à n'importe quelle partie de la page en tant que widget. De plus, un grand projet Wordpress peut progressivement adopter avec Vue.js sans avoir besoin d'énormes changements de rupture dans la base de code, car vue ne suppose pas comment il va être utilisé. Je pense que c'est la clé du succès pour laquelle Laravel / Vue est si populaire et fonctionne bien ensemble :)

• PRO JSX et css-in-js pris en charge également!

Cela peut faciliter la migration des projets WordPress actuels avec le code React / JSX vers vue.js avec moins d'exigences de changement. (il existe même un plugin babel: babel-plugin-transform-react-to-vue )

• FACT Vue tout comme Preact et contrairement à Angular / React n'est pas un projet open source appartenant à une grande entreprise comme Google ou Facebook.

Ce serait quelque chose de critique pour un projet ÉNORME comme Wordpress pour échapper à un blocage potentiel d'un fournisseur. Si un projet Open Source n'appartient pas à une entreprise, quelqu'un doit le démarrer (donc "Dépendance de personne clé" n'a pas de sens pour être mentionné comme CON ).

Je vote pour VueJS.
Non pas parce que je sais quoi que ce soit à ce sujet, mais parce que je n'ai aucune idée de la manière dont il est prononcé en anglais. Cependant, j'ai utilisé Joomla pendant des années et je l'ai prononcé mal tout le temps.

Blague à part.
Peu de gens ici discutent du meilleur cadre pour prendre en charge les anciennes métaboxes et les champs personnalisés. React était très mauvais dans ce domaine, comme nous le savons maintenant.

Maintenant, juste pour vous désabonner de ce problème.

Afin de concentrer la discussion, j'ai créé un problème de tâche ici: https://github.com/WordPress/gutenberg/issues/2741

Je suggérerais Vue, juste parce que Laravel. De nombreux utilisateurs de WordPress mécontents du cours qu'il a suivi ou qu'il prend encore, sont passés à l'utilisation de Laravel comme principal cadre de CMS, tout en gardant WP comme deuxième choix. Preact n'est qu'un clone et une couche de compatibilité massive, un peu ce que Novell DOS était pour MS DOS, PC DOS et vice-versa.

cu, w0lf.

Vue.js jusqu'au bout!

Vous devriez certainement regarder Hyperapp .
Avantages

1. Il est très similaire à l'architecture Elm (Model, View, Update).
2. Il a des Redux intégrés comme des Reducers appelés "actions" (appelés pour mettre à jour le modèle et en retour View).
3. Utilise JSX
4. Encourage les conceptions de «programmation fonctionnelle»
5. C'est 1kb donc c'est facile à charger et facile à comprendre.

Les inconvénients

1. Il est encore nouveau, tout comme l'écosystème. Mais vous pouvez l'influencer et y contribuer.
2. Il peut y avoir des problèmes qui n'ont pas encore été découverts.

Les principes des blocs de Gutenberg s'accordent parfaitement avec ceux des composants Web . C'est de bas niveau, indépendant du framework et une norme émergente (avec des polyfills matures et testés) - la solution idéale pour WordPress.

Voir aussi: Polymère - Composants Web avec du sucre.

Vue est une option fantastique, et voici les raisons pour lesquelles je le crois:

J'ai commencé à regarder Vue au début de 2016. Je l'ai adoré et je voulais déterminer s'il serait un jour "en demande" ou si sa croissance était quelque chose à écrire. À l'époque, il compte 16 000 étoiles sur Github. C'était cool et tout, mais les gens ne s'étaient pas vraiment adaptés au milieu de toute la merde Angular vs React.

J'ai fini par perdre toutes mes données et recommencer le 17 septembre 2016. Il y a exactement un an, aujourd'hui. ( Voici mon ensemble de données actuel. )

Au cours de l'année écoulée, j'ai vu la popularité de Vue grandir (en termes de mentions sur Internet et de suivi des étoiles Github) à un taux de rupture d'enregistrement. Vue a accumulé 40000 étoiles en 365 jours. C'est une moyenne de 109 par jour. En comparaison, le bien-aimé _React_ du monde est passé de 49 000 à 75 000 dans le même laps de temps. (71 par jour) Vue dépassera React dans les prochains mois, en termes de notes d'utilisateurs.

Alors que tout le monde parlait de la croissance de React comme étant la plus incroyable de tous les temps, ils ne savaient pas que Vue était le véritable tenant du titre. Ils ne savaient pas que Vue grandissait parce que les gens l'aimaient vraiment en tant qu'outil, plutôt qu'à cause d'un soutien célèbre (Facebook).

Vue fait partie de la liste des dépôts tendance de Github chaque jour depuis plus d'un an maintenant. 99% des jours, il est au-dessus de React. 10% des jours, React ne fait pas la coupe.

Tout cela crie "utilisez Vue parce qu'il a connu une plus grande croissance de popularité!" Mais ce que je veux dire, c'est que Vue a grandi parce que les gens l'aiment vraiment parce que c'est un outil formidable, intuitif et puissant (souvent présenté à tort comme «idéal pour les petites applications») pour les applications de toutes tailles. Mais pas seulement un outil. Vue est un écosystème. Il vient également avec une communauté de soutien massive.

Puis-je ajouter ... les fichiers .vue sont géniaux. De nombreux outils sont en cours de construction pour gérer le style dans React car il y a apparemment quelque chose qui ne va pas avec les modules CSS et le fait d'avoir vos styles dans un fichier externe. (Idk ...) Mais Vue n'a pas ce problème. Vue a des instructions de contrôle intégrées à la syntaxe, et (depuis que j'ai vu les commentaires sur les éléments personnalisés ci-dessus) ne joue pas seulement bien avec les éléments personnalisés ... C'est une bibliothèque / un cadre pour les éléments personnalisés logiques.

Preact est génial. Honnêtement, je viens de commencer un autre projet avec aujourd'hui. Mais quand je regarde Preact, je vois un React hors marque. Il n'a pas été conçu pour être innovant ou pour faire progresser la façon dont nous créons des logiciels Web. Il a été créé pour ressembler et agir comme un outil préexistant, mais pour offrir de meilleures performances.

Ce sont mes deux centimes. Maintenant je suis fauché.

J'espère que votre décision finale vous rendra heureux et fournira une excellente base pour l'avenir de vos produits.

@ahmadawais :

• Le temps de mise sur le marché est important pour les projets d'entreprise et open source. Vous pouvez trouver des exemples de projets qui n'ont jamais été livrés car ils ont pris trop de temps et sont devenus obsolètes avant leur expédition. Quelques projets ont fini par être abandonnés pendant les travaux vers une version majeure.
• S'opposer à Preact signifie "nous avons fait une erreur avec React pour des raisons autres que la licence". Je pense qu'avec "La courbe d'apprentissage est déjà énorme pour les développeurs intermédiaires / nouveaux", vous vouliez dire que les développeurs de wordpress étaient déjà perdus avec React. Cela ne me surprend pas. Mais il semble difficile de croire que Vue, même s'il est moins verbeux, résoudra les problèmes de courbe d'apprentissage. L'ancien moteur PHP WP et tout framework javascript d'application à page unique sont très différents. Vue et React sont très similaires les uns avec les autres.
  Je ne sais pas pourquoi vous voyez une concurrence entre Wordpress et Laravel. Je peux être naïf ici. Je connais très peu l'histoire de Drupal 8.
  De mon point de vue, Wordpress est un CMS et il attire les développeurs en raison de sa large base d'utilisateurs non techniques et des fonctionnalités déjà intégrées. Il existe de nombreux modèles et les développeurs peuvent très rapidement créer un nouveau site personnalisable par un non-développeur.
  Laravel est un framework PHP qui, pour autant que je sache, ne vous donne pas beaucoup des fonctionnalités d'un CMS. Un développeur le choisira car il a besoin de plus de liberté.
• Je ne sais pas comment avoir quelques succès avec Vue + Laravel signifie également "Vue est bon pour Wordpress". Je pense qu'il y a très peu de synergie intrinsèque entre PHP et n'importe quel framework JS. Je suis tout à fait d'accord qu'il est important de trouver un cadre qui soit bon pour la communauté. Si la plupart de la communauté de développeurs actuelle dont dépend wordpress est familier avec Vue et qu'ils l'aiment, cela a un poids important dans votre décision finale.

Du point de vue de l'ingénierie, je pense que Marko JS et Vue sont des frameworks plus récents. Ils ont beaucoup appris de React et ont pu supprimer une partie de la verbosité. En ce sens, Marko semble supprimer encore plus de code standard que Vue. En particulier, Marko garde un code cohésif qu'il est bon de garder au même endroit et de laisser en HTML ce à quoi le HTML est bon et en Javascript à quoi sert Javascript. Et il est également 10 fois plus rapide. Donc, à part le fait que récemment Vue a beaucoup de fans, je ne vois pas beaucoup de raisons de préférer Vue à Marko.

Désolé mais la syntaxe et la configuration de Marko sont horribles par rapport à VueJS. En termes de performances, je n'ai vu aucune source où MarkoJS est plus rapide de manière significative sans ajouter de temps pour comprendre comment cela fonctionne.

La syntaxe de la version qui a introduit la syntaxe actuelle de Marko a été extrêmement bien accueillie par nos utilisateurs.

Nous avons beaucoup réfléchi à la syntaxe Marko pour nous assurer qu'elle est familière aux développeurs qui comprennent HTML et JS et nous voulions qu'elle soit aussi simple et puissante que possible avec un minimum de passe-partout. Je pense que vous constaterez qu'avec toute comparaison côte à côte, le modèle Marko nécessitera moins de code (ce qui est excellent pour la lisibilité et la maintenabilité).

Voici un document que j'ai rapidement assemblé pour que vous puissiez voir un aperçu des différences entre la syntaxe Marko et la syntaxe Vue:

Syntaxe: Marko vs Vue

Je l'ai lié plus tôt, mais pour une comparaison plus approfondie entre Marko et Vue (et React), veuillez consulter:

Meetup: Construire l'interface utilisateur - une comparaison de React, Vue et Marko (du créateur Marko) - Vidéo | Diapositives

En ce qui concerne les performances, nous avons quelques repères que vous pouvez consulter: https://github.com/marko-js/isomorphic-ui-benchmarks

Voici un aperçu rapide des benchmarks avec Marko et Vue activés:

Performances de rendu côté serveur

_Node.js ( v8.4.0 ) _

Running "search-results"...

Running benchmark "marko"...
marko x 5,180 ops/sec ±2.09% (87 runs sampled)

Running benchmark "vue"...
vue x 135 ops/sec ±3.81% (68 runs sampled)

Fastest is marko

Running "color-picker"...

Running benchmark "marko"...
marko x 10,206 ops/sec ±0.72% (87 runs sampled)

Running benchmark "vue"...
vue x 1,664 ops/sec ±5.20% (66 runs sampled)

Fastest is marko

Performances côté client

_Chrome Version 63.0.3218.0 (version officielle) canary (64 bits) _

Running "search-results"...
Running benchmark "marko"...
marko x 351 ops/sec ±1.18% (58 runs sampled)
Running benchmark "vue"...
vue x 206 ops/sec ±1.61% (57 runs sampled)
Fastest is marko

Running "color-picker"...
Running benchmark "marko"...
marko x 7,516 ops/sec ±2.90% (41 runs sampled)
Running benchmark "vue"...
vue x 4,593 ops/sec ±3.03% (54 runs sampled)
Fastest is marko

Ce sont les repères que nous avons créés pour Marko.js, alors prenez évidemment ces résultats avec un grain de sel, mais nous nous sommes efforcés d'être justes.

Aussi, je voulais juste ajouter quelques commentaires supplémentaires concernant Marko.js et la facilité d'utilisation:

Marko a toujours cherché à avoir l'intégration la plus simple avec Node.js. Après avoir installé le package marko via npm, voici tout le code nécessaire pour rendre un modèle dans un flux de réponse HTTP:

require('marko/node-require'); // require .marko files!

const http = require('http');
const template = require('./template');

http.createServer().on('request', (req, res) => {
  template.render({
    name: 'Frank',
    count: 30,
    colors: ['red', 'green', 'blue']
  }, res);
}).listen(8080);

Je pense que c'est aussi simple que jamais.

Marko fonctionne également avec les bundles de modules JavaScript populaires: http://markojs.com/docs/bundler-integrations-overview/

Pour rendre un composant d'interface utilisateur Marko de niveau supérieur dans le DOM, voici tout ce qui est nécessaire:

require('./fancy-button')                  // Import the Marko UI component
  .renderSync({ label: 'Click me' })   // Render the button with the provided input
  .appendTo(document.body);         // Mount the UI component to the DOM

@ patrick-steele-idem Selon http://www.stefankrause.net/wp/?p=431 benchmarks, markoJs
est aussi performant que Vue et al.

Ainsi, nous pouvons conclure que dans les scripts côté client en général, Markojs et Vue sont également performants.

Bien sûr, la référence, j'ai lié, n'inclut pas SSR. Je ne ferai donc aucun commentaire à ce sujet.

Je vote pour Vue. jQuery est déjà presque indispensable pour utiliser WordPress. Les personnes familiarisées avec jQuery doivent se sentir familières avec la syntaxe Vue. Son idéologie sur le DOM n'est pas si extrême que quelque chose comme Angular. Il repose sur le principe de WordPress sur la facilité pour l'utilisateur.

Comme je l'ai suggéré il y a environ deux ans pour Calypso , Mithril.js utilisant l'API HyperScript serait un bon choix pour remplacer React. Il dispose d'une licence MIT standard.

Un petit investissement dans de nouveaux outils pour effectuer au moins une partie du gros du travail automatiquement pour la conversion de React vers une autre bibliothèque vdom peut être rentable en heures de développeur économisées - comme mentionné dans ce numéro comme une suggestion à Automattic de faire à l'avance pour se couvrir son pari sur React.

Même sans considérer les bibliothèques non-vdom, il y a plus de 25 bibliothèques vdom (par exemple inferno.js, maquette, etc.) qui pourraient être considérées - comme dans cette liste que j'ai préparée

Voici quelques raisons techniques pour lesquelles Mithril.js ou d'autres vdoms mettant l'accent (ou au moins supportant) l'API HyperScript sont les meilleurs choix.

Personnellement, je pense que les approches de modélisation pour créer des interfaces utilisateur JavaScript telles que JSX de React ou la propre approche de modélisation d'Angular ou les systèmes de modélisation de nombreux autres systèmes d'interface utilisateur, y compris Vue, sont obsolètes. Pourquoi? Les préférences et les «meilleures pratiques» pour l'écriture d'applications Web basées sur des modèles HTML générées côté serveur à l'aide de feuilles de style CSS complexes (comme pour les plugins WordPress précédents) deviennent les «pires pratiques» pour écrire des applications Web d'une seule page. Les besoins techniques pour l'écriture d'applications modernes complexes côté client d'une seule page sont différents de ceux du code principalement serveur en raison de la complexité croissante du code côté client. En bref, les anciennes «meilleures pratiques» d'utilisation de modèles et de feuilles de style complexes en cascade ne sont tout simplement pas à l'échelle, ce qui rend le code difficile à maintenir.

Quelle est l'alternative émergente? Les applications Web modernes peuvent utiliser Mithril + Tachyons + JavaScript / TypeScript pour écrire des composants dans des fichiers uniques où tout le code est juste JavaScript / TypeScript. De telles applications n'ont pas besoin d'être partiellement écrites en CSS ou dans une variante non standard de HTML qui réimplémente une partie d'un langage de programmation (mal). (Eh bien, il peut y avoir un tout petit peu de CSS personnalisé nécessaire en plus de Tachyons ou de bibliothèques similaires, mais très peu.)

Voici un exemple de terrain de jeu de codage que j'ai écrit de cette façon avec plusieurs exemples qui utilisent cette approche.

Ainsi, en écrivant des interfaces utilisateur en utilisant HyperScript (plus une bibliothèque vdom), vous pouvez potentiellement (avec un peu de travail) remplacer un backend comme Mithril par presque n'importe quel autre vdom ou même une solution non-vdom. Ainsi, lorsque j'ai le choix, choisir d'utiliser l'API HyperScript est un moyen d'atténuer les risques liés aux bibliothèques sous-jacentes ayant des bogues ou des problèmes de licence.

En utilisant Tachyons ou des bibliothèques similaires, j'atténue le risque de fichiers CSS non maintenables à mesure que l'application se développe.

Certes, je sais que de nombreux développeurs Web ont grandi en peaufinant le HTML et adorent les modèles à l'aspect HTML. Donc, ils aiment JSX ou autre et sont heureux d'ignorer à quel point il est difficile de refactoriser de tels éléments non codés au milieu de leurs applications ou de les valider. Certes, certains IDE s'améliorent dans la refactorisation des modèles JSX. Mais je suis arrivé au développement Web à partir du bureau et du développement intégré en travaillant avec des systèmes où vous génériez (généralement) des interfaces utilisateur directement à partir du code (par exemple en utilisant Swing, Tk, wxWidgets, etc.). J'aime l'idée que les outils standards peuvent m'aider à refactoriser tout le code sur lequel je travaille et à détecter de nombreuses incohérences.

En supposant que tous les frameworks de l'exécution ici n'ont pas de différences visibles pour l'utilisateur en raison de leur vitesse sur le navigateur de leur choix, nous pouvons arrêter d'utiliser les performances du frontend comme métrique pour évaluer quel framework est le meilleur choix.

Mais si nous utilisons le rendu côté serveur, nous devons examiner attentivement les performances SSR. Calypso semble vouloir avoir la RSS. Et en cas de succès, Calypso exécutera un jour la plupart des sites sur wordpress.com.

Une entreprise paie le processeur sur les serveurs, pas le processeur sur les navigateurs. Donc, du point de vue des coûts, le temps de rendu 10 fois plus rapide de Marko signifie probablement que le même trafic qui dépasse 10 serveurs maximum avec MarkoJS, prendra en fait au moins 100 serveurs exécutant Vue.

Si Wordpress peut ignorer cela, je viendrai volontiers travailler pour l'entreprise et toucherai 10x le salaire du marché et utiliserai Vue qui, au fait, je pense que c'est une bonne alternative à React =)

Plus le cadre est léger - c'est-à-dire moins il offre de fonctionnalités hors de la boîte - plus il fonctionnera rapidement. C'est pathétiquement évident. C'est une chose de comparer les performances de divers algorithmes, mais lorsque le facteur le plus important est la quantité d'autres «trucs» exécutés, vous n'avez pas besoin d'écrire des tests.

https://hueniverse.com/performance-at-rest-75bb8fff143

@ahmadawais Angular core team ici - nous sommes en cours sur un grand nombre de travaux intéressants liés au développement de style CMS / Widget, y compris l'investissement dans le support des éléments personnalisés (qui, pour mon argent, est le futur pari intelligent pour la construction de plates-formes)

Plutôt que d'encombrer davantage le fil, nous serions heureux de discuter avec vous tous hors ligne, si cela vous intéresse. Envoyez-moi une ligne à robwormald à google dot com. Bonne chance à ce sujet, je ne vous envie pas de passer cet appel ;-)

J'ai créé un simple sondage ici qui peut être utilisé pour avoir un aperçu de ce que les gens veulent.

travaille actuellement sur la page de résultats et authentifie dessus. (nouveau sur Firebase)

PS. a pris environ 1 heure pour le faire en utilisant Vue 🖖

@vinayakkulkarni Que diriez-vous d'ajouter Mithril.js à votre sondage?

@pdfernhout : 👍

Terminé. J'ai ajouté MithrilJS à la liste.

• [x] VueJS
• [x] Angulaire
• [x] Préagir
• [x] Braise
• [x] Marko
• [x] Inferno
• [x] Aurelia
• [x] Mitrhil

Voyons ce que les gens décident.
PS. il y avait aussi un sondage Twitter de @ahmadawais .

Salut. Je suis un mainteneur principal de Drupal. Comme @ivanjaros l'a mentionné dans un commentaire précédent, nous évaluons également Preact, Vue, ou autre chose, pour certains bits à venir de l'interface utilisateur d'administration de Drupal. Nous pourrions décider de quelque chose de différent de ce que vous choisissez, mais ce que vous choisissez sera certainement au moins un facteur à prendre en compte dans notre choix.

J'ai ouvert ces deux numéros Drupal jusqu'à présent, et d'autres seront à venir. Il suffit de les renvoyer ici au cas où ces questions / discussions vous seraient utiles.

• composants renvoyant plusieurs nœuds racine
• slots vs accessoires vnode

Notez que j'aime toujours beaucoup Vue, malgré ces deux problèmes. Ce sont peut-être des choses avec lesquelles nous sommes d'accord pour vivre, afin d'obtenir tous les autres avantages de Vue.

En tant qu'auteur de Vue, j'éviterai de faire des commentaires sur le cadre à choisir ici car je suis évidemment biaisé; mais comme j'ai vu l'affirmation selon laquelle "Marko est 10 fois plus rapide que Vue" lancée à plusieurs reprises, je pense que cela mérite quelques éclaircissements. Je ne veux pas non plus faire dérailler la discussion en un débat technique, alors j'ai noté quelques réflexions dans cet essentiel pour ceux qui sont intéressés.

@ michaelbdavidson7 concernant les problèmes financiers: je travaille sur Vue à plein temps depuis plus d'un an et demi maintenant et le support Patreon est vraiment stable. Plutôt que de spéculer sur les fluctuations des engagements de Patreon, vous pouvez vérifier l'activité de validation de Vue pour juger par vous-même. De plus: avoir un canal de contribution financière ouvert signifie que WP / Automattic peut facilement assurer la durabilité de Vue en devenant un sponsor majeur (Matt lui-même est déjà un sponsor personnel!) - qui correspond en fait aux intérêts des deux projets.

Je vote Vuejs

@ tungbt94 Pourquoi?

Certainement VueJS

La plus grande question, pourquoi la réaction a été choisie avant cette question de brevet. S'il n'y avait pas de brevet, utiliseriez-vous encore react? Beaucoup de points soulevés sur le fait de NE PAS choisir préaction sont les mêmes que de ne pas choisir de réagir.

Mon vote est avec Preact

Comme je n'ai pas beaucoup d'expérience avec autre chose que React, je ne me pencherai pas sur le cadre à choisir.
Cependant, je pense que l'argument de la «grande communauté» peut avoir moins d'importance. Pourquoi? parce que lorsque Automattic décidera d'un cadre, ce travail agricole obtiendra des milliers de nouveaux utilisateurs. Et si je connais correctement la communauté WP, beaucoup d'entre eux commenceront également à contribuer à ce cadre et la popularité augmentera.

Compte tenu de la situation actuelle de Gutenberg et Calypso, je pense toujours que Preact est le meilleur choix d'ingénierie.

Cependant, si vous avez toujours envie de brûler des ponts avec une quelconque ressemblance avec React ou si vous deviez partir de zéro, je pense toujours que MarkoJs est le meilleur choix. Je pense que le soutien de la communauté peut encore être une préoccupation.

En supposant que les étoiles Github sont en quelque sorte corrélées avec la communauté, Vue est toujours 10x par rapport à MarkoJs, mais en regardant les graphiques, cela changera rapidement.

Vue grandit linéairement:

Mais MarkoJs semble être sur le point d'inflexion d'une croissance exponentielle:

@ patrick-steele-idem, l'auteur principal de MarkoJs , a toujours été super réactif sur https://gitter.im/marko-js/marko

Quand les gens choisissent finalement MarkoJs , mais vraiment n'importe quel type de communauté, j'ai envie de paraphraser la citation de JFK: "Ne demandez pas ce que la communauté peut faire pour vous - demandez ce que vous pouvez faire pour la communauté."

Personnellement, je voudrais féliciter @ahmadawais pour la création d'un seul problème qui a suscité un engagement significatif de la part de nombreux développeurs JS qui utilisent et prennent en charge les options de bibliothèque JS pertinentes.

Je soupçonne que ce problème a aidé à informer davantage de développeurs JS sur les évolutions de WordPress vers plus de développement basé sur JavaScript via Gutenberg que toute autre communication Gutenberg jusqu'à présent.

J'utilise AngularJS mais ce que je n'aime pas, c'est la mise à jour majeure à chaque fois, donc j'irai avec VueJS.

+1 pour Marko. Excellente bibliothèque que notre équipe utilise et dont elle a été très satisfaite. Rendu asynchrone, super rapide (rendu en chaîne dans le serveur et en vdom dans le navigateur), composants uniques ou multi-fichiers, et IMO la meilleure syntaxe de modèle.

S'il vous plaît prendre l » @WebReflection hyperHTML en compte.

J'aime angulaire

Je vote angulaire

Je choisis angulaire

juste anguleux

Je choisis angulaire

angulaire

Je vote angulaire

Je vote angulaire

Si vous aimez voter pour un framework, ce serait bien de connaître la raison exacte et comment cela aide Gutenberg.

Aux personnes qui viennent ici pour simplement dire "Je vote X", veuillez nous donner quelques raisons pour lesquelles nous devrions voter X aussi. «Je vote X» ne nous dit rien à part que vous aimez X.

Je choisis angulaire. Angular a de grands changements depuis la version2. Maintenant, il est complètement, bon - cadre fortement et largement utilisé - Comme il, comme ionique, n'étudiez pas rapidement, mais fortement.

Avec autant de spam "Je voteframework », github me dit.

J'exhorte les autres développeurs à bien voter pour votre choix de framework sur https://vinayakkulkarni.github.io/poll/ https://vinayakkulkarni.github.io/poll/ au lieu de simplement poster «Je vote…»;

En outre, une autre suggestion est de verrouiller cette conversation; la plupart des grands développeurs ont déjà eu leur mot à dire à ce sujet.

Le 18 septembre 2017, à 20 h 01, Mingyue [email protected] a écrit:

Je choisis angulaire. Angular a de grands changements depuis la version2. Maintenant, il est complètement, bon - cadre fortement et largement utilisé - Comme il, comme ionique, n'étudiez pas rapidement, mais fortement.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub https://github.com/WordPress/gutenberg/issues/2733#issuecomment-330241898 , ou désactivez le fil https://github.com/notifications/unsubscribe-auth/AS3FbT23DvVwTLGL61tmK7KtuwZeg- ucks5sjn7SgaJpZM4PYie9 .

merci @kidwm d' avoir mentionné _hyperHTML_, mais je suppose qu'il vaut mieux suivre leur direction:

Ne vous contentez pas de partager le framework JS que vous aimez, mais aussi pourquoi

alors laissez-moi essayer de faire ça ...

: zap: hyperHTML :

• PRO : Débutant et familier aux utilisateurs de P / React (au lieu de JSX, vous écrivez des littéraux de modèle)
• PRO : ultra rapide et sans VDOM; moins de consommation de mémoire (compatible avec les téléphones des marchés émergents)
• PRO : Ne nécessite aucun outil (nécessite des littéraux de modèle transpilés uniquement pour IE <11)
• PRO : entièrement basé sur les normes JS / DOM / HTML mais compatible avec TypeScript également
• PRO : s'adapte à moins de 5K (min-zippé) sans avoir besoin de polyfills ou de correctifs de navigateur supplémentaires
• PRO : couverture de code à 100% jusqu'aux bizarreries IE9
• PRO : partage la même API avec son homologue NodeJS ; 100% compatible avec le rendu côté serveur
• PRO : il peut adopter le DOM existant sans détruire les mises en page / nœuds SSR
• PRO : fonctionne mieux
• PRO : il peut faire ce que React , Vue.js , Polymer , Angular ou Marko font, et il gagne en termes de taille / bande passante / performances chacun d'eux

Maintenant, en fonction des métriques utilisées jusqu'à présent dans ce fil, le CONS

• INCONVÉNIENTS : même s'il a été testé au combat, entièrement couvert de tests et avec une API gelée, c'est un projet relativement jeune (mars 2017), il ne peut donc pas rivaliser en termes de popularité, d'adoption ou de nombre de contributeurs
• CONTRE : la communauté aide beaucoup et le projet grandit, mais le contributeur technique majeur jusqu'à présent, c'est moi. Je suis cependant engagé à 100% dans ce projet, et je suis prêt à le pousser autant que possible, et je discute avec quelques "_bigs_" de l'utilisation de _hyperHTML_ dans certains de leurs prochains grands projets (je ne spéculerai pas mais alors n'hésitez pas à ignorer cette dernière partie)

: dart: Je crois vraiment que l'avenir du Web est d'utiliser la plate-forme autant que possible, ce qui est définitivement bien meilleur qu'il y a 10 ans, et grâce aux spécifications modernes ECMAScript beaucoup plus facile à écrire, lire et maintenir. _hyperHTML_ représente "l'état actuel de l'art Web_" en termes de potentiels, tandis que tous les autres candidats de cette liste sont nés avant l'ère full-ES6.

Je comprends que la taille de la communauté, les contributeurs et les étoiles GitHub sont importants, mais je pense que les tests, la couverture du code entre navigateurs et le nombre de bogues doivent également être pris en compte, et je fais de mon mieux pour garder le nombre de _hyperHTML_ et d'amis proche de zéro (c'est en fait zéro pour le moment, à côté d'une discussion qui n'est pas un bug).

Dernier point, mais non des moindres, si personne ne donne une chance à de nouvelles solutions et ne juge que par les étoiles et le battage médiatique, les nouvelles solutions prendront plus de temps qu'elles ne devraient pour devenir plus populaires.

Bien sûr, j'ai parlé de ma dernière solution, mes considérations peuvent être considérées comme subjectives, mais spécialement ma dernière phrase sur le fait de donner une chance à de nouvelles solutions, était très générale, pas seulement à propos de mes bibliothèques: smiley:

Meilleures salutations

J'aime angulaire

doit être angulaire et google.

j'aime angulaire

Angular n'est qu'un vrai framework!

Je choisis Angular, pas AngularJs.

Seul angulaire est un vrai cadre!

Je commence à me douter, ces commentaires sont faits par des robots.

@OP : Veuillez verrouiller ce fil.

Je vote pour Angular (PAS AngularJS).

Angular est une plate-forme, l'équipe Google fait beaucoup de travail pour faciliter la progression du développement, y compris le composant, le module, le routeur, avec l'injection de dépendances, vous pouvez économiser beaucoup de travail pour organiser toutes les dépendances, avec angular-cli, vous pouvez économiser beaucoup de travail pour démarrer un tout nouveau projet, il vous suffit d'ouvrir la boîte et votre application est bien compilée avec aot, tree shaking et bien d'autres optimisations.

TypeScript est un autre excellent outil angulaire, il est fourni par MicroSoft, c'est-à-dire que toute la plate-forme angulaire est construite avec ts. Vous créez également votre application avec ts! C'est un excellent outil pour vous simplifier la vie lorsque la quantité de code devient de plus en plus grande, vous pouvez effectuer une refactorisation dans l'EDI (comme vscode) en un seul clic. La vérification de type statique vous permet de trouver les bogues le plus tôt possible. TS fournit également une bonne implémentation de la POO, vous pouvez organiser et réutiliser votre code d'une bien meilleure manière.

Il existe également de nombreux composants basés sur angular, comme meterial design2, primeng, et je veux vous recommander Jigsaw , qui est créé par notre équipe. Il est adopté par le produit Big Data de ZTE Chine. Il prend désormais en charge toutes les applications de ZTE.

Anglar est un excellent choix !!

À tous les bots: 🖕

Probablement quelqu'un a posté sur une communauté AngularJs. Je pense que les gens peuvent couper le fil s'ils ne veulent plus recevoir de messages.

Je pense qu'à terme, une conversation similaire sur ce sujet devra avoir lieu dans un endroit où il n'y a que des contributeurs WordPress.

Je voudrais partager certaines de mes réflexions sur cette question que j'ai pour la plupart déjà exprimées dans le groupe communautaire EmberJS slack, si vous avez 10 minutes pour lire la discussion là-bas, je le recommanderais: https://embercommunity.slackarchive.io / wb-marketing / page-2 / ts-1505456102000189 Il y en a beaucoup mais je vous recommande vivement de le vérifier pour avoir une compréhension nuancée de la discussion.

Mes principaux points dans cette discussion sont les suivants:

• En comparant un pic de 2 à 4 semaines d'implémentation de quelque chose dans le framework Ember par rapport à n'importe quelle autre bibliothèque, les autres bibliothèques ont tendance à gagner à court terme, mais Ember l'emporte sur tout projet à plus long terme.
• Lors de l'examen de la bibliothèque ou du cadre à utiliser, il est important de considérer non seulement la mise en œuvre technique, mais également les aspects «compétences générales» (taille de la communauté, engagement à soutenir LTS, implication de la communauté dans les décisions fondamentales du projet)
• Ember a fait ses preuves dans la fourniture d'améliorations majeures aux applications construites à l'aide de ember-cli «sous le capot», c'est-à-dire sans avoir besoin de mettre à jour le code de l'application. Il y a également eu des cas de mises à niveau mineures du code d'application (avec le code-mod inclus utilisant des éléments tels que ember-watson ), vous obtenez une augmentation significative des performances et de la productivité.

Je ne veux pas entrer trop dans les détails dans ce commentaire car je pourrais volontiers écrire un essai de 10 000 mots sur les points ci-dessus. Je voudrais cependant offrir mon temps à tous ceux qui voudraient discuter de cette question avec quelqu'un qui a un "état d'esprit Ember".

Si l'un des décideurs souhaite avoir un appel d'une heure avec moi pour poser des questions plus pointues sur l'écosystème Ember au sens large, je le ferai avec plaisir. Vous pouvez me contacter sur mon Twitter (DM ouverts) Je ne suis peut-être pas un membre de l'équipe principale, mais je crée des applications Ember depuis avant la version 1.0 et j'ai traversé tous les processus de mise à niveau avec diverses applications 👍

Je travaille pour "Mon eBay" sur eBay. Nous venons de publier notre première application d'une seule page . Nous avons apprécié chaque phase de développement avec MarkoJS. Comme moi, si vous aimez le paradigme de programmation de streaming de node, MarkoJS prend en charge le streaming et le rendu asynchrone. Autres faits que j'ai aimé à propos de MarkoJS:

• sa liaison efficace du comportement des composants d'interface utilisateur rendus sur le serveur et dans le navigateur.

• Délégation événementielle très efficace

• Sérialisation rapide de l'état du serveur au navigateur

@vinayakkulkarni Je pense que votre idée est bonne, mais le problème est que je peux laisser plus d'un vote en changeant de navigateur (je n'ai pas essayé avec le même navigateur).

Vous devriez probablement utiliser un sondage Twitter (mais il y en a déjà un) ou implémenter un système de connexion pour rendre les votes uniques.

Le rendu du serveur n'est pas pertinent pour la conversation ici. Node ne fera pas partie de la pile WordPress requise, donc la vitesse de rendu de ces frameworks dans Node n'est pas pertinente pour une décision.

Vue.js! regardez ce projet https://github.com/bstavroulakis/vue-wordpress-pwa

J'ai choisi Angular (pas AngularJS), il a la plus grande communauté, un écosystème stable et complet.

Angular est très lent et avec la v4 basée sur dactylographié, il est inutile pour le développement wordpress

Je choisis Angular par la maturité de la plateforme

Je voterais pour Vue parce que c'est plus facile à apprendre et parce que mon framework préféré Ember Js est trop gros pour le travail et Glimmer Js est encore trop récent. :-)

Le rendu du serveur n'est pas pertinent pour la conversation ici.

dans mon cas, je viens de mentionner une fonctionnalité que d'autres ont trouvé pertinente

Node ne fera pas partie de la pile WordPress requise

_hyperHTML_ peut récupérer n'importe quel contenu rendu côté serveur, y compris PHP. Je suis un ingénieur certifié Zend, et j'ai déjà travaillé avec des journalistes / éditeurs utilisant WordPress, mon indice n'était pas juste à l'improviste.

la vitesse de rendu de ces frameworks dans Node n'est donc pas pertinente pour une décision.

le fait qu'un framework fonctionne également sur le backend, puisse récupérer le contenu rendu côté serveur, et il serait même compatible avec NativeScript est peut-être un plus qui n'est pas pertinent aujourd'hui, mais une future fonctionnalité compatible avec une fonctionnalité intéressante, comme un projet ouvert d'esprit pourrait le considérer.

@webreflection Je ne voulais pas dire ce commentaire pour vous choisir en particulier. C'est plus en réponse au commentaire ci-dessus qui met en évidence le «paradigme du streaming» de Marko, mais il était destiné à couvrir tous les commentaires sur les performances de rendu BE.

Vue

@mAAdhaTTah de https://ma.tt/2017/09/on-react-and-wordpress/ :

Cet article ne sera pas publié et je suis ici pour dire que l'équipe de Gutenberg va prendre du recul et réécrire Gutenberg en utilisant une bibliothèque différente. Cela retardera probablement Gutenberg d'au moins quelques semaines et pourrait pousser la publication à l'année prochaine.

Et plus important:

Automattic utilisera également ce que nous choisirons pour Gutenberg pour réécrire Calypso

Calypso utilise déjà le rendu côté serveur. Voir: https://github.com/Automattic/wp-calypso/blob/master/server/render/index.js#L58

Donc, je crois comprendre que les performances SSR sont pertinentes.

J'aime aussi anguleux！
Cadre réel AngularJS js！

Je vote pour Angular

@chriscinelli C'est Automattic, pas WordPress. WordPress lui-même ne fait pas de rendu serveur avec nœud, donc les performances dans ces conditions ne sont pas pertinentes pour le projet.

De toute évidence, Angular est le meilleur choix

Je vote pour Angular

Je vote pour Angular

Je vote pour Vue.js.
Cela économise la plupart du temps, en particulier lorsqu'il s'agit de la couche de vues.

Je dois voter pour Vue !!!

Lance une vague angulaire

@trotyl Ce commentaire est inacceptable. J'ai modifié votre commentaire pour le supprimer.

oh, s'il vous plaît pas AngularJS
est maintenant Angular.

@mAAdhaTTah De wikipedia:

WordPress est sorti le 27 mai 2003 par ses fondateurs, Matt Mullenweg et Mike Little en tant que fork de b2 / cafelog

Bien que largement développé par la communauté qui l'entoure, WordPress est étroitement associé à Automattic , la société fondée par Matt Mullenweg.

Voici Calypso: https://developer.wordpress.com/calypso/ et Calypso utilise SSR.

Comme je l'ai écrit dans mon commentaire précédent , il est assez clair d'après le billet de blog abandonnant le support ReactJS par Matt qu'ils veulent garder Gutenberg et Calypso alignés sur la même technologie. Automattic servira les pages Calypso à partir de leurs serveurs avec SSR.

Je pense que cela suffit pour rendre la performance SSR pertinente dans cette décision.

Cependant, dans un futur lointain, une fois que les développeurs Wordpress se sont habitués à Preact (ou Vue ou Marko ou un autre framework), un nouveau projet fou peut sortir et ils décident de servir encore plus de parties de Wordpress via node. Cela rendra la RSS encore plus importante. Les performances SSR peuvent donc être encore plus importantes.

Au fur et à mesure que la conversation a avancé pour discuter de la SSR, je pense qu'il est prudent de mentionner que c'est une très haute priorité pour Ember et qu'elle a été longuement réfléchie avec l'avènement d' Ember-Fastboot.

Bien que j'utilise Fastboot (à grand effet) avec quelques applications clientes car il s'agit d'une discussion technologique de haut niveau, je recommanderais de contacter @tomdale car il était le champion de l'effort Fastboot 👍

@chriscinelli WordPress le projet communautaire et Automattic l'entreprise sont toujours des entités distinctes. Si Automattic veut plaider en faveur de l'un ou l'autre à cause de la SSR, ils le peuvent, mais cela ne change toujours pas la façon dont nous, la communauté WordPress, devrions envisager le cadre de choix pour le noyau WordPress, qui ne le fait pas, et ne peut vraiment pas, nécessite que le nœud s'exécute.

Quoi qu'il en soit, je me suis désabonné de ce fil. Si vous souhaitez poursuivre cette discussion hors ligne, mon e-mail est dans mon profil.

n'exige pas, et ne peut vraiment pas, que node s'exécute.

ne faisons pas de la capacité SSR un point discriminant. Les frameworks capables de nœud SSR peuvent vivre sans aucun nœud SSR: c'est juste une fonctionnalité supplémentaire, pas une exigence, ni une dépendance.

I'd vote for Vue.js

Je suis un arche senior qui est allé au MIT et qui est censé être raisonnablement intelligent. Je fais cela depuis de nombreuses années et j'ai interviewé quelques développeurs ici et là. Je sais que le Web regorge de gens intelligents, mais quiconque pense que la simplicité de Vue est à la hauteur de la complexité d'Angular a perdu sa perspective sur ce qui constitue un «complexe». Le Javascript basé sur les composants, tel que Google l'a conçu, n'est pas du tout trivial. C'est ridiculement complexe. Vue ne l'est pas. Vue est aussi simple que PHP. Je dis l'évidence, parce que «Vue est plus facile à apprendre» ne vient même pas de décrire à quel point Vue est plus facile que Angular. Et voici le hic - je pense que c'est aussi beaucoup plus facile que React.

React marchait entre le niveau facile et le niveau Google, pour les gens ordinaires. Pour les petits magasins, je dirais que React est suffisamment complexe pour défier les petites équipes. React est plus complexe que, par exemple, PHP / Wordpress. En choisissant React, Wordpress / Automattic a augmenté les exigences pour l'entrée des développeurs dans le monde des développeurs Wordpress. Je suis sûr que des centaines de personnes vont crier: «Réagir est facile» et «Le Web devient plus intelligent», mais plus complexe est encore plus complexe, en fin de compte.

Je pense humblement que revenir à Vue serait plus proche des racines de WP et moins d'un fardeau technique pour la communauté WP dans son ensemble. Mis à part les paradigmes Web - parfois, la simplicité est bonne.

Angular et Vue sont 2 choses différentes

Vue, React, MarkoJS, Inferno, Preact, etc. sont des bibliothèques couvrant uniquement la couche de vue. Tous, y compris Angular, ont un moyen de créer le HTML et de muter le DOM de manière déclarative. Angular veut fournir un cadre complet pour le développement du frontend et a beaucoup plus de choses au-delà de la couche de vue.

La syntaxe de React est la plus ancienne de cet exemple. Facebook a fait un très bon travail pour lier une bibliothèque très complexe qui fait beaucoup de choses (peut-être trop) dans une surface de protocole très limitée. Vous n'avez pas besoin de connaître cette complexité dans React pour savoir comment l'utiliser et être productif avec. Vous pouvez en fait apprendre les bases et commencer à utiliser en une demi-journée.

Toutes les autres bibliothèques de cette liste ont appris de React. Ils ont essayé de simplifier la syntaxe, d'améliorer les performances de React, de réduire la taille du code Javascript nécessaire pour faire les mêmes choses et d'ajouter quelques fonctionnalités en plus.
Preact a fait un excellent travail pour conserver une interface très similaire à React en seulement 3 Ko.
Inferno et Marko ont massivement optimisé les performances de rendu.
Marko et Vue ont beaucoup simplifié la syntaxe pour réduire le code standard.
Marko a également ajouté une syntaxe optionnelle de type Jade / Pug pour garder le code plus sec et la possibilité de créer des modèles asynchrones en gardant tout simple et intuitif pour l'utilisateur.

Cependant, toutes ces bibliothèques à côté d'Angular exigent que les ingénieurs proposent une stratégie et des mécanismes pour récupérer les données, le routage, etc. Redux et ses middlewares sont un moyen populaire utilisé par Gutemberg pour gérer la couche de données.

Dans la migration de React, Gutenberg n'a pas besoin de "juste autre chose pour changer". Même si Angular s'est efforcé de rester indépendant pour l'utilisateur, l'utiliser avec Redux et Javascript (vs Typescript) n'est pas un choix naturel malgré le fait que des bibliothèques comme https://github.com/angular-redux/ng-redux ont été développées et supportées pour Javascript est disponible. En outre, en regardant les votes jusqu'à présent, il semble que la communauté de Gutenberg soit fermement opposée au cadre de Google. Donc, très probablement, Angular ne sera pas une option.

PHP et n'importe lequel de ces frameworks Javascript sont des bêtes complètement différentes

Vous pouvez avoir un backend PHP et un frontend d'application d'une seule page, mais il n'y a pas de synergie et de petites similitudes.

Toute application Javascript est au moins un ordre de complexité au-dessus de ce que vous pouvez avoir en écrivant du code PHP simple saupoudré de jQuery. Toutes les applications Javascript modernes doivent gérer les deux grands monstres de complexité: l' état et les flux asynchrones . Ils ne sont atténués que par l'immuabilité et async / await ces dernières années. Le flux de développement ralentit à mesure que l'application se développe. Lorsque vous modifiez du code, vous devez recompiler, redémarrer et l'application doit recommencer l'initialisation. Une quantité massive d'outils a été construite pour implémenter des recharges à chaud et même si elles sont géniales, elles sont encore loin d'être parfaites.
Quelle que soit la bibliothèque que vous choisissez pour la couche de vue, vous devrez faire face à la complexité supplémentaire.

En PHP, vous modifiez le code, vous enregistrez un fichier et vous pouvez immédiatement recharger la page sans compilation ni rechargement. Tout fonctionne. Et plus important, PHP est complètement sans état . Chaque fois que vous rechargez la page, vous avez une ardoise vierge. Même les variables globales ont un état propre à chaque requête (mais ce n'est pas une bonne excuse pour les utiliser = P). Je n'ai pas écrit de code PHP depuis quelques années mais sa simplicité et son expérience de développeur me manquent encore. Si vous utilisez un framework moderne comme CakePHP, Symphony ou Laravel, vous ne manquez pas grand-chose par rapport à d'autres langages et frameworks plus bien accueillis par des ingénieurs sophistiqués. L'exception est la vitesse. PHP paie sa simplicité avec des performances d'exécution. Chaque fois que vous rechargez une page, tout le code doit être exécuté à nouveau. Les performances ont beaucoup augmenté avec HHVM et PHP7 mais en général elles sont encore loin de ce que vous pouvez réaliser avec node.js.

Conclusion

Peu importe la bibliothèque que vous avez récemment utilisée pour le frontend. Même si vous l'aimez, cela ne signifie pas que c'est le meilleur choix pour Gutenberg.
Le fait que _la plupart des principaux contributeurs de Gutenberg_ puissent aimer une bibliothèque spécifique est cependant important.

À la fin:

Un homme convaincu contre sa volonté est toujours du même avis

Je pense qu'il existe une quantité assez importante d'informations sur ce fil sur les avantages et les inconvénients de différentes bibliothèques viables.

Les contributeurs de Gutenberg et de Wordpress devraient être laissés seuls pour se réunir à «huis clos», loin des fanboys frontaux.
Il est peut-être temps de clarifier vos valeurs, vos objectifs et vos contraintes et de choisir le cadre en fonction de ce qui maximise votre résultat.

Et bonne chance encore avec votre décision 😃

J'ai voté pour Vue. Convient aux débutants et robuste. Quand j'ai commencé à utiliser Vue, j'ai eu le sentiment que j'avais lorsque j'ai commencé à développer avec WordPress. + 💯

@ tons colorés uniquement pour les débutants n'est pas assez bon! Chaque projet a un cycle de vie, la plupart du travail est en cours.

@ChrisCinelli Quelques précisions et avis:

Angular veut fournir un cadre complet pour le développement du frontend et a beaucoup plus de choses au-delà de la couche de vue.

Vue a des bibliothèques officielles pour le routage, la gestion d'état, les tests, le linting et plus, ainsi qu'un outil cli officiel. Tous ces éléments sont sous l'organisation vuejs, maintenus par les membres principaux et synchronisés avec Vue lui-même, mais la meilleure partie est que vous n'avez pas besoin de les apprendre ou de les utiliser (d'où la philosophie du 'Progressive Framework'). Contrairement à React, cela en fait effectivement un cadre dans sa forme officielle. Petit jeu de mots: tout cela tout en étant toujours plus facile à apprendre, plus rapide et plus léger que Angular. :sourire:

Marko a également ajouté une syntaxe optionnelle de type Jade / Pug

.vue fichiers

exiger des ingénieurs qu'ils élaborent une stratégie et des mécanismes pour récupérer les données

Ceci n'est qu'un exemple, mais la récupération des données n'a pas besoin d'être sur-ingénierie:

async created () {
  const result = await fetch('/api/items')
  this.items = await result.json()
}

À partir de là, vous pouvez créer un plugin Vue très simple pour rendre le code encore plus concis.

Vue elle-même ne devrait pas être la bonne bibliothèque pour ce travail car il y aura toujours de meilleures bibliothèques dédiées (c'est aussi pourquoi nous ne proposons pas de filtres de date par défaut, par exemple, car vous finiriez par utiliser moment ou une autre grande bibliothèque à la place de toute façon) . Nous sommes également en train d'écrire un livre de recettes avec des chemins et des pratiques recommandés pour plusieurs cas d'affaires et d'utilisation.

Lorsque vous modifiez du code, vous devez recompiler, redémarrer et l'application doit recommencer l'initialisation.

La seule vraie différence est l'étape de construction, qui est facile à configurer de nos jours à l'aide d'outils tels que vue-cli ou poi officiel. Lorsque vous enregistrez un fichier, l'application est presque instantanément prête à être actualisée (les temps de construction sont également très bons pour les grands projets, et l'expérience du développement d'une grande application PHP en utilisant un framework comme Symfony est plus pénible). En outre, la fonctionnalité Hot Module Remplacement est un gros plus qui n'existe pas dans le monde PHP (à ma connaissance) et permet à un nouveau code d'être disponible pour des tests dans le navigateur dans un temps quasi instantané, même dans les grands projets (sauf si vous avez opérations coûteuses comme la compilation de Sass - mais vous auriez le même problème lors de l'utilisation de PHP). À propos, Vue prend très bien en charge le webpack HMR.

Vous devrez faire face à la complexité supplémentaire.

À mon humble avis, certains frameworks PHP très populaires semblent être plus complexes et plus difficiles à apprendre que certaines bibliothèques / frameworks frontaux comme Vue. (Le contraire est également très vrai.)

Sur la base de mes 2 ans et plus d'expérience dans la création d'un éditeur basé sur des blocs similaire à Gutenberg, je pense qu'il y a plusieurs problèmes de démarrage à résoudre lors du choix du bon framework, par exemple

• Comment VueJS / Marko / Angular s'intégrerait-il avec le glisser-déposer? Comment fonctionnerait le glisser-déposer dans Gutenberg? Lorsque vous faites glisser, clonez-vous un élément fantôme ou utilisez-vous l'élément existant? Lors de la suppression, où pouvez-vous insérer des espaces réservés pour déposer un bloc?

• Comment VueJS / Marko / Angular (et son DOM virtuel) fonctionnerait-il avec Content Editables et l'API DOM Range & Selection? Les incohérences entre navigateurs avec cette gamme et cette sélection peuvent être très difficiles à résoudre ici.

• Dans quelle mesure le copier / couper / coller fonctionnera-t-il dans l'éditeur Gutenberg? Puis-je faire une sélection de texte entre plusieurs blocs et effectuer un couper / copier / coller? Le contenu modifiable se trouve-t-il dans chaque bloc individuel ou est-il tout contenu dans un contenu maître modifiable?

• S'il y a des blocs Gutenberg qui contiennent des intégrables iframe, par exemple en intégrant un lecteur youtube ou un fil Twitter dans un article de blog, déplacer ce bloc d'une position DOM à une autre position entraînerait le rechargement de l'iframe. D'autres mises en garde incluent l'impossibilité de récupérer les événements de l'iframe vers l'éditeur (imaginez si vous faites glisser un élément de bloc dans l'éditeur et que votre curseur plane maintenant sur l'iframe intersite et que tout cesse de fonctionner).

Tous les frameworks fonctionnent très bien avec Virtual DOM, mais une grande partie de l'utilisation du WYSIWYG se déroule en dehors du Virtual DOM. Je pense que les domaines sur lesquels se concentrer lors de l'évaluation du bon cadre pour Gutenberg sont de savoir dans quelle mesure le cadre peut gérer la gestion des événements DOM, et pour les exigences de pointe qui ne peuvent pas être construites avec un cadre, comment il est gérable de le construire en dehors du cadre. et rebranchez-le.

vue

Wordpress est assez facile à apprendre pour les nouveaux développeurs et c'est aussi beaucoup de puissance si vous regardez un peu plus loin, la même chose peut être dite pour Vue.
Je serai heureux si WP utilise ce framework!

Mon vote est VUE!

En termes de création de composants Web personnalisés, ce qui, à mon avis, est assez important pour l'avenir, ce site fournit un score pour chaque framework répertorié avec des paramètres de test et des scores. C'est instructif, j'encourage donc tout le monde à le répéter une fois:

https://custom-elements-everywhere.com/

Mon vote pour VueJS. Cadre génial, je pense que Laravel l'a prouvé.

WP + Sage 9 (roots.io) + VueJS => pile parfaite

Il peut également y avoir un problème avec Preact.

https://blog.cloudboost.io/3-points-to-consider-before-migrating-away-from-react-because-of-facebooks-bsd-patent-license-b4a32562d268

L'utilisation de Preact peut aggraver votre situation par rapport à l'utilisation de react. Facebook serait autorisé à vous empêcher d'utiliser réagir ou préagir même si vous n'avez pas engagé de poursuites. Cet avocat semble penser que Preact ne serait pas en mesure de faire valoir ses droits d'auteur devant les tribunaux et serait considéré comme une violation de React.

Dis-moi si je me trompe. Je ne connais pas grand chose au droit mais je voulais être utile.

J'ai lu ceci et c'est similaire aux conseils juridiques que nous avons reçus après avoir décidé de
abandonner React dans nos projets. Ce n'est pas que le risque soit énorme. Plutôt nous
voulait minimiser les risques pour les clients en aval. Cet avocat ajoute juste un
opinion concordante. Nous utilisons Polymer et Vue à la place, les deux fonctionnent très bien
pour des cas d'utilisation spécifiques.

Le 20 septembre 2017 23h04, "Coding Friend" [email protected] a écrit:

Il peut également y avoir un problème avec Preact.

https://blog.cloudboost.io/3-points-to-consider-before-
migrer-loin-de-réagir-à cause-de-facebooks-bsd-
licence-de-brevet-b4a32562d268

L'utilisation de Preact peut aggraver votre situation par rapport à l'utilisation de react. Facebook serait
autorisé à vous empêcher d'utiliser réagir ou préagir même si vous n'avez pas initié
la poursuite. Cet avocat semble penser que Preact ne pourrait pas tenir le coup
il s'agit d'un droit d'auteur devant les tribunaux et serait considéré comme une violation de React.

Dis-moi si je me trompe. Je ne connais pas grand chose au droit mais je voulais être utile.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/WordPress/gutenberg/issues/2733#issuecomment-331045326 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AH2_iHc8Rg54IDHqe8GIyVTdSbcJbZ9Iks5skeBngaJpZM4PYie9
.

Je me suis juré de ne plus jamais toucher à WP après avoir vu l'horrible code, mais si vous utilisez VueJS, je pourrais le reconsidérer avec un peu de Valium.

Avertissement: je ne suis pas avocat. Voici strictement mon avis.

@ codingfriend1 cet article a peu de mérite pratique.

Trois hypothèses sont émises:

1. Facebook a des brevets suffisamment larges pour couvrir le pré-acte.
2. Si une entreprise utilisant le pré-acte, disons ABC, poursuit FB pour contrefaçon de brevet, alors FB utilisera des brevets de réaction pour poursuivre ABC.
3. Le brevet de Facebook a du mérite.

Examinons de plus près toutes les hypothèses:

1. Facebook a des brevets suffisamment larges pour couvrir le pré-acte.

Il n'y a aucune preuve de cela jusqu'à ce jour. Gardez à l'esprit que tous les brevets sont publics. Le code source Preact est de notoriété publique.
De plus, Jason Miller (auteur préact) a affirmé que "aucun des Preact n'est brevetable - c'est beaucoup trop évident."

Je dirais donc que cette hypothèse est peu susceptible d'être vraie. C'est possible, mais peu probable.

1. Si une entreprise utilisant le pré-acte, disons ABC, poursuit FB pour contrefaçon de brevet, alors FB utilisera des brevets de réaction pour poursuivre ABC.

Cela détruira la réputation de Facebook. Alors que je m'attends à ce que FB se batte bec et ongles, mais en utilisant le brevet de react de cette façon, FB sera étiqueté comme "troll breveté".

Pendant ce temps, FB dispose de suffisamment de ressources pour lutter par des moyens légaux. Je pense donc que cette hypothèse est également peu probable.

1. Le brevet de Facebook a du mérite.

Oui, c'est une hypothèse, pas un fait.

Il se trouve que «détenir un brevet» et «avoir un brevet valide» sont deux choses différentes.
J'ai lu cet article fantastique où le tribunal a jugé les brevets invalides.

Il est toujours possible que le brevet de FB soit trop large pour avoir un mérite.
Maintenant, on pourrait penser que, si Facebook a un brevet, il aura un certain mérite. Pourtant, logiquement parlant, s'il couvre le pré-acte, alors il est trop large et donc sans mérite. Cette hypothèse est donc en conflit direct avec l'hypothèse 1.

Étant donné que Facebook utilise un brevet pour se défendre, le brevet de Facebook est plus susceptible d'être large et sans fondement, au lieu d'être exécutoire.

Conclusion:

Gardez à l'esprit que les trois hypothèses n'ont pas été testées. Si toutes se révèlent vraies, - et c'est techniquement possible - alors, "oui, utiliser préact est dangereux."

Cependant, en pratique, les chances que les trois hypothèses soient vraies sont trop faibles, en particulier les hypothèses 1 et 3 réunies.

Donc, jusqu'à ce que le tribunal en décide autrement, je dirais que l'utilisation de preact (et d'autres bibliothèques vdom) est tout à fait sûre.

Concernant le point 1, Facebook a un brevet appelé Délégation d'événements efficace dans les scripts du navigateur . C'est fondamentalement la fonction live() jQuery (faisant ensuite partie de on() dans l'API jQuery)!

Cependant, quelle que soit la validité des hypothèses, la raison pour laquelle WordPress s'éloigne de React n'est pas que WordPress a des inquiétudes à propos de Facebook. Et je cite le message d'annonce lié dans le numéro ci-dessus ( mettez le mien en

Je pense que la clause de Facebook est en fait plus claire que de nombreuses autres approches que les entreprises pourraient adopter, et Facebook a été l'un des meilleurs contributeurs open source. Mais nous avons beaucoup de problèmes à résoudre, et convaincre le monde que la clause de brevet de Facebook est bien n'est pas à nous de s'attaquer C'est leur combat .

Sur cette base, c'est la perception, la confusion et les questions que le brevet apporte qui ont chassé WordPress. Je pense que les mêmes préoccupations s'appliquent également à Preact, comme je l'ai expliqué dans mon commentaire précédent .

En ce qui concerne le point 1, Facebook a un brevet appelé Délégation d'événements efficace dans les scripts du navigateur. C'est essentiellement la fonction live () de jQuery (qui fera plus tard partie de on () dans l'API jQuery)!

Cela signifie-t-il qu'ils ont inventé l'idée de la délégation événementielle?! J'y vois des citations qui remontent à l'année 1995, qu'est-ce que cela signifie?

@ChrisCinelli concernant ce que vous

Je pense que c'est simplement une question d'échelle. Lorsqu'un projet compte 5k voire 10k étoiles Github, un seul événement comme par exemple un lien en haut de page de Hackernews peut rapporter 1k étoiles en une journée, ce qui dans le cas de Marko représente 20% du nombre récent.

À l'échelle de 65000 étoiles de Vue, ce n'est pas si visible. Vous pouvez même voir qu'en raison du fonctionnement du script de l'histoire des étoiles, à un moment donné, il cesse de montrer les fluctuations et ce n'est qu'une ligne droite jusqu'à la fin.

Une telle situation n'est pas propre à Marko lui-même, elle est arrivée à Inferno ou dernièrement à MoonJS qui est un microframework inspiré de Vue. Vous pourriez même dire que Preact semble être dans un point similaire en raison du nombre d'étoiles qu'il a obtenu ces derniers temps en raison de l'ensemble du drame des brevets de React.

Vous pouvez observer de quoi je parle sur le graphique suivant à partir de la même source que la vôtre:

Le temps nous dira si ces personnes vont réellement essayer le framework en développement, l'utiliser en production et continuer à l'utiliser plus tard. Je souhaite bonne chance à Marko, comme à toute autre bibliothèque open source.

Quant à Vue, oui c'est une croissance stable sans grande fluctuation. Avec la vitesse actuelle, il devrait dépasser React avant Noël. Au moins sur Github. :)

Et @aurelia?
Site Web: aurelia.io
@EisenbergEffect a créé ceci.

Pour moi, c'est un super cadre!

1. Conventions simples (peuvent être personnalisées)
2. HTML simple
3. Vanille JS
4. Aucune intervention-cadre!

Vous pouvez même ajouter la bibliothèque de votre choix (jQuery, Vue.js, Preact, Ember, HyperHTML, etc ...) que vous souhaitez utiliser et apprendre à Aurelia comment l'utiliser!

C'est tellement simple et basé sur des normes que vous n'aurez même pas besoin du soutien de la communauté, et si vous pensez vraiment que le soutien de la communauté est important, ils vous couvrent aussi (avec plus de 10 000 étoiles).

Ressources pour @aurelia :

1. Présentation d'Aurelia
2. Blog Aurelia
3. Aurelia Docs

On dirait que React reçoit une nouvelle licence sous le MIT: https://code.facebook.com/posts/300798627056246

La décision devrait être annulée maintenant, je suppose.

Holly Molly! React est de retour dans les affaires. WordPress a fait ça? Pas certain! Il est 3 heures du matin et j'en suis super excité! Et vous!

Renouveler la licence React, Jest, Flow et Immutable.js

La semaine prochaine, nous allons renouveler la licence de nos projets open source React, Jest, Flow et Immutable.js sous la licence MIT. Nous renouvelons la licence de ces projets parce que React est la base d'un vaste écosystème de logiciels open source pour le Web, et nous ne voulons pas retarder les progrès pour des raisons non techniques.

Cette décision intervient après plusieurs semaines de déception et d'incertitude pour notre communauté. Bien que nous pensons toujours que notre licence BSD + Patents offre certains avantages aux utilisateurs de nos projets, nous reconnaissons que nous n'avons pas réussi à convaincre de manière décisive cette communauté.

Dans le sillage de l'incertitude sur notre licence, nous savons que de nombreuses équipes sont passées par le processus de sélection d'une bibliothèque alternative à React. Nous sommes désolés pour le taux de désabonnement. Nous ne nous attendons pas à reconquérir ces équipes en effectuant ce changement, mais nous voulons laisser la porte ouverte. La coopération amicale et la concurrence dans cet espace nous poussent tous vers l'avant et nous voulons participer pleinement.

Ce virage pose naturellement des questions sur le reste des projets open source de Facebook. Bon nombre de nos projets populaires conserveront la licence BSD + Patents pour le moment. Nous évaluons également les licences de ces projets, mais chaque projet est différent et les options de licence alternatives dépendront de divers facteurs.

Nous inclurons les mises à jour de licence avec la sortie de React 16 la semaine prochaine. Nous travaillons sur React 16 depuis plus d'un an et nous avons complètement réécrit ses composants internes afin de débloquer des fonctionnalités puissantes qui profiteront à tout le monde qui construit des interfaces utilisateur à grande échelle. Nous partagerons plus bientôt comment nous avons réécrit React, et nous espérons que notre travail inspirera les développeurs du monde entier, qu'ils utilisent React ou non. Nous sommes impatients de mettre cette discussion sur les licences derrière nous et de revenir à ce qui nous tient le plus à cœur: expédier d'excellents produits.

À mon avis, avec la licence MIT et avec la communauté JS open source la plus active et la plus grande derrière elle - React est le choix définitif à suivre.

Mon vote est de retour avec React maintenant . - Foi en l'humanité restaurée.

Votez avec 👍 au lieu de commentaires similaires.

Je tiens à exprimer mes ÉNORMES MERCI à Wordpress pour avoir participé à ce qui a conduit à ce changement de lincencing React.

Je pense toujours que Vue serait la meilleure solution. Beaucoup des atouts de Vue s'appliquent toujours, mais je tiens à souligner que la convivialité pour les débutants et le fait de ne pas avoir à utiliser une étape de construction sont, à mon avis, des fonctionnalités qui tue dans l'environnement wordpress.

pour la masse
pour sûr
pour vueJS

J'ai également choisi Angular2.0 + (pas AngularJS), qui a la plus grande communauté, une équipe de développeurs solide, un écosystème stable et complet.

@CrazyBBer Où puis-je trouver des données sur la plus grande communauté étant Angular 2/4? Cela m'aiderait avec un article de blog.

Quoi qu'il en soit, les gars c'est fini, React est là pour rester avec WordPress et même en tant que passionné de Vue, je trouve que la situation pourrait tourner de la meilleure façon possible, étant donné la quantité de code déjà écrite avec React.

@ahmadawais @gustojs les gens sur Reddit ont fait part de leurs inquiétudes sur le fait que le MIT ne couvre que les droits d'auteur, donc les développeurs n'auront PAS de brevet lors de l'utilisation de React, ce qui, je suppose, reste un problème.

De plus, cette déclaration me dérange vraiment:

nous reconnaissons que nous n'avons pas réussi à convaincre de manière décisive cette communauté.

En effet, en disant "Nous n'avions pas tort - vous les développeurs ne nous compreniez tout simplement pas"

@ahmadawais : Je pense toujours BSD + Patents license maintenant, passant au MIT. Qui sait, dans un proche avenir, ils pourraient revenir à une licence / brevet appartenant à FB et ensuite tout le monde sera suspendu pour sécher. Vue a été MIT depuis le début et est plus axé sur la communauté que sur une grande entreprise.

Et ce qu'a dit @ atanas-angelov-dev.

Inutile de changer maintenant alors.
Je pense que Vue offre une meilleure perspective mais cela signifierait tout réécrire

Ahh! Allez les gens, donnez juste une chance à Aurelia!
Il a été créé par l'un des principaux développeurs de l'équipe Angularjs.
Vous pouvez passer d'une petite adoption à un framework complet, tout comme Vue.js

Même l'équipe du portail @azure a déclaré que s'ils avaient commencé maintenant, ils auraient choisi Aurelia plutôt que KO!
Et qui sait?! ils pourraient migrer vers Aurelia petit à petit maintenant.

Commencez peu, je sais que vous l'aimerez!

Nirmal4G,
Votre thèse semble si vendeuse qu'elle est ridicule.
En fait, je pense que l'ensemble du cadre présente les mêmes défauts que cette page 404 vers laquelle vous créez un lien direct dans votre message.
http://aurelia.io/get-started.html

@ bovas85 Pas commercial, je ne fais même

@ cr101 / cc

Ne jugez pas le livre par sa couverture

J'ai utilisé de nombreux frameworks populaires avant même de connaître Aurelia. Si je devais les empiler en équilibrant tous les critères, pour mon application (croyez-moi, c'est une grande application), Aurelia est en tête de liste et suivie de Vue.

Je pense que l'ensemble du cadre présente les mêmes défauts que cette page 404 vers laquelle vous créez un lien direct dans votre message.

Chaque lien que j'ai publié ne mène jamais à une page 404. C'est la faute de github pour rediriger un site http vers https. C'est réglé maintenant. Voyez, un bug. Dites-moi tout framework qui n'a pas de bugs, je vous défie.

C'est juste qu'avec d'autres frameworks, vous avez beaucoup d'abstractions redondantes (mais utiles). La communauté W3C n'adopte jamais de conception de cadre public dans son API, donc voilà, beaucoup d'abstractions.

Chaque framework est tellement concentré sur la compatibilité descendante qu'ils perdent la compatibilité ascendante, mais Aurelia ne le fait pas, tant que vous vous en tenez aux spécifications HTML W3C et ECMAScript, JS votre code fonctionne bien.

_S'il n'y a pas d'Aurelia, cela ne me dérangerait pas de m'en tenir à Vue. C'est la meilleure chose suivante._

_Il s'agit simplement d'accepter une norme plutôt que de créer une nouvelle façon de la réinventer._

@ Nirmal4G veuillez fournir des preuves de vos réclamations ou éviter les noms. Je crois à peine, surtout quand il s'agit de LOC, que Vue était moins que hyperHTML. Tout ce que j'ai écrit en hyperHTML par rapport à vue était moins LOC, rassemblant la mise en page et la logique . Même si je ne crois même pas en LOC comme une métrique pertinente à quoi que ce soit, la lecture de FUD non prouvée ne me semble pas juste.

@WebReflection Tenez vos chevaux, je n'ai pas dit que vous étiez pire que Vue. Désolé si je vous ai offensé.

Mon application utilise tout ce que vous pouvez lui lancer. J'ai essayé un prototype avec de nombreux frameworks, l'un des critères que j'avais était le LOC mais du point de vue visuel, ce n'est pas pour la raison que vous pensez, toute performance du framework peut être améliorée mais ce sont les choix de conception, qui viennent avec le nom.

J'ai évalué HyperHTML, les performances étaient impressionnantes, aucun polyfills n'est génial, mais malheureusement, pour mes besoins, il n'a pas fait la coupe.

Chaque cadre a une meilleure chose, mon souhait est que si quelqu'un peut assembler le meilleur de tous les cadres avec un meilleur design, ce serait divin, mais cela n'arrivera pas. Donc, je dois trouver cet équilibre où un cadre peut s'améliorer à l'avenir et où il ne le fera pas.

C'est vraiment bon d'entendre que React va maintenant être le MIT.
Je suis très enthousiasmé par ce projet et j'ai hâte de recommencer à utiliser WordPress après longtemps, une fois que React et WP API seront entièrement pris en charge. :)

Attendons de voir quelle sera la licence React. Brevets MIT ou MIT + ..? ;)

Personnellement, j'aime React mais je trouve Vue plus productive. Je serais content de l'un ou de l'autre, mais ...

... en gardant à l'esprit le fort soutien de Vue par la communauté, je suggère de prendre cela en considération, en plus des licences.

Vue semble être un choix plus approprié pour WordPress.

Facebook a supprimé 4 éléments de sa suite de pièges litigieux. Ce sont maintenant tous sous licence MIT:

• Réagir
• Plaisanter
• Couler
• Immutable.js

Pendant ce temps, la licence de catégorie X de Facebook s'applique toujours à:

• Réagir natif
• GraphQL
• Fil
• Relais
• IDE Atom
• et probablement toute autre chose faite par eux et "open" source

Je dis toujours aller avec Vue. Cela en vaut la peine à long terme. De toute façon, React n'a jamais eu de sens pour Wordpress. Il est tellement intégré dans la communauté PHP que Vue a toujours semblé être le choix le plus sensé (en plus il n'est pas pénible à utiliser comme React).

Pendant ce temps, la licence de catégorie X de Facebook s'applique toujours à:

Réagir natif
GraphQL
Fil
Relais
IDE Atom
et probablement toute autre chose faite par eux et "open" source

@TheJaredWilcurt désolé mais vous voulez peut-être supprimer le fil de cette liste .. le fil n'a pas une telle licence "Facebook Catégorie X" -> https://github.com/yarnpkg/yarn

@ atanas-angelov-dev

Les gens sur Reddit ont soulevé des inquiétudes sur le fait que le MIT ne couvre que le droit d'auteur, de sorte que les développeurs n'auront PAS de concession de brevet lors de l'utilisation de React, ce qui, je suppose, reste un problème.

Le MIT est une excellente licence. jQuery est également sous licence MIT. J'espère que vous le savez.

@vinayakkulkarni Je pense toujours

Ce n'est pas comme ça que ça marche. J'ai lu le commentaire de Samuel sur Facebook à une question similaire. Une fois que vous avez obtenu une licence MIT, vous pouvez soit le modifier pour changer la licence, soit vous ne pouvez tout simplement pas. Mais je ne suis pas avocat.

De plus, personnellement, je pense que Facebook a fait cela comme un geste de bonne foi et non pour tromper les gens. Cela signifie quelque chose pour moi.

De plus, personnellement, je pense que Facebook a fait cela comme un geste de bonne foi et non pour tromper les gens. Cela signifie quelque chose pour moi.

Ce n'est pas une déclaration très logique. Vous récompensez un groupe parce qu'il a arrêté de faire quelque chose de négatif, plutôt que de récompenser le groupe qui n'a jamais rien fait de négatif. De plus, comme mentionné ci-dessus, ils utilisent toujours des licences de catégorie X dans d'autres projets similaires, ce qui n'est pas un signe de bonne foi pour moi.

Vue a une courbe d'apprentissage et d'adoption beaucoup plus douce.
Et c'est la principale idée sous-jacente de WordPress depuis le début.

@ahmadawais Je sais - Le MIT est aussi bon que les licences mais, et c'est un gros "mais", Facebook a apparemment des brevets sur React et bien que le MIT vous permette d'utiliser le code dans n'importe quel but, vous risquez de finir par enfreindre Facebook. brevets (prenez tout cela avec un bloc de sel - IANAL)

Et pour rester sur le sujet, je dois dire que je vois beaucoup de ce qui a rendu WordPress génial dans Vue également - à mon humble avis, aucune autre bibliothèque appropriée n'est aussi facile à apprendre et à utiliser que Vue.

Facebook a apparemment des brevets sur React

Quelle partie de React pensez-vous être brevetée? (rien dans React n'est breveté, essayez d'abord de faire une recherche) afficher des liens, pas seulement "apparemment" .., c'est le genre de commentaires qui n'aide pas du tout. si vous souhaitez recommander votre bibliothèque préférée, faites-le de la bonne manière, en montrant ses mérites, pas seulement en diffusant FUD.

Pourquoi le passage initial aux brevets BSD + si aucun React n'a de brevet derrière lui? Facebook n'a pas dit ce qu'ils sont ou ce qu'ils ne sont pas.

Pourquoi déranger avec les licences pendant 2 ans et ne faire un changement que pour une partie de leur portefeuille, après avoir toujours dit qu'ils ne le changeraient pas, et dit "il suffit de s'en occuper, nous ne nous soucions pas si vous l'utilisez ou non".

Pourquoi exclure React Native, GraphQL, etc. de la «nouvelle» licence? Vers quoi une future version de React va-t-elle basculer? Il n'y a aucune garantie lorsque vous avez une licence à deux niveaux de Facebook, selon qui s'en plaint ...

Que faire si une partie du code React Native est intégrée à React. Où en êtes-vous si une implémentation GraphQL se fraye un chemin dans une base de code ..?

Cette action de Facebook soulève plus de questions qu'elle ne répond, et signifie toujours que chaque utilisation de React est un risque potentiel pour les vrais projets Open Source.

Adoptez simplement la bibliothèque sans bagage qui est déjà établie dans le monde PHP - Vue.

@bjrmatos https://www.google.com/patents/US20170221242 Je suppose!

Encore un +1 à Vue. Facebook utilise toujours deux licences tout au long de ses projets. Ce n'est pas bon.

@PericlesSouza, vous

@Raymonf Eh bien, fondamentalement, tout cadre moderne viole déjà ce brevet (y compris Vue), donc tout le monde est dans la même position, peu importe si vous utilisez React, Vue ou un autre cadre qui implémente le concept décrit dans le lien (btw essentiellement projet là-bas est déjà en violation de deux ou trois brevets appartenant à d'autres entreprises, vous serez surpris de savoir quel genre de choses sont brevetées par les entreprises à l'heure actuelle). Si cela vous inquiète vraiment, cela signifie que vous ne pouvez pas utiliser de framework qui met à jour l'interface utilisateur de cette manière ... donc dans ce contexte juridique, il n'y a pas d'alternative meilleure ou pire.

Je ne veux pas m'impliquer à nouveau dans ce genre de conversations car il sera impossible de parvenir à un accord, je vais donc arrêter mes commentaires. La communauté React est satisfaite du passage au MIT (même les plus grands détracteurs de la licence d'origine)

Bonne chance à l'équipe wordpress dans la décision, le principal problème de la licence React BSD + Patents est résolu, c'est maintenant à eux de décider.

Facebook a donc récemment modifié sa licence pour React. Cela signifie-t-il que WordPress continuera à utiliser React ou modifiera toujours le framework frontal par défaut?

@bjrmatos ce n'est pas du tout vrai

fondamentalement, tout cadre moderne viole déjà ce brevet

par exemple, hyperHTML n'utilise pas de DOM virtuel, il utilise directement l'API DOM (non brevetable) via des appels de rappel réguliers (non brevetables) et le seul algorithme différent pour transformer c hildNodes: avant de c hildNodes: après dans les listes de nœuds est basé sur la distance de Levenshtein (non brevetable) et le moins grand nombre d'opérations d'épissure (non brevetable, j'ai écrit cela et c'est ISC ).

Et bien qu'à ce stade, je pense que ce fil est obsolète et inutile, je ne comprends pas la nécessité de continuer à répandre FUD. Si vous avez fait un choix et que vous l'aimez, il n'y a aucune raison de dire à tout le monde qu'ils font quelque chose de mal ou qu'ils ont les mêmes problèmes que vous. Je souhaite que nous puissions nous mettre d’accord là-dessus.

@noncotient c'est une question à un million de dollars, n'est-ce pas? 💯

Je viens de me désinscrire ici car la discussion devient un peu inutile.
Je pense que beaucoup de bons points ont été avancés et ce fut une expérience d'apprentissage pour tous ceux qui ont lu attentivement ce numéro.

Je suis d'accord, c'est désormais inutile. Je suggère que ce fil soit verrouillé (ou peut-être des contributeurs uniquement). Il y a eu suffisamment de commentaires sur cette question, et maintenant elle atteint le point où elle ne mènera qu'à des arguments non constructifs.

Ce problème sera-t-il clos?
Il semble que @WordPress ne souhaite pas migrer vers le nouveau framework JavaScript maintenant. 🤔

Pour moi, j'aime personnellement @vuejs. Mais il semble que cela n'a pas d'importance maintenant. 😅

Personnellement, je préférerais de loin Vue malgré tout.

Pour moi, et je crois que beaucoup d'autres personnes, il n'a jamais été question de licence. C'était juste une excuse pour s'éloigner de React.

Marko est incroyablement puissant et facile. Nous sommes actuellement en train de terminer une réécriture complète d'un magasin en ligne dynamique avec 50 000 produits et il est flamboyant et extrêmement riche en fonctionnalités. Suivez cette voie et ne regardez pas en arrière.

Marko est bon mais Prarko est 100 octets plus petit (GZipped), et est 0,01% plus rapide sur un test auto-optimisé, nous devons donc l'utiliser à la place, même si personne d'autre ne le fait. Bien que demain, Plarko sortira, avec une fibre supplémentaire, ce qui rend tout ce qui est redondant.

Désolé, mais c'est ainsi que se dirige le reste de ce fil.

Attendons de voir quelle est la licence réelle lorsqu'elle sortira, quelles sont les implications de la licence à deux niveaux de Facebook, et voyons quelle décision l'équipe WordPress prend une fois qu'elle a étudié le problème en profondeur.

Je veux dire, à l'origine, il a demandé des commentaires sur les moteurs que la communauté aime. Et cela semble être ce que les gens publient, mais certaines personnes sautent simplement partout pour envoyer des commentaires qui correspondent à ce qui a été demandé. Un peu étrange.

Toutes les bibliothèques / frameworks mentionnés ici sont excellents; certains sont plus adaptés à certains scénarios que d'autres. Chacun aura ses défenseurs, chacun devancera les autres en termes de performances / fonctionnalités, en fonction de leurs cycles de développement.

Commencez peut-être par une question simple, comme je le fais sur la plupart des projets:

1. Avons-nous besoin d' un cadre SPA?

Si la réponse est oui, expliquez pourquoi. Cela vous donne un ensemble de critères pour évaluer les candidats potentiels; peut-être pour le rendu côté serveur, peut-être le routage, etc.

Sinon, posez la question suivante:

1. Est-ce que nous avons vraiment besoin d' un moteur de modèle?

VanillaJS a la plus grande communauté de la planète et aucun problème de licence. Il est également conforme aux normes;), et avec les modules ES6, pourrait offrir une base appropriée pour le développement de base, avec la possibilité de prendre en charge le plugin pour utiliser des moteurs _template_ tels que React, Vue, Preact, Aurelia, etc. etc., tout ce qui sera publié dans les années à venir, comme l'exigent les développeurs.

Matt Mullenweg a publié sa réponse ...

Je suis surpris et ravi de voir la nouvelle que Facebook va abandonner la clause de brevet dont j'ai parlé la semaine dernière. Ils ont annoncé qu'avec React 16, la licence ne serait que du MIT ordinaire sans ajout de brevet. J'applaudis Facebook pour avoir pris cette décision et j'espère que l'utilisation de la clause de brevet sera réexaminée dans tous leurs projets open source.

Notre décision de nous éloigner de React, sur la base de leur position précédente, a suscité de nombreuses discussions intéressantes dans le monde WordPress. En particulier avec Gutenberg, il peut y avoir une approche qui permet aux développeurs d'écrire des blocs Gutenberg (Gutenblocks) dans la bibliothèque de leur choix, y compris Preact, Polymer ou Vue, et maintenant React pourrait également être une option officiellement prise en charge.

Je tiens à remercier tous ceux qui ont participé à la discussion jusqu'à présent, je l'apprécie vraiment. Le débat et la discussion vigoureux dans les commentaires ici et sur Hacker News et Reddit ont été formidables pour la passion que les gens ont apportée et l'opportunité d'en apprendre davantage sur tant de points de vue différents; c'était encore mieux que Facebook écoutait.

→ https://ma.tt/2017/09/facebook-dropping-patent-clause/

@ahmadawais @m

Notre décision de nous éloigner de React, sur la base de leur position précédente, a suscité de nombreuses discussions intéressantes dans le monde WordPress. En particulier avec Gutenberg, il peut y avoir une approche qui permet aux développeurs d'écrire des blocs Gutenberg (Gutenblocks) dans la bibliothèque de leur choix, y compris Preact, Polymer ou Vue, et maintenant React pourrait également être une option officiellement prise en charge.

Cette situation semblerait être une victoire pour tout le monde. Attendons de voir comment cela se passe réellement.

Fermez ce numéro maintenant ... cela montre à quel point le monde est inconstant ... triste de voir les gens ne pas tenir parole.

[Modifier: supprimé en raison d'une déclaration offensante]

Bonne chance à tous ceux qui doivent utiliser Gutenberg et la lourde courbe d'apprentissage de l'apprentissage Réagissez avec.

Paix.

👋 Je pense que nous avons tous eu beaucoup de discussions ici. Je tiens à remercier tous ceux qui se sont suffisamment souciés pour parler et commenter cette question. IMHO, il semble que toutes les options que nous avons en ce moment sont de bonnes options.

Si nous nous retrouvons avec une meilleure API indépendante du framework, on pourra utiliser n'importe quel framework JS de son choix dans ses applications. Avec la licence MIT, React a une position aussi forte pour être utilisé dans le noyau que toute autre bibliothèque avec une bonne licence open source (compatible en lecture).

🎯 Si vous recherchez un framework JavaScript particulier, ou si vous en avez créé un (équipes principales), je vous suggère de créer des exemples réels pour les développeurs WordPress afin que les gens puissent commencer à jouer avec l'idée d'utiliser votre framework JavaScript préféré dans les applications basées sur WordPress. construire.

Je ferme ce ticket pour le moment. Et dans l'espoir de contribuer davantage au succès de WordPress en tant que plateforme et en tant que communauté. Attendre la même chose de tout le monde ici. Je crois vraiment que ce sera une aventure de montagnes russes pour quiconque travaille avec le logiciel WordPress.

Dans un certain temps, nous pourrions finir par améliorer le logiciel pour le rendre plus facile pour ses utilisateurs (~ 30% des sites Internet) comme il y a quelques années. J'encourage WordPress ici, comme vous tous!

À votre santé!

Ce n'est pas vraiment clair d'après le commentaire de Matts si la décision de quitter React a été annulée.

Premièrement, la licence réelle que Facebook utilisera n'a pas encore été publiée , donc prétendre que c'est fini n'est pas vraiment une décision judicieuse.

Deuxièmement, il ne traite pas des licences à deux niveaux suivies par Facebook: React pourrait être MIT, mais React Native sera + (non divulgué) brevets .

Alors ... qu'en est-il des composants qui sont partagés par les deux?

Qu'en est-il du code React Native utilisé dans React? Fibre va-t-elle être partagée entre deux licences différentes? Ou le code GraphQL se retrouve dans React?

Qu'arrive-t-il à WordPress s'il suit la voie React, avec tous ces projets Facebook connexes publiés sous une licence différente, puis Facebook décide que certains aspects de React sont en fait soumis, par exemple, à une subvention de brevet React Native ou à une fibre Octroi de brevet?

Sérieusement, réfléchissez très attentivement à cela. Pourquoi le risquer alors qu'il existe des alternatives que la majorité préfère utiliser, qui n'ont pas ce problème - Vue.

Je ne ferais pas confiance à un accord de licence qui change avec le vent, au lieu d'être bien pensé. Les avocats de Facebook pourraient renverser la vapeur sur un coup de tête.

Restez fidèle à la véritable Open Source.

@PericlesSouza La licence sera exactement ce que les gens imaginent ici à partir de la description de l'article de blog: une licence MIT standard, rien de plus. React ne dépend pas de React Native. Les éléments partagés par les deux vivent dans le projet React, pas dans React Native. React et ses dépendances appartenant à FB seront disponibles sous MIT dès que notre équipe aura le temps de valider les modifications. Nous ne prévoyons aucune entreprise amusante.

@sophiebits

Vous travaillez pour Facebook. Si vous n'êtes pas un avocat autorisé à parler au nom de Facebook, peu importe ce que vous prétendez. Le code que vous écrivez n'a même pas d'importance. Désolé.

«Imaginer» les licences ne tient pas debout devant les tribunaux.

Par exemple, pouvez-vous énoncer catégoriquement pourquoi Facebook a adopté la concession de brevet, quels étaient les brevets (ou n'étaient pas), ou pourquoi ils disent qu'ils le changent maintenant, sans dire `` IANAL '' (je ne suis pas un avocat)?

Les pièces partagées par les deux vivent dans le projet React, pas dans React Native

Mais pouvez-vous dire cela avec une garantie légale? Non?

React et ses dépendances appartenant à FB seront disponibles sous MIT dès que notre équipe aura le temps de valider les modifications

Quelles parties sont supprimées pour permettre à React d'être publié sous MIT? Quelles dépendances n'appartenant pas à FB et qui n'étaient probablement pas conformes au MIT utilisiez-vous déjà ..? Les avocats de Facebook garantiront-ils que tout est vraiment conforme au MIT? Combien de temps faudra-t-il à Apache Software Foundation pour le certifier?
.

Il semble que j'ai eu raison de souligner que le code est partagé entre deux projets qui auront apparemment une licence à deux niveaux.

Vous déformez mes mots. Le code partagé entre React et React Native sera sous licence MIT. Tout ce que vous considérez comme fibre sera sous licence du MIT. React n'inclura ni ne dépendra d'aucun code sous licence BSD + Brevets ou de toute autre concession de brevet que vous méprisez tant. Nous ne supprimons pas des parties de React. La seule dépendance non-FB de React que je connaisse est l'attribution d'objet qui est également sous MIT.

Je ne vous suggère pas de prendre mes paroles comme une garantie légale. Nous sommes tous les deux conscients que mes commentaires ici ne changent pas en eux-mêmes la licence de React. Vous pouvez choisir d'être sceptique et ne pas avoir à me croire maintenant, mais dans un jour ou deux, vous verrez que ce que je dis ici est vrai.

@sophiebits

Je ne déforme pas vos paroles - et je respecte à la fois le travail que vous faites et votre volonté de vous engager ici.

Je dis simplement qu'à moins et jusqu'à ce que nous obtenions des engagements juridiques de Facebook, par des responsables autorisés de l'entreprise, vérifiés par des organismes open source externes, alors nous sommes toujours dans la même position que nous avons commencé - personne ne peut être certain de la situation juridique réelle. est, comme vous en convenez en déclarant:

Je ne vous suggère pas de prendre mes paroles comme une garantie légale. Nous sommes tous les deux conscients que mes commentaires ici ne changent pas en eux-mêmes la licence de React.

Et:

Tout ce que vous considérez comme fibre sera sous licence du MIT.

Peu importe ce que je considère comme Fibre, cela dépend entièrement de ce que les avocats de Facebook et les brevets déposés définissent comme Fibre.

Pourquoi React Native est-il actuellement destiné à recevoir une licence différente de React, lorsqu'il partage du code avec React? Cela ne rend-il pas (pardonnez le jeu de mots) la licence MIT invalide?

Je note également que vous n'avez pas mentionné GraphQL. Y a-t-il autre chose que j'ai manqué?

Le point entier de la débâcle des licences React est le manque de sécurité juridique.

@sophiebits

Je note votre modification en réponse à mes points:

React n'inclura ni ne dépendra d'aucun code sous licence BSD + Brevets ou de toute autre concession de brevet que vous méprisez tant. Nous ne supprimons pas des parties de React. La seule dépendance non-FB de React que je connaisse est l'attribution d'objet qui est également sous MIT.

Mais vous avez dit que vous supprimiez des parties de React et que vous vérifieriez le code "dans les prochains jours".

React et ses dépendances appartenant à FB seront disponibles sous MIT dès que notre équipe aura le temps de valider les modifications

Et vous avez oublié le IANAL ... :-)

Oh, en fait, vous l'avez dit en forme longue:

Je ne vous suggère pas de prendre mes paroles comme une garantie légale. Nous sommes tous les deux conscients que mes commentaires ici ne changent pas en eux-mêmes la licence de React.

Encore une fois:

Le point entier de la débâcle des licences React est le manque de sécurité juridique.

Je suis d'accord avec le fait qu'il n'y a toujours pas de sécurité juridique. Mais je crois personnellement que ce fil a suivi son cours; Il est préférable de le marquer comme contributeur uniquement, et d'attendre que la licence réelle soit publiée et que l'équipe puisse faire son évaluation.

Désabonnement maintenant.

Veuillez ne pas vider React, Facebook a fait sa décision https://thenextweb.com/dd/2017/09/25/facebook-re-licenses-react-mit-license-developer-backlash/

@vinayakkulkarni Bien que je

@sophiebits juste un petit mot pour vous remercier d'être venu dans ce fil, c'est apprécié.

Cela pourrait être un sujet pour un nouveau fil, mais malheureusement, la licence MIT (même la licence standard) ne résout pas le problème d '«incertitude» avec les brevets, ce qui a conduit à une décision WordPress plus tôt.

La licence MIT vous donne-t-elle le droit d'utiliser une propriété intellectuelle brevetée? Lisez ce qu'un avocat a à dire à ce sujet: La licence MIT, ligne par ligne

- Frans Bouma (@FransBouma) 23 septembre 2017

Le MIT ne vous accorde apparemment pas de licence de brevet. Facebook a des brevets dans React, qu'il dit vous octroyer dans sa licence actuelle. Avec la licence actuelle, au moins, vous savez que vous avez toutes les licences existantes et quelles sont les conditions qui les révoquent. Avec un MIT, vous n'obtenez même pas de licence.

La délivrance de brevets signifie cependant qu'il y a des brevets concernés (ou que concède-t-il?). Sauf que personne ne sait ce que sont les brevets. Facebook ne l'a pas dit, même pas quand il les a accordés, ni quand il a annoncé la suppression de la subvention.

Indépendamment de ce que moi ou l'équipe de WordPress pourrait penser que cela signifie, ce qui semble être toujours présent, c'est la confusion autour de la situation juridique des brevets Facebook (encore non répertoriés) dont il dispose sur React, que toute personne qui l'utilise [[peut - ou- peut ne pas]] s'inquiéter de la violation, lors de la poursuite de Facebook aujourd'hui, ou simplement en utilisant React après la nouvelle licence.

Encore une fois, que ce soit ou non, le problème est l'incertitude, et c'est ce que je dis n'est pas résolu.

Pour rappel, la majorité qui a donné son avis sur ce fil souhaite une solution basée sur Vue.

Il y a plusieurs raisons à cela, qui ne se limitent pas au fait que Vue n'a pas de confusion de licence (qui reste toujours avec la politique de licence à deux niveaux de Facebook):

1. Vue est conçu dès le départ pour être ajouté de manière incrémentielle, avec des îlots de fonctionnalités, permettant une amélioration progressive d'une base de code.

2. De plus, et en option, il fournit des solutions de gestion d'état et de routage officiellement prises en charge.

3. Il prend en charge plusieurs processeurs pour HTML, offrant aux développeurs un choix de langage de modèle - HTML, JSX, Pug, etc., ou des fonctions de rendu.

4. Composants de fichier unique et CSS étendus (Stylus, SASS, SCSS, PostCSS, composants CSS) - de la manière la plus simple possible. Littéralement, ajoutez simplement l'attribut scoped aux déclarations de style de vos composants, et c'est fait.

5. Prise en charge des propriétés calculées (avec mémorisation) intégrées (c'est-à-dire sans dépendances telles que MobX).

   6+. Des performances supérieures pour React, une courbe d'apprentissage beaucoup plus faible, une adoption plus élevée dans la communauté PHP, consultez Laravel Mix par exemple - vous pouvez l'utiliser sans utiliser Laravel lui-même. Ou incluez simplement Vue via https://unpkg.com/vue et commencez à coder.

Vue est tout simplement plus adapté à WordPress.

Réagissez :

76364 étoiles Github
571 Problèmes en suspens (!)
4325 Problèmes résolus
178 demandes de tirage ouvertes (!)
5644 demandes de tirage fermées

Vue :

68, 246 étoiles Github (la trajectoire est de dépasser React d'ici Noël)
62 problèmes ouverts (beaucoup plus réactifs à la correction de bogues, ajout de fonctionnalités demandées)
5629 Problèmes résolus
17 demandes Open Pull
863 demandes de tirage fermé

@Meligy

Le MIT ne vous accorde apparemment pas de licence de brevet. Facebook a des brevets dans React, qu'il dit vous octroyer dans sa licence actuelle. Avec la licence actuelle, au moins, vous savez que vous avez toutes les licences existantes et quelles sont les conditions qui les révoquent. Avec un MIT, vous n'obtenez même pas de licence.

La délivrance de brevets signifie cependant qu'il y a des brevets concernés (ou que concède-t-il?) Facebook ne l'a pas dit, même pas quand il les a accordés, ni quand il a annoncé la suppression de la subvention.

C'est là que réside le problème du pas tout à fait Open Source d'une grande entreprise. En fin de compte, leurs avocats annuleront les bonnes intentions des équipes de développement, maintenant ou à l'avenir.

Facebook a présenté sa licence + brevets comme une défense agressive de `` quelque chose ou quoi que ce soit '', et maintenant on nous demande de croire que le même `` quelque chose ou quoi que ce soit '' n'existe pas réellement pour React, mais _il existe toujours_ pour React Native et GraphQL etc.

Automattic peut-il promettre qu'ils prendront le fardeau sur lui-même et porteront React, forkeront, le développeront seul, quand Facebook changera à nouveau sa licence et son opinion sur React?

Pour moi, il semble que Facebook tend un piège à WordPress. 25% de tous les sites Web dans le monde sont un gros problème.

Veuillez marquer ce fil de discussion comme _contributeurs uniquement_ dès que possible, ce serait bien de lire les résultats des contributeurs, au lieu de simplement FUD et spéculations, sans avoir besoin de vous désinscrire complètement. Je vous remercie.

Les parties prenantes de @WebReflection Wordpress ne sont pas seulement ses principaux développeurs, mais aussi la communauté étendue.

@PericlesSouza citant des étoiles Github ne https://npmcharts.com/compare/react , angular, @ angular / core , ember-cli, vue

Vue n'est pas beaucoup plus qu'un signal sur le radar. La grande majorité utilise React et ne serait certainement pas non plus d'accord avec vos puces.

@PericlesSouza citant des étoiles Github ne https://npmcharts.com/compare/react , angular, @ angular / core , ember-cli, vue

Vue n'est pas beaucoup plus qu'un signal sur le radar. La grande majorité utilise React et ne serait certainement pas non plus d'accord avec vos puces.

Statistiques NPM? Vous voulez dire que les mêmes statistiques qu'ils admettent comptent chaque demande pour vérifier si vous utilisez ou non la dernière version, ou via chaque dépendance, comme une demande de téléchargement? (Ils ont admis cela sur leur blog quand les gens se moquaient de leurs «milliards de paquets par mois»).

Si vous voulez suivre cette voie, alors tout le monde utilise jQuery.

Essayez peut-être des figures pour les paquets qui n'ont pas ce champ de distorsion de dépendance:

https://npmcharts.com/compare/vue-cli , create-react-app

Image complètement différente de celle que vous avez choisi de présenter.

Ou que diriez-vous de l'utilisation du site Web:

https://w3techs.com/technologies/comparison/js-react , js-vuejs

Qui est soutenu par BuiltWith stats:

Oh, et je vais simplement laisser cette image ici - à partir du moment où l'équipe a demandé à la communauté elle-même. Vous devriez les écouter plutôt que les traiter avec mépris.

@PericlesSouza Cela n'a aucun sens de comparer vue-cli avec create-react-app car il existe d'autres outils de construction très populaires pour React comme Next.js et GatsbyJS .
De nombreux développeurs React n'utilisent même pas de CLI et utilisent à la place leurs propres scripts de construction Webpack personnalisés, comme le font Gutenberg et Calypso.

La réalité est que l'écosystème React est beaucoup plus grand que celui de Vue. Prenez par exemple Material UI pour Vue.js qui a 4339 étoiles tandis que Material UI pour React a 29078 étoiles.

Un composant de boîte de sélection natif qui fournit des fonctionnalités similaires à Select2 sans la surcharge de jQuery: Vue select a 1348 étoiles tandis que React select a 8493 étoiles.

@PericlesSouza , @drcmda , toutes ces données peuvent être contestées de nombreuses manières, même les statistiques npm avec les cli, si vous ajoutez AngularCLI et EmberCLI, vous verrez des données totalement différentes, ce qui ne veut rien dire:

Source: https://npmcharts.com/compare/vue-cli , create-react-app, @ angular / cli , ember-cli

Source: https://w3techs.com/technologies/comparison/js-angularjs , js-react, js-vuejs

Source: https://insights.stackoverflow.com/survey/2017#technology -frameworks-bibliothèques-et-autres-technologies

Mais cette conversation ne devrait pas porter sur le cadre le plus utilisé, mais sur celui qui sera le mieux pour l'environnement Wordpress dans son ensemble.

@PericlesSouza @willgm Les règles s'appliquent aux deux. Les deux sont comptés exactement de la même manière, ce qui est assez malhonnête pour prétendre que ce n'est pas juste. S'accrocher à des CLI optionnelles ou à des sites Web suggestifs comptant des «j'aime» et des «étoiles» est futile. Même le stackoverflow est très subjectif et je n'ai même pas entendu parler du site "builtwith ..." jusqu'à aujourd'hui, et les statistiques CLI, eh bien, reflètent combien utilisent une CLI (la majorité ne le fait pas).

Les données de la source la plus évidente et la plus importante, reflétant des environnements de production réels dans les mêmes circonstances exactes, sont la seule statistique que vous n'aimez pas que j'obtienne, qui ne change pas la façon dont c'est.

Mais cette conversation ne devrait pas porter sur le cadre le plus utilisé, mais sur celui qui sera le mieux pour l'environnement Wordpress dans son ensemble.

Et je suppose que vous savez lequel est le mieux adapté. Vous pensez que les 400 000 personnes par jour qui reçoivent React off npm sont toutes dans l'erreur. Vue pourrait rivaliser seul, n'a pas vraiment besoin d'une foule se précipitant dans les trackers de problèmes.

@PericlesSouza @willgm Les règles s'appliquent aux deux. Les deux sont comptés exactement de la même manière, ce qui est assez malhonnête pour prétendre que ce n'est pas juste. S'accrocher à des CLI optionnelles ou à des sites Web suggestifs comptant des «j'aime» et des «étoiles» est futile.

Nan. React a 16 800 packages dépendants qui faussent les chiffres. NPM admet que tout ce qu'ils comptent comme téléchargement est un code de résultat 200 lors de l'appel d'une URL, à la suite d'une vérification de dépendance, ou d'un bot, ou d'un miroir, ou quoi que ce soit. Incidemment, ils disent également que la plupart des téléchargements en Chine, où Vue est très populaire, proviennent de miroirs et ne sont pas comptés.

À en juger par votre utilisation du langage - `` accrocher '', `` sites Web suggestifs '', `` futile '', vous n'avez pas de vrais arguments sur ce sujet, alors que, comme demandé par l'équipe, j'ai publié les points positifs de l'utilisation de Vue (voir ci-dessus ).

Compter les étoiles - d'autres font cela lorsqu'ils soulignent le succès de React, mais vous dénoncez leur valeur lorsqu'il est utilisé pour indiquer la popularité de Vue? Vous ne faites pas non plus mention du nombre beaucoup plus élevé de problèmes en suspens ( 571 ), et du nombre assez remarquable de demandes de tirage en suspens ( 178 ) toujours en attente pour React, ce qui par rapport à la réactivité plus élevée de la communauté Vue dans la correction de bogues et l'ajout de fonctionnalités est une source de préoccupation valable lors de la proposition d'utilisation de React.

Ce qui m'amène à:

Counting Likes - eh bien, c'était le but de ce fil, comme commencé par l'équipe et demandé à la communauté - je suppose que vous n'aimez tout simplement pas le résultat. Le voici encore, et c'est très concluant:

Nan. React a 16 800 packages dépendants qui faussent les chiffres.

@PericlesSouza Comment

Distinguer un paquet dans un tracker qui traite chaque paquet de la même manière n'a pratiquement aucun sens. D'un autre côté, compter les likes ne signifie rien de plus que cette communauté XY savait où voter.

@dcrmda

Je pense que ce qu'il veut dire, c'est que chaque fois que vous installez un package qui a une dépendance sur React, et qu'il frappe NPM pour vérifier les versions et les dépendances, ce NPM compte cela comme un download du package, même si ce n'est pas téléchargé.

Si c'est ce qu'il veut dire, alors il a tout à fait raison; il est explicitement indiqué par le NPM qu'ils le font; ils décrivent leur «méthodologie» comme «intentionnellement naïve» (ils mentionnent également que les robots et les miroirs peuvent fausser les chiffres car ils n'ont aucun mécanisme pour déterminer à quoi sert une demande, ils ne font que la compter). Et React a des packages plus dépendants, donc cet effet est plus prononcé.

Quant à beaucoup de paquets dépendants - oui React étant un framework plus ancien, il en a plus, et il en a besoin. Je développe à la fois avec React et Vue, et avec Vue, vous avez tendance à avoir besoin de moins de packages supplémentaires, car le noyau est assez complet, et le routeur officiel et Vuex suivent également la philosophie des faibles dépendances. Vue elle-même ne dépend d'aucun paquet, React en dépend de quelques-uns. Ils ont des approches différentes à cet égard.

Un autre exemple est que les gens ont tendance à utiliser un package d'intégration entre par exemple Bootstrap et React, ou à utiliser des bibliothèques telles que des composants stylisés, des noms de classe, etc. Avec Vue, vous n'en avez généralement pas besoin, bien que de tels projets existent également. Je trouve Vue beaucoup plus facile à utiliser car je peux avoir du CSS à portée de composant prêt à l'emploi sans bibliothèques ou configuration supplémentaires, et je peux écrire mes propres intégrations simples avec des frameworks CSS au besoin, plutôt que d'importer une bibliothèque d'intégration entière, puis d'essayer l'arbre -sachant les 75% dont je n'ai pas besoin.

@PericlesSouza vous avez manqué quelques éléments assez pertinents de votre message `` Pros of Vue '':

Emplacements nommés pour autoriser les composants de modèle réutilisables tels que les formulaires standard, les entrées, les mises en page, etc., ce qui est plus flexible que l'utilisation des enfants par Reacts.

Composants conditionnels avec la possibilité facultative de conserver l'état local sans détruire le composant non actif.

L'élément HTML 'Est' une syntaxe de composant Vue pour les modèles de chaîne, qui empêche le levage d'éléments HTML rendus qui entraînent un HTML invalide.

Flux de données à sens unique avec des accessoires, mais avec l'ajout d'un flux beaucoup plus simplifié 'emit' et 'event bus' pour notifier ou mettre à jour le frère ou le parent. Cela peut être utile pour l'intercommunication entre:

Plusieurs instances de Vue sur une page, contrôlant des régions spécifiques. Cette technique est utile pour les tableaux de bord dynamiques ou les widgets enfichables et la gestion de la mémoire.

Enregistrement de composants globaux et locaux et de directives personnalisées.

Filtres chaînables en plus des propriétés calculées.

Tout ce qui précède fait partie de la bibliothèque principale de Vue.

React est un excellent framework, et j'aime l'utiliser, mais personnellement, je pense que Vue est plus adapté à ce cas d'utilisation proposé.

@mcquiggd

Ouais, j'étais pressé et n'ai pas eu le temps de faire une liste complète des avantages de Vue.

Il est intéressant que vous ayez mentionné que React avait des dépendances car je remarque qu'il dépend de fbjs . J'ai mis l'accent sur les parties qui devraient déclencher l'alarme si les gens envisagent de réagir, avec la stratégie de licence à deux niveaux de Facebook tout en partageant le code entre des projets sous licence différente. Tout indice est inquiétant, surtout lorsque vous voyez la liste des projets qui en dépendent, mais qui ont des licences différentes.

https://www.npmjs.com/package/fbjs

https://www.npmjs.com/browse/depended/fbjs

Objectif

Pour faciliter le partage et l'utilisation de notre propre JavaScript par Facebook.

Remarque: _Si vous consommez le code ici et que vous n'êtes pas également un projet Facebook, préparez-vous à un mauvais moment_. _Cette bibliothèque est publiée avec nos cas d'utilisation à l'esprit et n'est pas nécessairement destinée à être consommée par le grand public. Nous n'accepterons probablement pas vos demandes de fonctionnalités à moins qu'elles ne correspondent à nos besoins.

571 Problèmes en suspens (!)

Il est maintenant 338. (J'ai passé quelques jours à les nettoyer.)

Au cours des derniers mois, l'équipe React était occupée à préparer une nouvelle version de React 16 , largement rétrocompatible. C'était notre plus grande version jamais publiée, donc nous n'étions pas en tant que réponse sur le suivi des problèmes, donc je suis désolé pour cela. Il s'avère que React 16 a également résolu un certain nombre de ces problèmes. :-)

Je tiens à souligner que la plupart de ces 338 problèmes restants sont des demandes de fonctionnalités et des discussions. Une recherche de l'étiquette de bogue me donne environ 60 problèmes. Et étant donné que l'écosystème React est plus grand que Vue pour le moment, il n'est pas surprenant que les gens se heurtent à davantage de cas extrêmes et d'incohérences et entament plus de discussions. Ils s'attendent également à ce que React remplisse davantage d'incohérences dans le navigateur, de sorte que beaucoup de bogues sont liés à une couverture manquante de ceux-ci. De plus, nous conservons la documentation dans le même référentiel, donc un certain nombre de ces problèmes concernent les documents.

J'espère que cela vous donne un aperçu des raisons pour lesquelles nous avons tendance à avoir un nombre de problèmes plus élevé que Vue.

Il est intéressant que vous ayez mentionné que React avait des dépendances car je remarque qu'il dépend de fbjs. J'ai mis l'accent sur les parties qui devraient déclencher l'alarme si les gens envisagent de réagir, avec la stratégie de licence à deux niveaux de Facebook tout en partageant le code entre des projets sous licence différente. Indiquer que tout est inquiétant, surtout lorsque vous voyez la liste des projets qui en dépendent, mais qui ont des licences différentes.

Malheureusement, c'est un FUD sans fondement, point final. Je ne sais pas quelle est votre motivation pour le diffuser, mais React a été renouvelé sous le nom de MIT, et cela inclut tout code dont React dépend (comme fbjs). Il n'y a pas de plan sournois ici.

Vous pouvez voir par vous-même que la licence fbjs a également été modifiée en MIT dans https://github.com/facebook/fbjs/commit/c69904a511b900266935168223063dd8772dfc40 cinq jours avant votre commentaire. La version React 16 qui est sortie il y a quelques jours ne contient pas un seul octet non MIT.

Le fait que d'autres projets dépendent de fbjs mais aient une licence différente est complètement hors de propos, tout comme il est indifférent que votre code d'application ne soit probablement pas MIT mais dépend de Vue.

PS Je pense que Vue est génial, et je ne veux pas pousser React sur qui que ce soit. Mais je veux m'assurer que nous fondons cette discussion sur des faits. :-) Nous sommes toujours ouverts aux critiques, et je suis sûr que Vue et React ont des choses à apprendre l'un de l'autre.

Tout cela est un discours passionnant.

Je dois demander - pourquoi un framework / une bibliothèque? Comme mentionné précédemment, le standard Web Component semble fournir ce que ReactJS, Vue et d'autres ont été conçus pour fournir (car le standard n'existait pas).

Vous pouvez utiliser des bibliothèques d'état comme Redux très bien avec des composants Web. Similaire aux bibliothèques de routage. SSR n'est pas aussi développé avec les composants Web, mais il y a aussi des gens qui y travaillent. La plus grande valeur de React réside en partie dans les diverses bibliothèques de support qui l'entourent - qui ne sont pas nécessairement perdues en utilisant la plate-forme.

Que vous apporte le framework XXX sur les composants Web de la plateforme?

Des discussions passionnantes en effet ...

La quatrième licence pour React, à ce jour.

1. À l'origine Apache 2.0. Ça aurait dû être bien, non? Quel était le problème?
2. Puis BSD + Brevets. Sans révéler ce que les brevets existent ou n'existent pas.
3. Puis de légères modifications, prétendument pour plaire à Google. Sans aucun détail sur pourquoi.
4. Maintenant MIT, avec refactoring non spécifié de React, mais pas pour les projets directement liés, tels que React Native, GraphQL, etc ... et la dépendance partagée avec la description publique «Pour faciliter le partage et l'utilisation de notre propre JavaScript par Facebook. Cela nous permettra principalement d'envoyer du code sans trop nous soucier de son lieu de résidence "

Apparemment, tout cela n'a rien à craindre du tout.

[modification supprimée par Tammie Lister: les légendes personnelles comme celle-ci sont inacceptables]

@PericlesSouza Vous pouvez affirmer que nous ne devrions pas nous faire confiance car les licences étaient déroutantes auparavant. C'est valable si c'est votre argument. Mais les licences ne devraient pas prêter à confusion maintenant.

React est le MIT.
Sa dépendance fbjs est le MIT.
Le code que React et React Native partagent (qui a été et continue d'être dans le dépôt React) est MIT.
React, y compris toutes ses dépendances, est le MIT.
Create React App n'est pas nécessaire pour utiliser React, mais c'est aussi le MIT.
Relay et graphql-js ne sont pas nécessaires pour utiliser React, mais ils sont également MIT.

Nous avons publié React 16.0 avec la nouvelle licence. Il est facile de vérifier cela.
Nous avons également publié une nouvelle version de React 15.x avec la licence MIT en tant que 15.6.2.
Nous prévoyons de publier toutes les futures versions de React sous la licence MIT également.

Ajoutez à cela, un autre employé de Facebook dans ce fil a admis que React (MIT pour 16? Que pour <16? 17+? Mieux vaut regarder ce package.json attentivement) et React Native share code, qui a nécessité une refactorisation (puis modifie son commentaire pour supprimer cette déclaration, après l'avoir citée).

Je suis cet ingénieur. (Sa.)

Vous avez commenté https://github.com/WordPress/gutenberg/issues/2733#issuecomment -331737418, puis j'ai répondu https://github.com/WordPress/gutenberg/issues/2733#issuecomment -331738521.

Voici le contenu original de nos deux commentaires, tel qu'enregistré dans mon client de messagerie:

Voici le contenu en ce moment:

Après avoir fait mon commentaire, vous avez modifié votre commentaire pour qu'il soit beaucoup plus long, y compris la question supplémentaire:

Quelles parties sont supprimées pour permettre à React d'être publié sous MIT?

qui ne figurait pas dans votre commentaire d'origine. Donc en réponse à votre modification, j'ai édité mon commentaire pour ajouter:

Nous ne supprimons pas des parties de React. La seule dépendance non-FB de React que je connaisse est l'attribution d'objet qui est également sous MIT.

Ce que vous avez ensuite jugé approprié de m'appeler dans le commentaire suivant. Comment oserais-je modifier mon commentaire pour répondre à une question que vous avez ajoutée dans votre modification. Je n'ai supprimé ni modifié aucune réclamation concernant le code de partage React et React Native.

-

S'il vous plaît, arrêtez de m'éclairer. C'est épuisant.

@youknowriad Auriez -vous l'

Si quelqu'un d'autre ici est encore légitimement préoccupé par la licence, n'hésitez pas à me contacter et je ferai de mon mieux pour clarifier.

Ce que vous avez ensuite jugé approprié de m'appeler dans le commentaire suivant. Comment oserais-je modifier mon commentaire pour répondre à une question que vous avez ajoutée dans votre modification. Je n'ai supprimé ni modifié aucune réclamation concernant le code de partage React et React Native.

Évidemment, j'ai répondu à votre modification, est-ce votre problème?

Il n'y a pas besoin de gaslighting, simplement une ouverture et une cohérence de la part de Facebook, de l'équipe de développement React et des licences, et comme l'indiquent les quatre modèles de licence dans Reacts, une durée de vie relativement courte, et votre article (actuel), cela fait malheureusement défaut.

Mettre brièvement les licences de côté: encore une fois, qu'est-ce que React fournit aujourd'hui qui est gagné au-delà des composants Web? En supposant que vous utiliserez toujours une sélection de bibliothèques de support dans les deux (par exemple Redux).

Avec les composants Web, WordPress peut créer de nombreux éléments qui peuvent être utilisés dans divers frameworks / bibliothèques frontaux. Cela permettrait aux utilisateurs finaux avec React, Vue, Angular ou tout autre frontal qu'ils utilisent de «déposer» des composants WordPress.

@sophiebits Je ne sais pas à quelle version de votre message répondre maintenant, alors je vais attendre et voir ce que cela deviendra finalement. C'est vraiment une situation assez similaire à celle de React.

@ Brian-McBride

Vous faites un bon point, et je crois qu'il a été soulevé plus tôt dans le fil - "pourquoi ne pas utiliser du javascript vanilla", basé sur des normes, entièrement conforme.

Hmm.

Remove references to PATENTS that crept in #11091
Merged  sophiebits  merged 1 commit into facebook:master from sophiebits:nopatentsagain a day ago

https://github.com/facebook/react/pull/11091

Comme je l'ai dit, faites très attention à votre contrôle de version si vous utilisez React.

Oui, nous avons accidentellement commis trois fichiers avec le mauvais en-tête, à partir de demandes d'extraction ouvertes avant le changement de licence. Aucun n'était dans une version publiée (ni ne pouvait l'être - l'un était des tests unitaires, deux faisaient partie du site Web).

Des erreurs se produisent. Nous l'avons corrigé lorsque nous l'avons découvert et j'ai ajouté un script à notre CI pour vérifier à l'avenir qu'aucune référence accidentelle n'est ajoutée. Vous pouvez le voir dans ce commit.

Une chose supplémentaire que je pense que les projets de logiciels libres devraient prendre en compte - Facebook bénéficie de l'utilisation de React.

Mais les valeurs de Facebook ne correspondent généralement pas à celles du mouvement du logiciel libre - tout, de la manipulation non éthique des utilisateurs aux attaques contre la neutralité du Net ("Free Basics"), incapacité à supprimer des données, incapacité à bloquer la collecte de données, censure, jardin clos , chambres d'écho, et plus encore.

[Facebook], c'est comme quand mon frère me faisait me donner des coups de poing et me demandait «pourquoi tu te donnes des coups de poing?» Puis il disait à ma mère que ce n'était pas sa faute.

En regardant Facebook pendant de nombreuses années, je me suis de plus en plus rapproché de la conclusion que je ne veux plus soutenir cette entreprise de quelque manière que ce soit, donc je n'utilise personnellement pas de logiciel FB chaque fois que des alternatives existent.

J'ai lu un livre sur React et il a fière allure du point de vue de la programmation - mais les alternatives sont également excellentes, et elles ne viennent pas avec le bagage de soutenir Facebook.

Je pense que les projets de logiciels libres devraient toujours préférer les bibliothèques de logiciels libres indépendantes chaque fois qu'elles sont disponibles. Il existe de nombreuses alternatives intéressantes pour WordPress, notamment Vue, les composants Web, Ember et Mithril. Vue a un énorme soutien dans la communauté PHP et n'a aucun problème éthique qui lui est attaché, il semble donc que cela conviendrait bien. Si c'est juste pour le tableau de bord, cela vaut peut-être la peine de jeter un coup d'œil à quelque chose d'encore plus intéressant que JavaScript: Elm .

Il ne devrait pas s'agir de ce qui est à la mode ou de ce qui est cool en ce moment, mais de ce qui offre le plus de liberté technologique aux générations futures - directement ou indirectement.

Juste une autre pensée à considérer ...

Merci à tous ceux qui ont exprimé leurs opinions tout en essayant d'avoir une conversation respectueuse. Je tiens également à remercier tout particulièrement @sophiebits , @gaearon , @ blake-newman, et tous les autres représentants de projets qui ont gentiment passé leur temps à répondre aux questions. Vos connaissances sont grandement appréciées et toujours les bienvenues.

La conversation est depuis passée aux réunions JavaScript dans le canal Slack # core-js, il y a un bon résumé ici . Si vous souhaitez participer à ces discussions, nous vous invitons à vous y joindre. Alternativement, nous avons deux approches de l'interopérabilité qui pourraient utiliser des contributions, des tests et des commentaires: # 2463 et # 2791.

Et avec cela, ce fil a suivi son cours. Nous verrouillons le problème, mais nous vous encourageons à poursuivre la conversation dans les lieux mentionnés ci-dessus.

Ce fil a donné lieu à de bonnes discussions, mais certains d'entre eux ont montré un comportement inacceptable et ont été modifiés. Il est important de se rappeler que https://wordpress.org/about/etiquette/ s'applique à tout projet WordPress et nous ne tolérerons pas les violations ou celles qui les commettent. Merci à tous ceux qui ont contribué à la conversation de manière prévenante et respectueuse.