Gutenberg: Auswahl des JavaScript Frameworks für Gutenberg (~ WordPress)

Meine Stimme ist bei VueJS

Ich wähle VueJS

Vue hat eine großartige Community und sollte die erste Wahl sein.

Angular JS

Ich werde für VueJS stimmen. Wie oben beschrieben, ist es ein Anfänger freundlich und erfolgreich mit Laravel verwendet. Das macht es zur perfekten Wahl.

Ich werde auch für Vue JS stimmen

Bitte beachten Sie, dass das bloße Schreien von "Ich bevorzuge Vue" oder "Ich möchte XY" bei der Entscheidungsfindung hier nicht wirklich hilfreich ist. Wenn Sie abstimmen möchten, würde ich vorschlagen, Emoji-Reaktionen oder ähnliches zu verwenden, anstatt einen Thread zu überladen, der möglicherweise als Ort für die Dokumentation von Ergebnissen bei der Bewertung verschiedener Frameworks dienen könnte.

Ich werde mit Vue gehen. Es ist einfacher zu lernen und sich anzupassen. Außerdem ist es weniger umstritten als Preact.

Ist das nicht das Problem der "Abhängigkeit von Schlüsselpersonen", das von Zeit zu Zeit auftaucht, was jedes WordPress-Feature-Plugin oder jede unbekannte Technologie ist? Koop baute das alte Medienhandling auf, Weston hat eine Menge Customizer-Arbeit geleistet, Matías und einige andere arbeiten an Gutenberg. Fast jede größere Änderung an WordPress, die in den letzten Jahren vorgenommen wurde, hat eine winzige Gruppe von Leuten daran gearbeitet oder es verstehen.

Ich könnte das falsch sehen, aber "Schlüsselpersonenabhängigkeit" für jede Wahl scheint wie ein roter Hering. Mit der Adoption wird die Abhängigkeit von Schlüsselpersonen vollständig beseitigt. WordPress war einst auch ein Abhängigkeitsprojekt für Schlüsselpersonen (Mike und Matt). Ich denke, das ist ein schwaches Argument, um eine Adoption zu vermeiden.

Auch hier könnte ich völlig falsch darüber nachdenken, aber es ist ein allgemeiner Gedankengang, der von Zeit zu Zeit auftaucht und dessen scheinbar hohe Bedeutung nicht versteht.

Um den Kommentar von @swissspidy zu ergänzen, kann es auch

Ich würde für VueJS stimmen! Es ist bei weitem am einfachsten, sich von der Community anzupassen.

Ich denke, Webkomponenten (ohne Polymer, aber mit lit-html oder ähnlichem, wenn ein virtuelles DOM benötigt wird) sollten ernsthaft in Betracht gezogen werden. Die Nutzung der Plattform und der Standards ist weitaus besser als jede Bibliothek oder jedes Framework! Ermöglicht eine robuste und zukunftssichere Komponentenstruktur, die natürlich mit allen Frameworks kompatibel ist. (Vue, Angular, React - derzeit jedoch in unterschiedlichem Maße: 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

Gerne helfe ich diesem Projekt bei Bedarf beim Ausprobieren von Vue oder Webkomponenten.

Lesen Sie auch PR # 2463 für Gutenberg _ "Framework-agnostische Blockinteroperabilität (Vanilla, Vue)" _

Ich würde aus mehreren Gründen vorschlagen, sich zu Vue.js zu neigen.

1. Nachgewiesene Erfolgsbilanz im PHP-Framework Laravel.
2. Scheint einfach zu erlernen und zu adoptieren, damit mehr Menschen dazu beitragen können.
3. Wenn wir uns von React entfernen, können wir eine saubere und eindeutige Abkehr davon vornehmen (die Verwendung von Preact scheint in gewissem Sinne daran festzuhalten (React)).

Nur meine Meinung, aber es scheint die bessere Wahl zu sein und viele andere Leute scheinen Vue zu bevorzugen, und es ist zumindest etwas, das man sowieso in Betracht ziehen sollte.

Vue scheint eine größere Dynamik und eine bessere Unterstützung durch die Community zu haben als Preact. Es löst mehr Probleme (weil es mit staatlichem Management einhergeht) und hat eine sanftere Lernkurve. Die Dokumentation ist _exzellent_.

Mein Anliegen bei Preact ist, dass es zu ähnlich ist wie React, um sich rechtlich sicher zu fühlen (Reacts Patente könnten Preact abdecken), und zu anders als React, um ein einfacher Port zu sein (es gibt genug Unterschiede, um Hilfsbibliotheken, Plugins usw. zu beschädigen).

Vue den ganzen Weg Baby !!

• [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 -> Hier
Wäre absolut begeistert von WordPress dev wenn Vue.js 🖖

Vue hat im Laufe der Zeit eine großartige Community sowie regelmäßige Updates / Upgrades des Frameworks entwickelt.

PS. Tritt https://chat.vuejs.org bei, um eine großartige Community-Erfahrung zu machen. Einige wirklich dopeass-Entwickler dort :)

@jbreckmckye Ich möchte das Gespräch nicht entgleisen, aber verstehen Sie, worum es in der Patentklausel geht? Es geht darum, Facebook vor Patentklagen anderer Unternehmen zu schützen. Nehmen wir zum Beispiel an, mein Unternehmen stellt intelligente Kühlschränke her und wir verwenden Reagieren in der Benutzeroberfläche. Nehmen wir an, wir haben ein Patent darauf, und dann beginnt FB, dieses Patent zu verletzen. Wenn wir klagen, können wir nicht mehr reagieren.

Es hat nichts mit Patenten zu tun, die reagieren (was ich nicht einmal sicher bin, ob Facebook dies getan hat ... sonst wären Preact, Vue und alle anderen mit einem ähnlichen Rahmen inzwischen verklagt worden).

Als Kernmitglied von Vue.j möchte ich das Problem des Busfaktors ansprechen. Wir wissen, dass dies derzeit ein sehr angesprochener Punkt ist. Wir ergreifen jetzt Maßnahmen, um einige der Bedenken auszuräumen.

1) Vue.js Organisationskonto für npm, damit wir einfacher als Team veröffentlichen können
2) Interne Verwaltung von Details, um den Betrieb aufrechtzuerhalten (Websites usw.)
3) Initialisierung eines offenen Kollektivs, um Mitwirkende zu locken und die wachsende Gemeinschaft zu unterstützen. https://medium.com/the-vue-point/vue-is-now-on-opencollective-1ef89ca1334b
4) Das Vue-Ökosystem ist schnell gewachsen, und immer mehr Beiträge zum Kern-Repository kommen von der Community selbst. https://www.youtube.com/watch?v=993X1kiisFE
5) Wenn Sie sich die offiziellen Vue-Repositories ansehen, können Sie sehen, dass viele von ihnen jetzt mehr von anderen Kernteammitgliedern als Evan stark gepflegt werden

Insgesamt wächst Vue.js schnell und der 'Busfaktor' hat sich deutlich verringert. Wie @philiparthurmoore feststellt, wird Evan immer eine große Beteiligung haben, und das ist gut so.

Es scheint hier viele VueJS-Fans zu geben. Hat jemand tatsächlich eine große Codebasis von React nach Vue migriert? Wie ist der Migrationspfad?

Soweit ich sehen kann, scheint Preact eine viel pragmatischere Wahl zu sein, da es API-kompatibel mit React ist. Während die Migration nach Vue ein viel umfangreicheres Umschreiben erfordern würde.

@patrickgalbraith Das ist eigentlich der falsche Grund, Preact in Betracht zu ziehen. Es sollte nach seinen Vorzügen beurteilt werden und nicht, weil es einfacher ist, dorthin zu migrieren. Ich kann die folgenden Probleme mit Preact sehen

• Kleinere Community im Vergleich zu VueJS
• Code-Gerüche - Der Übergang zu einer sehr ähnlichen Bibliothek kann zu schlechten Praktiken führen (aus dem offensichtlichen Grund, dass dies der schnellere Weg ist).
• Bei Preact zu bleiben ist sowieso wie bei React zu bleiben (lesen Sie es in einem Thread)

Ich habe Preact nur in begrenztem Umfang verwendet, also denke ich genau das.

@ Blake-Newman Danke, dass du vorbeigekommen bist und das geklärt hast. 💯

Es sollte nach seinen Vorzügen beurteilt werden und nicht, weil es einfacher ist, dorthin zu migrieren.

Jep. Dies ist eine langfristige Entscheidung.

@patrickgalbraith Wenn das ganze Projekt abgeschlossen wäre, würde ich das als faires Argument betrachten. Da wäre es ein Migrationsstück, um Lizenzprobleme zu vermeiden.

Da sich das Projekt noch in einem frühen Stadium befindet, ist es als @ahmadawais weniger ein Problem.

Auch Vue, React und Preact haben sehr ähnliche Paradigmen. Sie können leicht zwischen den beiden wechseln, es wird Unterschiede geben.

Es gibt auch, obwohl in diesem Fall wahrscheinlich nicht ganz praktisch, Werkzeuge, die den Migrationsfrieden unterstützen können. https://github.com/SmallComfort/react-vue

Obwohl hier nicht dieselben Tools verglichen werden, werden in diesem Artikel wichtige Punkte angesprochen. https://medium.com/unicorn-supplies/angular-vs-react-vs-vue-a-2017-comparison-c5c52d620176

@ Blake-Newman ist es wirklich nur ein frühes Stadium, wenn man bedenkt, dass es mehr als 6 Monate in der Entwicklung ist? Denken Sie auch daran, dass Calypso ebenfalls über zwei Jahre alt ist.

Wie auch immer, ich bin mir sicher, dass es kein Problem sein wird, wenn man bedenkt, dass es einfach ist, zwischen React und Vue zu wechseln. Ich freue mich darauf, die Pull-Anfrage dafür zu sehen.

Schablone sieht auch vielversprechend aus.

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

Meiner Meinung nach sind diese beiden Punkte ein starkes Argument für Vue:

• Anfängerfreundlich und ..
• Riesige Menge an Community-Unterstützung

Beide sind meiner Meinung nach zwei der Grundpfeiler des WordPress-Projekts.

Ich könnte allein sein, aber ich habe Evans Patreon in den letzten sechs Monaten ziemlich genau beobachtet, und es lautete, dass er mehr Arbeit übernehmen müsste, wenn er keine Finanzierung erhalten könnte.

Es ist ein echtes Risiko, wenn ein Projekt nur eine geringe Finanzierung hat UND es im Grunde genommen von einer Person geschrieben wurde (Stand: <vor sechs Monaten). Seine Patreon-Zahlen sind in letzter Zeit tatsächlich gesunken. Wenn der Hauptdarsteller sagt, dass er möglicherweise nicht in der Lage ist, daran zu arbeiten, wenn die Finanzen nicht in einer Reihe stehen, dann sind die Finanzen ein sehr reales Risiko. Die Rahmenentscheidung eines großen, langfristigen Projekts, das davon abhängt, ob ein (großartiger) Entwickler SF-Miete zahlen kann, ist eine große Sache.

Natürlich könnte Vue von anderen Unternehmen großzügig unterstützt werden, aber das ist schwer zu wissen.

Die Übernahme durch die Community garantiert auch keine Langlebigkeit des Frameworks, Leute. Wenn Sie es nicht bemerkt haben, "sterben" Frameworks die ganze Zeit.

Trotzdem bin ich beeindruckt, dass ein Mitglied des Vue-Kernteams aufgetaucht ist, um das Problem mit dem einzigen Mitwirkenden / dem Busfaktor sogar namentlich anzusprechen, und habe einige Gründe angegeben, warum das Problem mit einzelnen Entwicklern möglicherweise weniger problematisch ist. Aber es war in der jüngeren Vergangenheit ein echtes Problem.

Ich stimme für Vue

• einfache API / Sie können die grundlegendsten Dinge unter einer Woche lernen
• einfache Flussmittelimplementierung über vuex
• schnelle Ergebnisse: P.
• wachsende Gemeinschaft
• MIT

Eine weitere Abstimmung für Vue aus allen oben genannten Gründen. Ich entschuldige mich bei allen, die E-Mail-Benachrichtigungen aktiviert haben!

@ michaelbdavidson7 , Vue wird letztendlich Evans Input haben und die Patreon-Kampagne sollte ihn dabei unterstützen, mehr großartige Vue-Arbeit zu leisten. Er bekommt nicht genug über Patreon und übernimmt andere Arbeiten. Ich glaube nicht, dass er Vue gefährdet. Wie @ blake-newman (ein zentraler Vue-Mitarbeiter) vorschlug (und Evan selbst vor ein paar Monaten), ist Vue nicht mehr nur von einer Person abhängig. So sehr WordPress nicht von einer Person abhängig ist. Wir haben Matt, ja, aber WordPress kann in einigen Inkarnationen ohne Matt fortgesetzt werden (sorry Matt;)). Gleiches gilt für Vue (sorry Evan;)).
@ahmadawais, die meiner Meinung nach auch in Bezug auf "Schlüsselpersonenabhängigkeit" nicht korrekt sind.

Wenn dieses Ziel erreicht ist, kann ich weniger Zeit damit verbringen, über private Monetarisierungskanäle nachzudenken (z. B. Support- / Beratungsverträge zu übernehmen) und stattdessen mehr an Inhalten arbeiten, die der gesamten Vue-Community zugute kommen ...

^ Dieses Ziel wurde nicht erreicht und ist nicht einmal nah. Angenommen, er meinte, was er sagte, würde er vielleicht immer noch über Vertragsabschlüsse nachdenken, und wenn sich dies ändert, sollte dies als eine sehr junge Entwicklung angesehen werden. Es ist immer noch da oben. Wenn die Schlüsselperson einen Vertrag zur Zahlung der Miete abschließt, besteht das Risiko, dass sie nicht weiter an dem Framework arbeitet. Wenn sich dies ändert, hat sich dies erst kürzlich geändert.

Alle von euch, die nur Frameworks mit Namen schreien, haben in den letzten Jahren nichts gelernt, lol.

@ michaelbdavidson7 Das Ziel wurde erreicht, Evan bei der Vollzeitarbeit zu unterstützen. Das zusätzliche Ziel ist es, ihn weiter und teilweise in der Gemeinschaft zu unterstützen. So entstand die offene kollektive Kampagne, die ausschließlich dazu dient, die Gemeinschaft zu unterstützen.

Ich möchte auch darauf hinweisen, dass die Patreon-Kampagne nicht die einzige Einnahmequelle über Beiträge ist. Leider ist Patreon nicht für jedes Unternehmen geeignet, um Sponsoren zu werden. Somit werden einige Beiträge getrennt bezahlt und in Rechnung gestellt.

Der Grund, warum die Zahl gesunken ist, ist, dass einer der Sponsoren aus China stammte und es eine Begrenzung für den Geldbetrag gibt, der in einem Jahr aus China als Aufwand verbucht werden kann. Dies ist nur vorübergehend und wird hoffentlich wieder unterstützt.

Die anderen Einnahmequellen, die Evan durch Workshops erhält, sind nicht nur für die Gemeinde hilfreich, sondern auch für ihn. Auf diese Weise kann er direkt darauf aufmerksam werden, wie die Bibliothek genutzt wird und wird. Es ist also nicht so schlimm, wie es scheint.

Vue ist nachhaltig und ich spreche nicht für Evan, aber ich bin sicher, dass er mit der aktuellen Finanzsituation sehr zufrieden ist.

Eine Sache, die ich an React sehr schätzte, war die Dokumentation zur Barrierefreiheit . Ich denke, dies ist etwas, das Sie beachten und berücksichtigen sollten, wenn Sie über neue Frameworks nachdenken. Es gibt hier erwähnte Barrierefreiheitsprinzipien, die für jede defensiv geschriebene Web-App gelten. Eine rahmenspezifische Dokumentation kann jedoch hilfreich sein.

Vue.js hat ein offenes Problem für die Barrierefreiheit . Ein kurzer Blick in Preact und ich sehe nicht viel; Ist es sicher anzunehmen, dass die Dokumentation von React gilt?

Letztendlich wäre es großartig, ein Framework zu haben, das programmatische Tests für a11y einfach und automatisch macht, damit wir die meisten a11y-Fehler und -Warnungen beseitigen können.

Wenn Sie nur aufgrund der Lizenz einen einfachen Übergang wünschen, können Sie InfernoJS in Betracht ziehen. https://github.com/infernojs/inferno bietet nahezu dieselbe API mit geringerem Platzbedarf und schnellerer Laufzeit. Das MIT ist lizenziert. Ich bin einer der Inferno-Betreuer und könnte beim Übergang helfen.

@ Havunen danke fürs

Für den Kontext wurde Infernos Autor von Facebook engagiert

Ich stimme für markoJS http://markojs.com/

Gutenberg verwendet einige neue React 16-Funktionen, z. B. Portale und möglicherweise Fragmente , die sowohl Inferno als auch Preact nicht unterstützen. Dies kann bei der Diskussion über reaktionsähnliche Bibliotheken berücksichtigt werden, wenn die Verwendung dieser Funktionen für gutenberg von entscheidender Bedeutung ist.

Ich würde DIO 8 vor allem deshalb empfehlen, weil es an dieser Stelle in Bezug auf die API React 16 am nächsten kommt.

Das heißt, es könnte ein gutes Neugierdexperiment sein, Gutenberg als Aliasing für die erwähnten reaktionsähnlichen Bibliotheken einzurichten und zu prüfen, ob sie ohne Änderungen / Probleme für jeden funktionieren, der dies wünscht.

Ich bin mir nicht sicher, ob sie genau gleich sind, aber für Portale gibt es ein Vue -Portal, das von @LinusBorg , einem der Mitglieder des

@youknowriad Ich wurde von Facebook eingestellt. @ Havunen und das Team hinter Inferno machen einen tollen Job ohne mich. Die Arbeit, die sie an Inferno machen, ist großartig und das Projekt ist es wert, Inferno zu besuchen, wenn Sie eine Chance bekommen :)

Ich bin einer der Autoren von Marko.js und möchte Marko.js zur Prüfung in den Ring werfen. Einige unserer Community-Mitglieder haben sich an uns gewandt und uns auf dieses GitHub-Problem hingewiesen. Marko.js verfügt über eine Open Source-freundliche MIT-Lizenz, die zum Aufbau von eBay.com verwendet wird, und eine starke und wachsende Community. Es bringt eine Reihe guter Ideen von React und Vue ein, aber wir haben uns viel Mühe gegeben, um die Dinge einfacher und schneller zu machen (durch Optimierungen zur Kompilierungszeit), und wir haben die Boilerplate entfernt, wo immer wir konnten. Ich wollte nur einige der folgenden Funktionen hervorheben:

UI-Komponenten

Das Komponentenmodell von Marko ist konzeptionell dem von React sehr ähnlich (Eingabe, Status, Ereignisbindung, Lebenszyklusereignisse, virtuelles DOM-Rendering, DOM-Diffing / Patching usw.). Ein Übergang in Calypso würde nicht viel kognitiven Aufwand erfordern. Marko unterstützt auch Single-File-UI-Komponenten. So sieht eine Marko-UI-Komponente aus:

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>

Syntax

Marko verwendet kein JSX, sondern eine Obermenge von HTML, die JS-Ausdrücke unterstützt. Es ist HTML sehr ähnlich, aber nicht vollständig auf HTML beschränkt, wie es Vue ist. Dies bietet eine schönere Syntax für Dinge wie Schleifen und Bedingungen und macht klarer, wo Ausdrücke im Vergleich zu einer Standard-HTML-Zeichenfolge verwendet werden. Wir sind der Meinung, dass die Vorlagen von Marko.j äußerst lesbar und wartbar sind (Marko unterstützt auch eine präzise, ​​auf Einrückungen basierende Syntax).

Serverseitiges Rendern

Ich weiß nicht, wie wichtig es für WordPress ist, aber Marko unterstützt auch hochleistungsfähiges serverseitiges Rendern unter Node.js mit Unterstützung für asynchrones und Streaming-Rendering.

Weiterführende Literatur:

• Marko vs React
• Serverseitiges Rendering-Shootout mit Marko, Preact, Rax, React und Vue
• Warum ist Marko schnell?
• 10 fantastische Marko-Funktionen
• Meetup: Erstellen der Benutzeroberfläche - ein Vergleich von React, Vue und Marko (vom Marko-Ersteller) - Video | Folien

Ich stimme für Marko !! 🙂

Wenn jemand aus dem WordPress-Team (@ahmadawais? @M? @Swissspidy?) Einen kurzen Chat haben möchte, um Fragen zu Marko zu beantworten, würden wir, das Marko-Team, dies gerne tun. : call_me_hand: 😸

@Ich habe dies auf @ms Blog kommentiert, wollte es aber hier in einer öffentlicheren Form veröffentlichen:

Ich empfehle das Ember-Ökosystem, einschließlich Ember und Glimmer.js.
Für kleinere Webkomponenten wie Drop-In-Editoren und andere Inhaltsverhalten bietet Glimmer eine großartige Erfahrung und erstellt Drop-In-Web-Komponenten, die außerhalb eines Frameworks ausgeführt werden können.

Bei größeren Projekten wie Guttenberg und Calypso, bei denen Routing, komplexes Statusmanagement, Zugriffskontrolle, Content Management und mehr zum Einsatz kommen: Ember bietet das beste Toolset und Ökosystem
Mit einer großen Anzahl von Mitwirkenden: Embers festgelegte Muster, Addons und Build-Systeme tragen dazu bei, dass Anwendungen bei der Skalierung von Anwendungen leistungsfähig und wartbar bleiben.
Ember Engines und In-Repo-Addons helfen dabei, optionale Teile der Anwendung modular und für Endbenutzer installierbar zu halten.

Ember wird stark von anderen Content-Management-Systemen verwendet, und diese Bemühungen können darauf aufgebaut, daraus gelernt und geteilt werden.
Wie in einem früheren Kommentar in @ms Blog erwähnt, verwendet Ghost Ember als Administrator und Editor, aber Ember wird auch bei Drupal Headless-, Cardstack- und Content-Unternehmen wie Conde Nast , Bustle und anderen verwendet.
Dies bedeutet, dass allgemeine Funktionen wie Tag-Listen, komponentenbasierte Editoren (insbesondere der Mobiledoc-Editor ) und mehr als Teil des Ember Addon-Ökosystems verfügbar sind.

Aus Community- und Entwicklererfahrung passt Ember am besten zum Wordpress-Ökosystem (als Entwickler, der über 5 Jahre in Wordpress gearbeitet hat).
Ember verfügt über viele bewährte Methoden, die entweder integriert, gut dokumentiert oder über Addons verfügbar sind. Dies reduziert die Frage, ob dies mit meiner App funktioniert, und hilft, mögliche Sicherheits- oder Leistungsfehler besser zu reduzieren.
Ember basiert auf anpassbaren Abstraktionen, was bedeutet, dass die Komplexität von Endentwicklern abstrahiert werden kann und der Umfang von schwierigem Code begrenzt werden kann, um die Anpassung einfach und unterhaltsam zu gestalten.
Ember-Addons stimmen eng mit Wordpress-Plugins und -Themen überein, da sie automatisch erkannt werden und standardmäßig standardmäßig konfiguriert sind. Sie können jedoch weiter an die Anforderungen des Endbenutzers angepasst werden.
Für Ember Addons gibt es ein Kurationswerkzeug namens Ember Observer, mit dem Sie die beliebtesten, am besten gewarteten und stabilsten Addons finden können.

Calypso und Guttenberg sind große, ehrgeizige Projekte mit ausgereiften Bedürfnissen. Die Ember-Community verfügt über ausgereifte Lösungen für Barrierefreiheit, Internationalisierung und andere Anforderungen moderner Webanwendungen.

Ich bin Teil des Ember.js-Lernteams und arbeite eng mit den wichtigsten Mitwirkenden zusammen. Ich würde gerne mit anderen Ember-Teammitgliedern darüber sprechen oder ein Gespräch darüber führen, wie Ember und Glimmer Ihren Anforderungen entsprechen könnten.

Ich habe festgestellt, dass React-Portale erwähnt wurden, und möchte ein weiteres 2 ¢ hinzufügen, dass Ember ein gut gepflegtes Addon namens Ember Wormhole hat , um diese Funktionalität bereitzustellen, und viele Addons, die darauf aufbauen, um Funktionen wie Dialoge und Änderungen am Dokumentenkopf bereitzustellen , und mehr.

Ich würde für Marko stimmen, da es native Unterstützung für asynchrones Rendern und schnelle serverseitige Leistung bietet. !!!

@ patrick-steele-idem & @mlrawlings - danke fürs

Ich werde mehr graben.

Ich habe mit Ember.js sowohl in einer sehr großen Unternehmensorganisation gearbeitet, in der Apps in anderen Apps ausgeführt wurden, als auch bei einem sehr kleinen Start mit kleinen eigenständigen Anwendungen. Die starken Meinungen und Konventionen von Ember.js haben dazu beigetragen, eine produktive und wartbare Codebasis aufrechtzuerhalten, wenn Teams und Anwendungen wachsen. Es ermöglicht nicht nur die Möglichkeit, Code (über Engines oder Addons) projektübergreifend zu teilen, sondern ermöglicht es auch einem Entwickler, der die Konventionen gelernt hat, produktiv zu sein und zu so ziemlich jeder Ember-Anwendung beizutragen.

Der größte Vorteil von Ember war seine Stabilität ohne Stagnation. Ohne unsere Vorlagen ändern zu müssen, haben wir mit der Veröffentlichung der neuen Version von Ember, die die Rendering-Engine unter uns komplett überarbeitet hat, enorme Leistungsvorteile erzielt. Die Abstraktionsebenen scheinen genau richtig für moderne Rich-Webanwendungen zu sein, die möglicherweise wachsen und in die ferne Zukunft skaliert werden müssen.

Wenn Änderungen erforderlich sind, ist die Migration ein zentrales Anliegen, und Anleitungen zur Ablehnung helfen bei jedem Schritt des Weges (zuletzt mithilfe von JavaScript AST / CST-Transformationen, um Anwendungen automatisch zu aktualisieren).

Andere beliebte Webanwendungen, die Ember verwenden, das von @rtablada nicht erwähnt wird, sind Twitch.tv , das Heroku-Dashboard , Travis CI und Discourse .

@SaladFork Vielen Dank für das Update. Ich habe zunächst hauptsächlich Unternehmen im Bereich Content Management benannt.

Einige Beispiele für Open Source-Ember-Anwendungen in großem Maßstab sind:

• Travis CI
• Hospital Run - Ein EMR-System (Electronic Medical Record), das für den Offline-Einsatz entwickelt wurde, insbesondere bei geringer Konnektivität in Afrika
• Geist

Ich bin mir nicht sicher, wie viel er ins Detail gehen kann, aber ich pinge @tehviking an, um zu sehen, ob er einen Teil des jüngsten Übergangs seines Teams von einer App von React zu Ember teilen kann.

Ich würde Marko für seine Leistung, Flexibilität und sehr klare, leicht verständliche Syntax wählen!

+1 auch für Marko. Nachdem ich die Front-End-Arbeit gut erledigt hatte, bevor ich anfing, Haare zu verlieren und grau zu werden (wie vor langer Zeit), war es das Front-End-Framework / die Front-End-Bibliothek, nach der ich all die Jahre gesucht habe. Das ist ein großer Grund, warum ich auch gerne bei eBay mit @ patrick-steele-idem & @mlrawlings arbeite .

Marko JS hat meine Stimme. In Anbetracht der Benutzerfreundlichkeit und Leistung extrem unterschätzt.

Ich liebe Marko-Widget zusammen mit effizientem Marko. einfach herausragende und schlanke Rahmenbedingungen. Sein Weg schneller als andere Frameworks. Benchmark ist da

Ich stimme für MarkoJS, wir waren seit vielen Jahren ein Lenkerladen.

Als wir den strategischen Schritt unternahmen, auf Mikrodienste umzusteigen und eine komponentenbasierte Architektur für unsere Plattform zu ermöglichen, suchten wir nach dem richtigen Framework, um ein Gleichgewicht zwischen serverseitigem Rendering und Client-Rendering zu erreichen. Wir sind eine Plattform, die in 6 verschiedenen Märkten klassifiziert ist, einschließlich aufstrebender Märkte wie Südafrika und Mexiko, in denen Daten ein großes Problem darstellen und wir eine Website benötigen, die die Browsing-Anforderungen des Benutzers auf Geräten, die einige Jahre alt sind und auch verwenden, wirklich berücksichtigt weniger Daten. Außerdem navigiert der Benutzer auf der Website hin und her, bis er einen Artikel findet, den er gerne kauft. Dies bedeutet, dass beim Navigieren des Benutzers ein sehr schnelles Server-Rendering erforderlich ist.

Nach sorgfältiger Überlegung haben wir MarkoJS mit der Tatsache ausgewählt, dass es Folgendes unterstützt:

1. Schnelles Server-Rendering mit guter Serverleistung
2. Schiebt das erste Byte so schnell wie möglich heraus
3. Möglichkeit, kleinere Komponenten zu erstellen und asynchron zu rendern, sobald Daten bereit sind
4. Möglichkeit zum Erstellen einer Plug-and-Play-Komponentenarchitektur
5. Maximieren Sie das Client-Rendering mit derselben oder einer besseren Architektur von React / Vue.
6. Komponentengesteuerte Tests, die nicht nur zum Testen des Renderns, sondern auch zum Status der Komponente verwendet werden können

(Eine Erfolgsgeschichte von eBay Classifieds)

+1 für Angular (NICHT AngularJS).

Die Angular-CLI ist bei weitem die beste aller Frameworks, und mit Migrationsplänen für eine nahtlose Migration zwischen Versionen würde sie sehr gut passen.

Plus Angular ist im Unternehmensbereich sehr beliebt, wo WordPress etwas Liebe gebrauchen könnte, wenn WordPress als Plattform für Berater und Freiberufler weiter wächst und nicht mehr nur ein Wettlauf nach unten ist.

Es hat eine robuste Community von Entwicklern aller Ebenen. Das Kernteam ist immer großartig, wenn es darum geht, ob es für Google arbeitet oder nicht. WordPress ist größtenteils (für die meisten High-Level-Entwickler) eine Community, an der sie beteiligt sind. Ich möchte also sagen, dass Angular in Bezug auf die Community eine großartige Passform hat

Ich habe kürzlich einen Vortrag über Vue in vom Server gerenderten Umgebungen gehalten ( Folien hier ). Nachdem ich in den letzten Monaten mit Vue in einer .NET-Umgebung gearbeitet habe, bin ich überzeugt, dass es keine andere Option für die Arbeit in Umgebungen gibt so wie das. Sie erhalten eine wirklich hervorragende Kombination aus der Möglichkeit, Komponenten zu komponieren, die für eine intensive Interaktivität in JS gezogen werden müssen, während das Back-End weiterhin die Kontrolle über die Site behält.

Das heißt, es ist ziemlich perfekt, um auf dem aufzubauen, was WordPress jetzt hat. Für jede andere vom Server gerenderte JS-Bibliothek wird höchstwahrscheinlich ein Knoten benötigt. Vue nicht; Sie können eine Komponente wie <gutenberg-editor> registrieren und WordPress buchstäblich <gutenberg-editor> im HTML senden lassen. Vue kann den von WordPress gesendeten HTML-Code verwenden, um die Seite zu booten. In dieser Hinsicht ähnelt es ein bisschen Webkomponenten und erfordert keine weitere BE-Technologie, um Server-Rendering zu erhalten.

Dies ist einer der Gründe, warum ein Framework wie Laravel es als Standard gewählt hat: Es lässt sich sehr einfach in Backends ohne Knoten integrieren. Ich denke, WordPress sollte es aus den gleichen Gründen übernehmen.

Ich habe für Vuejs gestimmt .
Der gleiche Fall mit @borantula zu seinem Kommentar

Mein CTO stellte Vuejs dem Team vor - Neulinge im Front-End, und sie kommen schnell dazu, jetzt sind sie mit Vuejs zufrieden. Mein Team verwendet WordPress in vielen Projekten.
Derzeit verwenden wir Vuejs und Custom Element, um das Front-End für ein Projekt zu erstellen, das WordPress im Backend verwendet. Es funktioniert sehr reibungslos.

Wie @ blake-newman und Evan gesagt haben, hängt Vuejs nicht mehr von einer einzigen Schlüsselperson ab, so dass gesagt werden kann, dass die von @ahmadawais erwähnten CONS nicht mehr existieren.

MARKO funktioniert gut in unserer Web-App. Progressives Rendern funktioniert wie ein Zauber.

Ich kann nichts über Preact oder MarkoJS sagen (stark auf Kommentare verwiesen), aber ich kann für Vue sprechen, als ich es vor einem Jahr unserem Team vorstellte (das damals hauptsächlich an php + jQuery arbeitete) und es ihr Verständnis von Javascript allmählich veränderte. aus dem jQuery-Geisteszustand herauskommen.

Ich denke, es wäre eine gute Wahl, nicht nur für Gutenberg, sondern auch für das langfristige Ziel von WordPress, auf eine API-orientierte Plattform mit mehr Javascript auf Schnittstellen umzusteigen. Es ist einfacher zu lernen und Vertrautheit wird andere WP-Entwickler dazu ermutigen, ebenfalls einzusteigen.

Ich habe gesehen, wie VueJS in der Laravel-Community gedeiht und ist für die meisten fast zu einer defakten Wahl geworden. Ich glaube, dass es auch in der WordPress-Community so sein wird.

Backbone.js

/ s

Ich wollte meine Unterstützung hinter MarkoJS werfen.

Vor zwei Jahren habe ich die Infrastruktur meines Unternehmens von ExpressJS und Jade (jetzt PUG) auf Marko JS verlagert. Mein Unternehmen wollte komplizierte und wiederverwendbare Komponenten in unserem gesamten Ökosystem erstellen. Entwickler wollten Geschwindigkeit und Wiederverwendbarkeit. Designer wollten eine geringere Konstruktionslast. Wir haben seitdem nicht mehr zurückgeschaut.

Wir haben jetzt mehrere Websites mit Kundenkontakt in Marko und ein gesamtes CMS-System.

Letztendlich habe ich MarkoJS für Folgendes ausgewählt:

• Schnelles Server-Rendering auch mit Frameworks wie Koa und / oder ExpressJS
• Verarbeitet das asynchrone Rendern von Seitendaten
• Möglichkeit, Plug-and-Play-Komponenten für ein größeres Ökosystem zu erstellen
• Bessere Leistung als React / Vue
• Extrem einfache Vorlagensyntax

Ich möchte auch darauf hinweisen, dass das MarkoJS-Team buchstäblich herausragend war. @ patrick-steele-idem und @mlrawlings waren schon immer an Bord, um neue Ideen zu entwickeln, Probleme zu beheben und Einzelpersonen zu helfen.

👍 für MarkoJS

Preact ist eine React-API-kompatible Bibliothek, dh Preact profitiert direkt vom React-Ökosystem und der großen Anzahl verfügbarer OSS-Pakete / -Komponenten. Das Ökosystem von Vue ist im Vergleich viel kleiner. Die Dokumentation für Vue-Pakete / -Komponenten von Drittanbietern ist in Chinesisch.

Bitte nicht mehr "Ich stimme für XYZ", sie tun nichts, um das Gespräch zu verbessern, außer unnötige Antworten an Personen zu senden, die dieses Problem abonniert haben

🔥 Winkel

• PRO: Größter Konkurrent zu reagieren
  Für viele Leute. Die Frage ist oft "Winkel oder reagieren?" / "Reagieren oder eckig?". Die Angular-Community ist wohl die größte unter den React-Alternativen und wächst schnell.

• PRO: Viele Lernressourcen
  Neben offiziellen API-Dokumenten und -Handbüchern verfügt Angular wahrscheinlich über das größte Ökosystem an Lehrmaterialien, Blog-Posts, Büchern und vielen, vielen kostenlosen und kommerziellen Videokursen auf allen wichtigen Lernplattformen sowie an Google GDEs, die diese in Workshops und Konferenzen unterrichten.

• PRO: Lässt sich gut in Redux integrieren
  Entweder direkt oder über RxJS-fähiges Ngrx (unterstützt von einem Mitglied des Angular-Teams)

• PRO: Best-in-Class-Werkzeugunterstützung

  • CLI bietet weit mehr Funktionen als andere

  • Sehr gute Editorunterstützung in VS Code, insbesondere mit dem Sprachdienst

  • Geschrieben für TypeScript, bietet beste TypeScript-Erfahrung

• PRO: Funktionsreich, eigensinnig und standardmäßig organisiert
  Die logische Trennung über Angular Modules (NgModule) sowie Standardfunktionen für Formulare, HTTP-Aufrufe, Routing usw. erleichtern anderen Entwicklern das Lesen von Code und das Hinzufügen dazu

• PRO: Beste Integration mit RxJS
  Nützlich für viele API-Streams und viele Streams von Ereignissen auf einer Seite im Allgemeinen

• PRO: Eingebautes DI-System (Dependency Injection)
  Nützlich zum Erstellen von Erweiterungspunkten und möglicherweise sogar eines Plugin-Systems, insbesondere in Kombination mit RxJS

• PRO: Markiert viele andere Kästchen, die andere Bibliotheken abdecken

  • UI-Bibliotheken mit zulässigen Lizenzen
    Es gibt PrimeNg, Angular Material 2, ngx-bootstrap und viele mehr ...

  • Faules Laden
    Integrierte Unterstützung für Lazy-Loading-Routen und Unterstützung für Lazy-Loading-Module auch manuell

  • Komponentenspezifisches CSS
    Stellt sicher, dass CSS nur für Komponenten gilt, nur geladen wird, wenn die Komponente geladen wird, und Hooks für globales CSS enthält

  • Serverseitiges Rendern
    Ich arbeite bereits mit Node und ASP .NET Core und kann mich heutzutage besser konzentrieren

  • Testen
    Angular bietet agnostische Testhelfer für Unit-Test-Frameworks, die Unit-Tests sehr einfach machen. Sie generieren standardmäßig Tests aus der CLI mit Jasmine, die einfach auf Jest umgestellt werden können. Sie bieten auch einen optionalen Selenium Wrapper Protractor, um das Testen von E2E zu vereinfachen (obwohl Sie es nicht wirklich benötigen, verwende ich Selenium .NET für meine Angular-Apps, nichts Angular-spezifisches, aber sie versuchen, es noch einfacher zu machen).

  • Mobile / PWA-Unterstützung
    Google ist der größte Unterstützer von PWAs. Die Unterstützung wird in Angular CLI bereits mit Service Workers und Universal (serverseitige Unterstützung) sowie Ionic (Cordova-Unterstützung) und NativeScript (native Apps) angezeigt.

• PRO: Konzentrieren Sie sich auf die Browserunterstützung
  Mit einer dedizierten Polyfills-Seite in Dokumenten und dem standardmäßigen Einfügen (kommentierter) Polyfills in die CLI hält Angular Sie auf dem Laufenden, welche genauen Polyfills Sie beispielsweise für IE <= 11 benötigen, sodass Sie keine viel größere Polyfills laden müssen ohne Grund eingestellt. Das liegt daran, dass ihnen die Browserunterstützung am Herzen liegt.

• PRO: Große Unternehmensunterstützung
  Angular ist eine der wenigen hier diskutierten Bibliotheken (die einzige?), Die von einer großen Firma unterstützt wird.
  Indem wir uns hier unterstützen, nicht nur ein Unternehmen, das es in einigen Projekten verwendet und zum Ökosystem beigetragen hat, sondern auch offizielle Betreuer sind, die Entwickler und technische Redakteure dafür bezahlen, dass sie Vollzeit arbeiten, und in Community-Führungskräfte (in diesem Fall GDEs und DevRel) investieren von Google).
  Dies ist PRO kein CON, da es mit einer MIT- Lizenz ohne zusätzliche Klauseln, ohne Widerrufsbelehrung oder irgendetwas anderem geliefert wird, das für manche Menschen verwirrend oder beängstigend sein kann.

Ich habe Vuejs für einige Projekte wie Plugins und REST-API implementiert. Ich muss sagen, dass es leicht zu lernen ist, viele Funktionen hat, eine riesige Community hat und das Ökosystem auch gut ist.

Heutzutage wächst Vuejs schnell. Es ist eine kluge Wahl, wenn Vuejs in WordPress-Code integriert ist.

@cyberwani @thephilip @evoratec und andere.

@ntwb hat bereits folgenden Kommentar geantwortet:

Bitte nicht mehr "Ich stimme für XYZ", sie tun nichts, um das Gespräch zu verbessern, außer unnötige Antworten an Personen zu senden, die dieses Problem abonniert haben

Hören Sie also bitte auf, nutzlose Kommentare abzugeben. Um Ihre Unterstützung zu zeigen, können Sie Github-Emojis verwenden, um einen Kommentar zu Ihrer Bibliothek zu erhalten.

Vue.

Übrigens gibt es jetzt Alibaba hinter Vue sowie das Weex Apache-Projekt, das Vue API auf Mobilgeräten ermöglicht.

Ich würde hier wirklich etwas Mäßigung zeigen, zu viele Fan-Jungs ohne klare Argumente

Dies ist die letzte Warnung. Der nächste Schritt ist, dass wir anfangen, Kommentare zu löschen ...

Ich selbst habe Marko, Preact oder Vue.js nicht verwendet. Um ehrlich zu sein, kenne ich keine von ihnen. Ich würde gerne hören und lesen, was die WordPress-Community zu diesen Frameworks zu sagen hat. Jeder von ihnen, die technischen Vorzüge eines jeden, das umgebende Ökosystem eines jeden, die Build-Tools und nicht zuletzt die Menschen und Gemeinschaften, die hinter diesen Projekten stehen. 😄

Ich möchte nicht "Meine Stimme ist für XYZ" lesen. Wenn Sie eine Stimme hinzufügen möchten, scrollen Sie nach oben und fügen Sie eine Emoji-Reaktion nach oben auf Ihr bereits erwähntes Framework Ihrer Wahl hinzu. 👍

Es dauerte nicht lange, bis zwei neue Kommentare seit meinem vorherigen Kommentar angezeigt wurden 😞

Zu diesem Zweck ... Wenn Ihr Kommentar nach https://github.com/WordPress/gutenberg/issues/2733#issuecomment -329705942 hinzugefügt wurde und Sie nur _ "Ich stimme für XYZ" _ oder einen Text dazu gesagt haben Da Ihre Kommentare eine sehr hohe Wahrscheinlichkeit haben, gelöscht zu werden , werden auch zukünftige Kommentare desselben Typs entfernt .

Wenn Sie zu diesem Problem zurückkehren und sich fragen, warum Ihr Kommentar gelöscht wurde, ist dies der Grund

@ahmadawais Ich habe ein paar Kommentare.

Gutenbergs Migration von Reagieren zu ...?

Hinsichtlich:

@patrickgalbraith Das ist eigentlich der falsche Grund, Preact in Betracht zu ziehen. Es sollte nach seinen Vorzügen beurteilt werden und nicht, weil es einfacher ist, dorthin zu migrieren. Ich kann die folgenden Probleme mit Preact sehen

• Kleinere Community im Vergleich zu VueJS
• Code-Gerüche - Der Übergang zu einer sehr ähnlichen Bibliothek kann zu schlechten Praktiken führen (aus dem offensichtlichen Grund, dass dies der schnellere Weg ist).
• Bei Preact zu bleiben ist sowieso wie bei React zu bleiben (lesen Sie es in einem Thread)

Ich denke, wenn Sie ein Projekt mit einer nicht trivialen Anzahl von Codezeilen haben, müssen Sie sehr vorsichtig sein. Ingenieure schreiben gerne Dinge um, lernen neue Sprachen und Frameworks und denken, dass sie einen besseren Job machen werden, wenn sie diesen Code umschreiben können ... Joel sprach vor langer Zeit über die Gefahr von Umschreibungen .
Durch die Verwendung von Preact sparen Sie viel Zeit. Sie können die Zeit unterschätzen, die erforderlich ist, um zu einem völlig neuen Framework zu wechseln. Ich bin mir nicht sicher, warum Sie geschrieben haben "Das ist eigentlich der falsche Grund, über Preact nachzudenken". Als Ingenieur stehen Kosten und Markteinführungszeit ganz oben auf der Liste der Kriterien, anhand derer ich Lösungen bewerte und auswähle.
Wenn das Problem wirklich das Facebook-Patent ist, löst Preact es und minimiert die Kosten. Preact ist leistungsfähiger als React und sogar Vue: geringerer Platzbedarf und schnelleres Laufzeit-Rendering. Überprüfen Sie auch Addy Osmanis Bericht darüber .

Ich bin mir nicht sicher, wie Sie die Größe der Preact-Community bewertet haben. Wenn wir über das Ökosystem und die verfügbaren Komponenten sprechen, können Sie mit Preact die meisten Open-Source-Komponenten von React verwenden. In der Praxis gibt es also Leute, die, auch wenn sie nicht explizit an Preact arbeiten, immer noch Code produzieren, den Sie nutzen können. Sie können das Ökosystem von React immer noch als Teil des Ökosystems von Preact betrachten.

Warum ist Vue immer noch Ihre Lieblingsoption?

Ich bin der Meinung, dass der dritte Punkt hier "An Preact festhalten ist wie an Reagieren festhalten" wahrscheinlich der Hauptgrund ist, warum Sie zögern, sich für Preact zu entscheiden. Liege ich falsch? Was ist falsch an React neben dem Patent?

Das große Ganze betrachten

Ich habe gelesen, dass alles, was Sie für Gutenberg auswählen, auch für Calypso verwendet wird.
Gutenberg verwendet React nur im Frontend. Wenn Sie sich das serverseitige Rendern ansehen, wird die Situation komplexer, aber Preact scheint immer noch eine einfachere Migrationsoption zu sein.

Ich denke, Sie müssen sich Ihre Kriterien ansehen. Wenn Sie ernsthaft über ein Umschreiben nachdenken und es wichtig ist, das isomorphe Rendering MarkoJS ganz oben auf der Kandidatenliste.

Wenn ich von vorne anfing und bereit war, das React-Ökosystem zu ignorieren, ist MarkoJS ein Kinderspiel.

Ich schaue mir die Leistungen an und MarkoJS scheint keine Rivalen zu haben . 40x schneller als React, 10x schneller als Vue und 6x schneller als Preact ist verrückt. In meinem Buch sind 30% Verbesserungen irrelevant, aber wenn Sie mehr als eine 10-fache Verbesserung haben, müssen Sie ernsthaft darauf achten.
Wenn Sie eine bescheidene erfolgreiche Präsenz haben und 10 Server anstelle von 100 oder 2 anstelle von 20 verwenden können, macht dies einen großen Unterschied.

Vollständige Offenlegung Ich habe keine emotionale Bindung an entweder pReact oder MarkoJS. Ich denke nur, dass sie aus technischer Sicht sinnvoller sind als die Alternativen.

Viel Glück bei Ihrer Entscheidung 😃

@ ChrisCinelli das sind SSR-Nummern ...

Ich komme aus der Drupal-Welt (wir sehen uns diese Ausgabe an: D), also habe ich keinen Anteil daran. Aber wenn man die Kommentare liest, ist es offensichtlich, dass es hier ungefähr 5 "Top" Frameworks gibt und jeder das von ihm gewählte mag, damit er ihm Requisiten gibt.

Der Geschwindigkeitsaspekt ist heutzutage eigentlich irrelevant. Die einzigen zwei Faktoren, die berücksichtigt werden sollten, sind: a) Wollen Sie wirklich alles neu schreiben und b) wie wird der Übergang für React-Entwickler aussehen und wie wird das Lernen der Gewinner-FW für neue Entwickler sein?

Es gibt Preact-kompatible, Inferno-kompatible ... Schichten für einen einfachen Übergang, aber die Leistung wird darunter leiden. Auf der anderen Seite wird der Übergang mit der Zeit anmutig, nicht alles muss auf einmal neu geschrieben werden. Aus geschäftlicher Sicht ist dies ein Kinderspiel. Von Community POV und Zukunft macht es keinen Unterschied.

Jetzt liegt im DX alles. Jeder, der Erfahrung mit reaktiven fws hat, sollte kein Problem damit haben, auf neue fw umzusteigen, nur weil die Konzepte gleich sind, nur die Syntax unterscheidet sich. Aber der Neuling, das ist derjenige, der zählt. Wie schwer / einfach ist es, in neuen fw produktiv zu sein. Wie schwer / einfach ist es, vorhandenen Code zu lesen und zu verstehen. Und dies liegt ausschließlich an a) guter Dokumentation und b) Community (Foren, SO, Chatrooms, Blogs ..).

Ich werde nicht sagen, welche FW ich bevorzugen würde, da ich, wie gesagt, kein WP-Typ bin. Aber ich wollte mein 2c geben, um deinen Kopf kühl zu halten, wenn es um eine so große Entscheidung geht, die Tausende von Entwicklern auf der ganzen Welt beeinflussen wird.

@ntwb: Ich habe nicht mein Kommentar gelöscht , aber ich denke , Löschen von Kommentaren, auch die der Fan Jungen, als eine Art von Zensur.

Warum:

Wenn Ihr Kommentar nach # 2733 (Kommentar) hinzugefügt wurde und Sie nur "Ich stimme für XYZ" oder einen entsprechenden Text gesagt haben, besteht eine sehr hohe Wahrscheinlichkeit, dass Ihre Kommentare gelöscht werden. Zukünftige Kommentare derselben Art werden ebenfalls entfernt .

Darüber sehe ich viele Kommentare von Fan Boys. Warum bleiben sie?
Es scheint eine Doppelmoral.

Angular, es ist eine klare Wahl. Ich denke, Roy und Meligy machen fantastische Punkte und unterstützen sie zu 100%. WordPress bewegt sich nicht nur in der Enterprise-Branche, sondern auch in Bezug auf die Methodik seiner Entwicklung.

Ich werde eine unterhaltsame Quelle verlinken: https://vuejs.org/v2/guide/comparison.html und insbesondere: "... die Komplexität von Angular beruht hauptsächlich auf dem Designziel, nur große, komplexe Ziele zu erreichen Anwendungen ... ". Diese einfache Aussage trifft den Nagel auf den Kopf. WordPress ist und bleibt eine robuste komplexe Anwendung.

@ChrisCinelli Nur weil wir die Leute gebeten haben, nicht "Ich

Ich habe dies nicht früher gebracht, weil ich keine Frameworks angreifen wollte, die ich nicht empfohlen hatte (nachdem ich Angular oben

Das Folgende ist ein Zitat aus einem Beitrag, der von einem Patent- / IP-Anwalt für die React-Lizenz verfasst wurde ( Fettdruck wird von der Quelle kopiert):

Ich habe eine Menge von "na dann lass uns einfach alle [alternatives Framework hier] verwenden." Warte eine Sekunde. Wenn Facebook-Patente React abdecken (Unterschiede, Komponenten usw.), beziehen sich diese Patente wahrscheinlich auf Preact / Vue / et al.

Aber React gibt Ihnen eine Patenterteilung! Mit einem alternativen Framework sind Sie vom ersten Tag an ein Rechtsverletzer. Dies alles hängt davon ab, ob Facebook Patente hat und ob sie diese durchsetzen möchten. Wenn Sie dies jedoch bis zum n-ten Grad bekämpfen möchten, sind

Wenn mein Verständnis richtig ist, verlässt WordPress React nicht, weil es sich Sorgen um die Lizenz selbst macht, sondern nur darum, diese Lizenz an seine Benutzer weitergeben zu müssen, und damit die Verwirrung und die Notwendigkeit, die Entscheidung zu verteidigen, zu sich selbst zu bringen.

Wenn Sie zu einer React-Alternative gehen, gibt es möglicherweise weniger zu verteidigen, wenn die alternative Lizenz zulässig ist, aber es kann auch immer noch Verwirrung bei WordPress geben.

Es liegt an WordPress zu entscheiden, ob dies ein Grund zur Sorge ist oder nicht.

@ ChrisCinelli danke für deine konstruktive Kritik. Ich begrüße es mit offenen Händen.

Als Ingenieur weiß ich, dass Kosten und Zeit ganz oben auf der Liste stehen. Aber hier ist die Sache. Dies ist kein Projekt eines bestimmten Unternehmens. Die Ziele hier sind unterschiedlich.

Das Ziel ist es, eine JS FW zu finden, die gut für die Community ist. Gutenberg ist noch nicht gestartet. Wenn es funktioniert hätte, wäre Preact der klare Gewinner gewesen.

Im Moment müssen wir uns darum kümmern:

• JS FW ist für die größere Community einfach zu übernehmen
• JS FW, die wir wählen, muss eine eigene Gemeinschaft und ein eigenes Ökosystem haben
• Eine nachgewiesene Erfolgsbilanz mit einer PHP-basierten Produktions-FOSS-Software ist von Vorteil. Vue + Laravel
• Die Auswahl von JS FW basiert auf seinen Vorzügen und nicht nur, weil die Migration einfacher ist

In 11 Jahren, die ich mit WordPress verbracht habe und als regelmäßiger Hauptverantwortlicher glaube ich, dass die Wahl von Preact viel Chaos verursachen würde. Die Lernkurve für fortgeschrittene / neue Entwickler ist bereits enorm.

Wenn sie gleich zu Beginn dieser neuen Phase der WordPress-Verbesserung das Durcheinander der Preact-React-Kompatibilität durchlaufen, können sie die WordPress-Community verlassen und etwas anderes mit einer ähnlichen Lernkurve lernen. (_HINT_: Laravel + Vue statt WordPress + Preact + React) Und übrigens, vergessen Sie, dass dies mit Drupal 8 passiert?

Bitte entfernen Sie keine zivilen Kommentare. Es besteht offensichtlich ein überwältigendes Bedürfnis oder der überwältigende Wunsch, eine Meinung zu diesem Thema zu äußern. Ich sehe es als eine gute Sache an, wenn Leute sagen, dass sie sich für WordPress interessieren und gehört werden wollen. Denken Sie daran, dass die WordPress-Community, nicht nur ihre Entwickler, an Github verwiesen wurde, um Feedback zu geben. Wenn wir +1 Kommentare wirklich, wirklich nicht tolerieren können, fügen Sie oben eine Liste hinzu, die die Benutzernamen beibehält.

Wenn Sie nur nach einer begründeten Diskussion suchen, scheinen viele "Ich stimme für X, Y oder Z" -Kommentare nur wie Lärm zu sein, aber es gibt ein klares Muster von Leuten, die Vue.js unterstützen. Ich gehe davon aus, dass wir hundert oder ein paar hundert Leute haben, die Code zu Gutenberg beitragen, aber Zehntausende, die Plugins und Themen schreiben, die damit interagieren. Der Erfolg von Gutenberg ist nicht nur die Endbenutzererfahrung, sondern auch die Entwicklererfahrung. Es ist nicht das einzige, aber eine wichtige Sache, die WordPress erfolgreich macht, ist, dass es leicht erweiterbar ist.

Obwohl ich kein spezifisches Framework im Sinn habe, würde ich sagen, dass eine Sache, die wir beachten sollten, darin besteht, dass die Browserunterstützung bei Webkomponenten, einem Framework, das Webkomponenten verwendet, oder zumindest deren eigenen Komponenten, die so aufgebaut sind, allmählich in Kraft tritt Sie wären zukunftssicher. Es gibt auch Polyfills, um Webkomponenten in Browser zu bringen, die dies nicht unterstützen.

Ich wurde bereits erwähnt und bin gerade hierher gekommen, um Benachrichtigungen auszuschalten, aber ich werde ein bisschen abwägen.

Wenn Sie eine App mit nur einer Seite von Grund auf neu erstellen, ist Zeit von entscheidender Bedeutung, und Sie möchten ein gut unterstütztes, dokumentiertes und testbares Framework. Ich habe viele konkrete Erfahrungen, die zeigen, dass es in Bezug auf Zeit und Schätze weitaus günstiger ist geh mit Ember.

Wenn Sie mehr PWA erstellen oder Komponenten auf einer vom Server gerenderten Seite ablegen, ist Ember eine schlechte Wahl, und ich kann sehen, warum so etwas wie Vue ansprechend ist.

Ich werde hinzufügen, dass ich aus konventioneller Sicht einige PWAs mit> 90 Leuchtturm-Scores mit Ember erstellt habe.

Bei unserem letzten Projekt, bei dem wir dies tun mussten, dauerte der Prozess <1 Stunde, um diese Leuchtturm-Punktzahl zu erhalten und die App mit aktiviertem serverseitigem Rendering bereitzustellen.

Der für hohe Leuchtturmwerte erforderliche SSR- und Service-Worker-Cache kann ein sehr schwieriger Prozess sein.
Mit Ember ist dieser Prozess sehr einfach und erfordert nur die Installation einiger gut dokumentierter und gewarteter Addons (für die meisten Apps).
Nach meiner Erfahrung ist Preact in Preact CLI standardmäßig mit diesen beiden Funktionen ausgestattet. Es gibt jedoch beliebte (P) React-Konventionen, die die SSR-Ergebnisse beeinträchtigen können.
In Vue empfehlen die offiziellen Dokumente die Verwendung von Nuxt.js oder die Befolgung des vollständigen SSR-Handbuchs . Beide führen weitere Muster ein, die über die grundlegende Vue-Dokumentation hinaus befolgt werden müssen.

Sagen Sie niemandem Bescheid, aber lassen Sie uns das Löschen von Kommentaren zu Themen zurückhalten, es sei denn, sie sind profan oder missbräuchlich. Ich bekomme Leute, die helfen und das Gespräch fokussieren wollen, aber wir sollten nicht in die Spirale des Löschens von Kommentaren geraten.

Ich bin mir nicht sicher, was an Ember im Vergleich zu VueJS @rtablada "gut dokumentiert" ist.

Ich persönlich hätte ein Problem mit Ember im Vergleich zu Vue oder sogar React.

@ahmadawais Jeder vergisst, dass diese Entscheidung große Auswirkungen haben wird und Sie in einigen Jahren das Framework trotzdem ändern möchten. Sie möchten also moderne Rahmengüte verwenden, aber nicht für Leben und Tod daran gebunden sein. Klingt unmöglich? Es ist nicht!

Vor einiger Zeit hatte ich ein ähnliches Problem und nach Recherchen und Versuchen habe ich eine Lösung gefunden, die versucht, Wasser mit Feuer zu verbinden. In wenigen Worten: Benutzerdefinierte Elemente der Webkomponente, Wrapping-Technologie, die Sie mögen (z. B. Vue, React, Angular) und Offenlegung der Standard-DOM-API.

In einer solchen Lösung haben Sie mehrere Komponenten und jede von ihnen hat:

• Rahmen, den Sie mögen (aber natürlich vorzugsweise nur einen)
• Standard-DOM-API, die andere Komponenten problemlos verwenden können. Sie können es sogar über einfaches JavaScipt bearbeiten

Da ich zu dieser Zeit mit Vue gearbeitet habe, habe ich den Adapter von Custom Element für Vue geschrieben - https://github.com/karol-f/vue-custom-element - damit Sie überlegene Kompatibilität haben (z. B. Vues $ emit send standard DOM-Ereignis, das dies kann über einfaches JS oder zB React / Angular) und IE9 + -Kompatibilität erfasst werden.

Ich empfehle, eine solche Lösung wie Sie zu betrachten:

• wird zukunftssicher sein
• wird nicht an ein Framework gebunden sein, das Sie heute wählen
• Ihre Benutzer sehen Standard-HTML-Elemente und können mit ihnen mit einem Framework interagieren, das ihnen gefällt, oder sogar mit einfachem JS
• Es wird keine manuelle Vue-Initialisierung geben, da der Browser Ihnen mitteilt und die Komponente automatisch initiiert, wenn sie auf der Seite ist (Sie können die Komponente sogar so verzögern).

und viele mehr.

Eine solche Lösung ist nicht an Vue gebunden - Sie können jedes andere Framework verwenden, das Sie möchten. Auch die benutzerdefinierten Elemente der Webkomponente sind Standardfunktionen des Browsers und werden nirgendwo hingehen!

Grüße!

Ich gehe davon aus, dass wir hundert oder ein paar hundert Leute haben, die Code zu Gutenberg beitragen, aber Zehntausende, die Plugins und Themen schreiben, die damit interagieren. Der Erfolg von Gutenberg ist nicht nur die Endbenutzererfahrung, sondern auch die Entwicklererfahrung. Es ist nicht das einzige, aber eine wichtige Sache, die WordPress erfolgreich macht, ist, dass es leicht erweiterbar ist.

Zitieren Sie den obigen Kommentar von @dmccan, weil dies ein so wichtiger Punkt zur Unterstützung von Vue ist.

WordPress hat mehr als nur das Veröffentlichen demokratisiert. Ich frage mich, wie viele erfolgreiche technische Karrieren und Unternehmen aufgrund der Zugänglichkeit von WordPress gestartet sind. Meins sicher.

Ich werde meinen Hut zu Gunsten von VueJS werfen. Das lokale JavaScript-Treffen hier wird von einem der Mitglieder des Kernteams von VueJS gemeinsam geleitet, und es schien dasjenige zu sein, mit dem die Teilnehmer viel schneller an Bord gehen konnten als andere. Meine früheren Erfahrungen waren mit AngularJS und ich fand, dass VueJS unglaublich einfacher zu erlernen ist und ich einfach mit dem Codieren beginne, obwohl ich von vorne angefangen habe.

Ich sehe, dass einige Leute über Unternehmen und damit über Angular sprechen, aber während WordPress in diesem Bereich vielleicht etwas Liebe braucht, denke ich, dass die Entscheidung auf der Funktionalität und dergleichen basieren sollte, die es den Entwicklern erleichtern, an Bord zu sein. Mit den Diskussionen, die wir über Meta-Boxen und so weiter gesehen haben, bringen wir Plug-In-Autoren dazu, ihre Arbeit "Gutenberg-ify" zu machen, anstatt einfach aufzugeben, ob / wann der klassische Editor verschwindet.

Einige weitere Punkte, die Sie über Vue.js erwähnen sollten: (Nur persönliche Gedanken, andere Bibliotheken, FWs und Optionen werden geschätzt und haben mit Sicherheit ihre eigenen einzigartigen Funktionen und Vorteile.)

• PRO Es erfordert nicht unbedingt einen Transpiler oder eine erzwungene Verwendung und kann wie jquery direkt im Web ausgeführt werden

Dies würde Plugin-Entwicklern erstaunlich helfen, sich in die Wordpress-Benutzeroberfläche zu integrieren. Sie können eine neue Vue-Instanz als Widget an einen beliebigen Teil der Seite anhängen. Auch große Wordpress-Projekte können schrittweise mit Vue.js übernommen werden, ohne dass große Änderungen an der Codebasis vorgenommen werden müssen, da Vue nicht davon ausgeht, wie es verwendet wird. Ich denke, dies ist der Erfolgsschlüssel, warum Laravel / Vue so beliebt ist und gut zusammenarbeitet :)

• PRO JSX und CSS-in-JS werden ebenfalls unterstützt!

Dies kann dazu beitragen, aktuelle WordPress-Projekte mit React / JSX-Code mit weniger Änderungsanforderungen schneller auf vue.js zu migrieren. (Es gibt sogar ein Babel-Plugin: Babel-Plugin-Transformation-React-to-Vue )

• FACT Vue ist genau wie Preact und im Gegensatz zu Angular / React kein Open-Source-Projekt eines großen Unternehmens wie Google oder Facebook.

Dies wäre für ein RIESIGES Projekt wie Wordpress von entscheidender Bedeutung, um einer potenziellen Lieferantenbindung zu entgehen. Wenn ein OpenSource-Projekt, das keinem Unternehmen gehört, von jemandem gestartet werden sollte ("Abhängigkeit von Schlüsselpersonen" ist also bedeutungslos, um als CON bezeichnet zu werden ).

Ich stimme für VueJS.
Nicht weil ich etwas darüber weiß, sondern weil ich keine Ahnung habe, wie es in englischer Sprache ausgesprochen wird. Ich habe Joomla jedoch jahrelang benutzt und es die ganze Zeit falsch ausgesprochen.

Scherz beiseite.
Nicht viele diskutieren hier, welches Framework für die Unterstützung alter Metaboxen und benutzerdefinierter Felder besser ist. Wie wir jetzt wissen, war die Reaktion sehr schlecht.

Nun, nur um sich von diesem Problem abzumelden.

Um die Diskussion zu fokussieren, habe ich hier ein Aufgabenproblem erstellt: https://github.com/WordPress/gutenberg/issues/2741

Ich würde Vue vorschlagen, nur weil Laravel. Viele WordPress-Leute, die mit dem Kurs, der sie genommen haben oder noch nehmen, unzufrieden sind, haben auf die Verwendung von Laravel als Haupt-CMS-Framework umgestellt, während WP die zweite Wahl bleibt. Preact ist nur ein Klon und eine massive Kompatibilitätsschicht, wie es Novell DOS für MS DOS, PC DOS und umgekehrt war.

cu, w0lf.

Vue.js den ganzen Weg!

Sie sollten sich auf jeden Fall Hyperapp ansehen .
Vorteile

1. Es ist der Elm-Architektur (Modell, Ansicht, Aktualisierung) sehr ähnlich.
2. Es hat eingebautes Redux wie Reduzierstücke, die als "Aktionen" bezeichnet werden (aufgerufen, um das Modell und die Ansicht zu aktualisieren).
3. Verwendet JSX
4. Fördert "funktionale Programmierung" -Designs
5. Es ist 1 KB groß und daher leicht zu laden und leicht zu verstehen.

Nachteile

1. Es ist noch neu und das Ökosystem auch. Aber Sie können es beeinflussen und dazu beitragen.
2. Möglicherweise gibt es Probleme, die noch nicht aufgedeckt sind.

Die Prinzipien von Gutenberg-Blöcken passen gut zu denen von Webkomponenten . Es ist ein Low-Level-Framework-Agnostiker und ein aufstrebender Standard (mit ausgereiften und getesteten Polyfills) - die perfekte Lösung für WordPress.

Siehe auch: Polymer - Webkomponenten mit etwas Zucker.

Vue ist eine fantastische Option, und hier sind die Gründe, aus denen ich das glaube:

Ich habe Anfang 2016 angefangen, Vue zu schauen. Ich habe es geliebt und wollte herausfinden, ob es jemals "gefragt" sein würde oder ob sein Wachstum etwas war, über das man nach Hause schreiben konnte. Zu der Zeit hat es 16.000 Sterne auf Github. Es war cool und alles, aber die Leute hatten sich inmitten des ganzen Mistes von Angular vs React nicht wirklich daran gewöhnt.

Ich habe alle meine Daten verloren und am 17. September 2016 von vorne angefangen . Heute vor genau einem Jahr. ( Hier ist mein aktueller Datensatz. )

Im letzten Jahr habe ich beobachtet, wie die Popularität von Vue (in Bezug auf Erwähnungen im Internet und das Verfolgen von Github-Stars) mit einer Rekordrate zunahm. Vue hat in 365 Tagen 40.000 Sterne gesammelt. Das sind durchschnittlich 109 pro Tag. Im Vergleich dazu wuchs die geliebte Reaktion der Welt im gleichen Zeitraum von 49.000 auf 75.000. (71 pro Tag) Vue wird React in den nächsten Monaten in Bezug auf Benutzerbewertungen übertreffen.

Während alle davon sprachen, dass Reacts Wachstum das unglaublichste aller Zeiten sei, waren sie sich nicht bewusst, dass Vue der eigentliche Titelverteidiger war. Sie waren sich nicht bewusst, dass Vue wuchs, weil die Leute es wirklich als Werkzeug liebten, und nicht wegen irgendeiner berühmten Unterstützung (Facebook).

Vue steht seit mehr als einem Jahr jeden Tag auf der Repos-Liste von Github. 99% der Tage ist es über Reagieren. In 10% der Tage macht React den Schnitt nicht.

All diese Rufe "benutze Vue, weil es mehr Popularität hat!" Ich möchte jedoch vermitteln, dass Vue gewachsen ist, weil die Leute es wirklich lieben, weil es ein großartiges, intuitives und leistungsstarkes Tool (oft fälschlicherweise als "großartig für kleine Apps" dargestellt) für Anwendungen aller Größen ist. Aber nicht nur ein Werkzeug. Vue ist ein Ökosystem. Es kommt auch mit einer massiven unterstützenden Community.

Darf ich hinzufügen ... die .vue -Dateien sind genial. Es werden so viele Tools für das Styling in React erstellt, weil anscheinend etwas mit CSS-Modulen nicht stimmt und Ihre Styles in einer externen Datei gespeichert sind. (Idk ...) Aber Vue hat dieses Problem nicht. Vue hat Steueranweisungen, die in die Syntax integriert sind, und (da ich oben Kommentare zu benutzerdefinierten Elementen gesehen habe) spielt nicht nur gut mit benutzerdefinierten Elementen ... Es ist eine Bibliothek / ein Framework für logische benutzerdefinierte Elemente.

Preact ist großartig. Ehrlich gesagt habe ich heute gerade ein anderes Projekt damit gestartet. Aber wenn ich mir Preact anschaue, sehe ich eine Reaktion außerhalb der Marke. Es wurde nicht entwickelt, um innovativ zu sein oder die Art und Weise, wie wir webbasierte Software erstellen, voranzutreiben. Es wurde entwickelt, um wie ein bereits vorhandenes Tool auszusehen und sich zu verhalten, aber um eine bessere Leistung zu bieten.

Das sind meine zwei Cent. Jetzt bin ich pleite.

Ich hoffe, Ihre endgültige Entscheidung macht Sie glücklich und bietet eine hervorragende Grundlage für die Zukunft Ihrer Produkte.

@ahmadawais :

• Die Markteinführungszeit ist sowohl für Unternehmens- als auch für Open Source-Projekte wichtig. Sie können Beispiele für Projekte finden, die nie ausgeliefert wurden, weil sie zu lange gedauert haben und veraltet waren, bevor sie ausgeliefert wurden. Einige Projekte wurden während der Arbeit an einer Hauptversion aufgegeben.
• Gegen Preact zu sein bedeutet "wir haben einen Fehler mit React aus Gründen gemacht, die über die Lizenzierung hinausgehen". Ich denke, mit "Die Lernkurve ist für fortgeschrittene / neue Entwickler bereits riesig" haben Sie gemeint, dass die Entwickler von WordPress bereits mit React verloren gegangen sind. Das wundert mich nicht. Es scheint jedoch schwer zu glauben, dass Vue, auch wenn es weniger ausführlich ist, die Probleme der Lernkurve lösen wird. Die alte PHP WP-Engine und jedes einzelne Seiten-App-Javascript-Framework sind sehr unterschiedlich. Vue und React sind sich sehr ähnlich.
  Ich bin mir nicht sicher, warum Sie eine Konkurrenz zwischen Wordpress und Laravel sehen. Ich kann hier naiv sein. Ich weiß sehr wenig über die Drupal 8-Geschichte.
  Aus meiner Sicht ist Wordpress ein CMS und zieht Entwickler aufgrund seiner großen Benutzerbasis von nicht technischen Benutzern und der bereits integrierten Funktionen an. Es gibt viele Vorlagen und Entwickler können sehr schnell eine neue Site erstellen, die von einem Nicht-Entwickler angepasst werden kann.
  Laravel ist ein PHP-Framework, das Ihnen meines Wissens nicht viele Funktionen eines CMS bietet. Ein Entwickler wird es wählen, weil er mehr Freiheit braucht.
• Ich bin mir nicht sicher, wie ein paar Erfolge mit Vue + Laravel auch bedeuten, dass "Vue gut für Wordpress ist". Ich denke, es gibt sehr wenig intrinsische Synergien zwischen PHP und einem JS-Framework. Ich stimme vollkommen zu, dass es wichtig ist, einen Rahmen zu finden, der gut für die Gemeinschaft ist. Wenn der Großteil der aktuellen Entwickler-Community, von der WordPress abhängt, mit Vue vertraut ist und sie es lieben, hat dies einen hohen Stellenwert bei Ihrer endgültigen Entscheidung.

Aus technischer Sicht denke ich, dass sowohl Marko JS als auch Vue neuere Frameworks sind. Sie haben viel von React gelernt und konnten einen Teil der darin enthaltenen Ausführlichkeit entfernen. In diesem Sinne scheint Marko noch mehr Code als Vue zu entfernen. Insbesondere behält Marko zusammenhängenden Code bei, der gut ist, um ihn an derselben Stelle zu halten und in HTML zu belassen, wofür HTML gut ist, und in Javascript, wofür Javascript gut ist. Und es ist auch 10x schneller. Abgesehen von der Tatsache, dass Vue in letzter Zeit viele Fans hat, sehe ich nicht viele Gründe, Vue Marko vorzuziehen.

Entschuldigung, aber Markos Syntax und Setup sind im Vergleich zu VueJS schrecklich. In Bezug auf die Leistung habe ich keine Quelle gesehen, in der MarkoJS wesentlich schneller ist, ohne Zeit zu verlieren, um zu verstehen, wie es funktioniert.

Die Syntax von die Version, in der die aktuelle Syntax von Marko eingeführt wurde, wurde von unseren Benutzern sehr gut angenommen.

Wir haben viel über die Marko-Syntax nachgedacht, um sicherzustellen, dass sie Entwicklern, die HTML und JS verstehen, vertraut ist. Wir wollten, dass sie so einfach und leistungsfähig wie möglich ist und nur minimale Boilerplates enthält. Ich denke, Sie werden feststellen, dass bei jedem Nebeneinander-Vergleich die Marko-Vorlage weniger Code benötigt (was sich hervorragend für die Lesbarkeit und Wartbarkeit eignet).

Hier ist ein Dokument, das ich schnell zusammengestellt habe, damit Sie einen Überblick über die Unterschiede zwischen der Marko-Syntax und der Vue-Syntax erhalten:

Syntax: Marko vs Vue

Ich habe früher darauf verlinkt, aber für einen tieferen Vergleich zwischen Marko und Vue (und React) siehe:

Meetup: Erstellen der Benutzeroberfläche - ein Vergleich von React, Vue und Marko (vom Marko-Ersteller) - Video | Folien

In Bezug auf die Leistung haben wir einige Benchmarks, die Sie überprüfen können: https://github.com/marko-js/isomorphic-ui-benchmarks

Hier ein kurzer Überblick über die Benchmarks mit aktivierten Marko und Vue:

Serverseitige Renderleistung

_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

Client-seitige Leistung

_Chrome Version 63.0.3218.0 (Official Build) Kanarienvogel (64-Bit) _

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

Dies sind die Benchmarks, die wir für Marko.js erstellt haben. Nehmen Sie diese Ergebnisse also offensichtlich mit einem Körnchen Salz, aber wir haben alle Anstrengungen unternommen, um fair zu sein.

Ich wollte nur noch ein paar Kommentare zu Marko.js und zur Benutzerfreundlichkeit hinzufügen:

Marko war immer bestrebt, die einfachste Integration mit Node.js zu erreichen. Nach der Installation des Marko- Pakets über npm finden Sie hier den gesamten Code, der zum Rendern einer Vorlage für einen HTTP-Antwortstrom erforderlich ist:

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);

Ich denke, das ist so einfach, wie Sie es jemals bekommen werden.

Marko arbeitet auch mit gängigen JavaScript-Modul-Bundlern zusammen: http://markojs.com/docs/bundler-integrations-overview/

Um eine Marko-UI-Komponente der obersten Ebene in das DOM zu rendern, ist Folgendes erforderlich:

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 Laut http://www.stefankrause.net/wp/?p=431 Benchmarks, MarkoJs
ist so performant wie Vue et al.

Wir können daher den Schluss ziehen, dass Markojs und Vue im Allgemeinen clientseitiges Scripting gleichermaßen performant sind.

Natürlich enthält der von mir verlinkte Benchmark keine SSR. Also werde ich das nicht kommentieren.

Ich stimme für Vue. jQuery ist bereits eine nahezu notwendige Voraussetzung für die Verwendung von WordPress. Personen, die mit jQuery vertraut sind, sollten sich mit der Vue-Syntax vertraut fühlen. Die Ideologie über das DOM ist gar nicht so extrem wie Angular. Es greift auf das WordPress-Prinzip zurück, um dem Benutzer die Arbeit zu erleichtern.

Wie ich vor ungefähr zwei Jahren für Calypso vorgeschlagen habe , wäre Mithril.js, das die HyperScript-API verwendet, eine gute Wahl, um React zu ersetzen. Es hat eine Standard-MIT-Lizenz.

Eine kleine Investition in neue Tools, mit denen zumindest ein Teil des schweren Hebens automatisch für die Konvertierung von React in eine andere vdom-Bibliothek ausgeführt werden kann, kann sich in gesparten Entwicklerstunden auszahlen - wie in dieser Ausgabe als Vorschlag für Automattic erwähnt, dies im Voraus zur Absicherung zu tun seine Wette auf React.

Auch ohne Berücksichtigung von Nicht-Vdom-Bibliotheken gibt es mehr als 25 Vdom-Bibliotheken (z. B. inferno.js, Maquette usw.), die berücksichtigt werden könnten - wie in dieser Liste, die ich im Januar 2016 für ein anderes Projekt unter Berücksichtigung von Vdom-Optionen zusammengestellt habe.

Hier sind einige technische Gründe, warum Mithril.js oder andere vdoms, die die HyperScript-API betonen (oder zumindest unterstützen), die beste Wahl sind.

Persönlich halte ich Vorlagenansätze für JavaScript-basierte Benutzeroberflächen wie Reacts JSX oder Angulars eigenen Vorlagenansatz oder die Vorlagen-Systeme in vielen anderen Benutzeroberflächensystemen, einschließlich Vue, für veraltet. Warum? Einstellungen und "Best Practices" für das Schreiben von serverseitig generierten HTML-Vorlagen-basierten Webanwendungen unter Verwendung komplexer CSS-Stylesheets (wie bei früheren WordPress-Plugins) werden zu "Worst Practices" für das Schreiben von einseitigen Webapps. Die technischen Anforderungen für das Schreiben komplexer moderner clientseitiger Anwendungen mit nur einer Seite unterscheiden sich aufgrund der zunehmenden Komplexität des clientseitigen Codes von denen für hauptsächlich serverbasierten Code. Kurz gesagt, die alten "Best Practices" für die Verwendung von Vorlagen und komplexen Cascading Style Sheets lassen sich einfach nicht skalieren, was zu einer schwierigen Pflege des Codes führt.

Was ist die aufkommende Alternative? Moderne Webanwendungen können Mithril + Tachyons + JavaScript / TypeScript verwenden, um Komponenten in einzelne Dateien zu schreiben, bei denen der gesamte Code nur JavaScript / TypeScript ist. Solche Apps müssen nicht teilweise in CSS oder einer nicht standardmäßigen HTML-Variante geschrieben sein, die einen Teil einer Programmiersprache (schlecht) neu implementiert. (Nun, neben Tachyons oder ähnlichen Bibliotheken wird möglicherweise ein kleines Stück benutzerdefiniertes CSS benötigt, aber nur sehr wenig.)

Hier ist ein Beispiel für einen Codierungsspielplatz, den ich so geschrieben habe, mit mehreren Beispielen, die diesen Ansatz verwenden.

Wenn Sie Benutzeroberflächen mit HyperScript (plus einer Vdom-Bibliothek) schreiben, können Sie möglicherweise (mit etwas Arbeit) ein Backend wie Mithril durch fast jedes andere Vdom oder sogar eine Nicht-Vdom-Lösung ersetzen. Wenn ich die Wahl habe, die HyperScript-API zu verwenden, kann ich das Risiko verringern, dass zugrunde liegende Bibliotheken Fehler oder Lizenzprobleme aufweisen.

Durch die Verwendung von Tachyons oder ähnlichen Bibliotheken reduziere ich das Risiko nicht wartbarer CSS-Dateien, wenn die Anwendung wächst.

Zugegeben, ich weiß, dass viele Webentwickler mit der Optimierung von HTML aufgewachsen sind und HTML-aussehende Vorlagen lieben. Sie lieben JSX oder was auch immer und ignorieren gerne, wie schwierig es ist, solche Nicht-Code-Inhalte mitten in ihren Anwendungen umzugestalten oder zu validieren. Zugegeben, einige IDEs können JSX-Vorlagen besser umgestalten. Ich bin jedoch von der Desktop- und Embedded-Entwicklung zur Webentwicklung gekommen und habe mit Systemen gearbeitet, auf denen Sie (normalerweise) Benutzeroberflächen direkt aus Code generiert haben (z. B. mit Swing, Tk, wxWidgets usw.). Ich mag die Idee, dass Standardtools mir helfen können, den gesamten Code, an dem ich arbeite, umzugestalten und viele Inkonsistenzen zu erkennen.

Unter der Annahme, dass alle Frameworks, die hier ausgeführt werden, aufgrund ihrer Geschwindigkeit in dem Browser ihrer Wahl keine sichtbaren Unterschiede für den Benutzer aufweisen, können wir die Frontend-Leistung nicht mehr als Metrik verwenden, um zu bewerten, welches Framework die beste Wahl ist.

Wenn wir jedoch serverseitiges Rendering verwenden, sollten wir uns die SSR-Leistung genau ansehen. Calypso scheint SSR anzustreben. Und wenn dies erfolgreich ist, wird Calypso eines Tages die meisten Websites auf wordpress.com betreiben.

Ein Unternehmen bezahlt die CPU auf den Servern, nicht die CPU auf den Browsern. Aus Kostengründen bedeutet die 10-mal schnellere Renderzeit von Marko wahrscheinlich, dass derselbe Datenverkehr, der mit MarkoJS maximal 10 Server umfasst, tatsächlich mindestens 100 Server mit Vue benötigt.

Wenn Wordpress das ignorieren kann, werde ich gerne für das Unternehmen arbeiten und ein 10-faches Marktgehalt erhalten und Vue verwenden, das ich übrigens für eine gute Reaktionsalternative halte =)

Je leichter das Framework ist - das heißt, je weniger Funktionen es sofort bietet - desto schneller wird es ausgeführt. Es ist erbärmlich offensichtlich. Es ist eine Sache, die Leistung verschiedener Algorithmen zu vergleichen, aber wenn der größte Faktor darin besteht, wie viel anderes „Zeug“ ausgeführt wird, müssen Sie keine Tests schreiben.

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

@ahmadawais Angular-Kernteam hier - wir arbeiten an einer Reihe interessanter Arbeiten im Zusammenhang mit der Entwicklung des CMS / Widget-Stils, einschließlich der Investition in den Support für benutzerdefinierte Elemente (was für mein Geld die kluge Zukunftswette für den Aufbau von Plattformen ist).

Anstatt den Thread weiter zu überladen, würden wir uns freuen, mit Ihnen offline zu chatten, wenn Sie Interesse haben. Schreiben Sie mir bei robwormald bei google dot com. Viel Glück dabei, ich beneide dich nicht, dass du diesen Anruf tätigen musst ;-)

Ich habe hier eine einfache Umfrage zusammengestellt

Derzeit wird an der Ergebnisseite gearbeitet und darauf autorisiert. (neu in Firebase)

PS. Es dauerte ungefähr 1 Stunde, um dies mit Vue 🖖 zu machen

@vinayakkulkarni Wie wäre es, wenn Sie Mithril.js zu Ihrer Umfrage hinzufügen?

@pdfernhout : 👍

Getan. Ich habe MithrilJS zur Liste hinzugefügt.

• [x] VueJS
• [x] Winkel
• [x] Preact
• [x] Ember
• [x] Marko
• [x] Inferno
• [x] Aurelia
• [x] Mitrhil

Mal sehen, worüber sich die Leute entscheiden.
PS. Es gab auch eine Twitter-Umfrage von @ahmadawais .

Hallo. Ich bin ein Drupal Core Maintainer. Wie @ivanjaros in einem früheren Kommentar erwähnt hat, evaluieren wir auch Preact, Vue oder etwas anderes für einige bevorstehende Teile der Administrator-Benutzeroberfläche von Drupal. Wir entscheiden uns vielleicht für etwas anderes als das, was Sie wählen, aber was Sie wählen, wird sicherlich mindestens ein Faktor sein, den wir bei unserer Wahl berücksichtigen müssen.

Ich habe diese beiden Drupal-Ausgaben bisher geöffnet, und weitere werden folgen. Verweisen Sie sie hier nur auf Querverweise, falls diese Themen / Diskussionen für Sie nützlich sind.

• Komponenten, die mehrere Stammknoten zurückgeben
• Slots vs. VNode Requisiten

Beachten Sie, dass ich Vue trotz dieser beiden Probleme immer noch sehr mag. Das könnten Dinge sein, mit denen wir leben können, um alle anderen Vorteile von Vue zu nutzen.

Als Autor von Vue werde ich es vermeiden, Kommentare dazu abzugeben, welchen Rahmen ich hier wählen soll, da ich offensichtlich voreingenommen bin. Aber als ich die Aussage sah, dass "Marko 10x schneller als Vue ist", die ein paar Mal herumgeworfen wurde, denke ich, dass es eine Klarstellung verdient. Ich möchte die Diskussion auch nicht in eine technische Debatte einfließen lassen , deshalb habe ich einige Gedanken in

@ michaelbdavidson7 bezüglich der finanziellen Bedenken: Ich arbeite seit über 1,5 Jahren ganztägig an Vue und die Patreon-Unterstützung war wirklich stabil. Anstatt über Schwankungen des Patreon-Versprechens zu spekulieren, können Sie die Commit-Aktivität von Vue überprüfen, um selbst zu beurteilen. Darüber hinaus bedeutet ein offener Kanal für finanzielle Beiträge, dass WP / Automattic die Nachhaltigkeit von Vue problemlos sicherstellen kann, indem es ein wichtiger Sponsor wird (Matt selbst ist bereits ein persönlicher Sponsor!) - was tatsächlich mit den Interessen beider Projekte übereinstimmt.

Ich stimme Vuejs

@ tungbt94 Warum?

Auf jeden Fall VueJS

Die größere Frage, warum wurde vor dieser Patentausgabe gewählt. Wenn es kein Patent wäre, würden Sie trotzdem reagieren? Viele Punkte, die gemacht werden, wenn man sich nicht für Preact entscheidet, sind die gleichen wie für das Nicht-Reagieren.

Meine Stimme ist bei Preact

Da ich mit nichts anderem als Reagieren nicht viel Erfahrung habe, werde ich mich nicht darauf konzentrieren, welchen Rahmen ich wählen soll.
Ich denke jedoch, dass das Argument der "großen Gemeinschaft" von geringerer Bedeutung sein kann. Warum? Denn wenn sich Automattic für ein Framework entscheidet, werden durch diese Farmarbeit Tausende neuer Benutzer gewonnen. Und wenn ich weiß, dass die WP-Community korrekt ist, werden viele von ihnen auch zu diesem Rahmen beitragen und die Popularität wird steigen.

In Anbetracht dessen, wo sich Gutenberg und Calypso im Moment befinden, denke ich immer noch, dass Preact die beste technische Wahl ist.

Wenn Sie jedoch immer noch das Gefühl haben, Brücken mit einer Ähnlichkeit mit React zu brennen, oder wenn Sie von vorne anfangen mussten, glaube ich immer noch, dass MarkoJs die beste Wahl ist. Ich denke, die Unterstützung der Community könnte immer noch ein Problem sein.

Unter der Annahme, dass Github-Sterne irgendwie mit der Community korrelieren, ist Vue im Vergleich zu MarkoJs immer noch 10x, ansieht , wird sich dies schnell ändern.

Vue wächst linear:

Aber MarkoJs scheint sich am Wendepunkt eines exponentiellen Wachstums zu befinden:

@ patrick-steele-idem, der Hauptautor von MarkoJs , war auf https://gitter.im/marko-js/marko immer sehr reaktionsschnell

Wenn sich die Leute letztendlich für MarkoJs entscheiden, aber wirklich für jede Art von Community, möchte ich umschreiben : "Fragen Sie nicht, was die Community für Sie tun kann - fragen Sie, was Sie für die Community tun können."

Persönlich möchte ich @ahmadawais zum Erstellen eines einzigen Problems gratulieren, das bei vielen JS-Entwicklern, die die relevanten JS-Bibliotheksoptionen verwenden und unterstützen, ein erhebliches Engagement hervorgerufen hat.

Ich vermute, dass dieses Problem dazu beigetragen hat, mehr JS-Entwickler über WordPress-Schritte zu einer JavaScript-basierten Entwicklung über Gutenberg zu informieren als jede andere Gutenberg-Kommunikation bisher.

Ich benutze AngularJS, aber was mir nicht gefällt, ist jedes Mal das Hauptupdate, also werde ich mich für VueJS entscheiden.

+1 für Marko. Tolle Bibliothek, die unser Team nutzt und mit der wir sehr zufrieden waren. Async-Rendering, superschnell (Rendering auf String im Server und auf Vdom im Browser), Einzel- oder Mehrfachdateikomponenten und IMO die beste Template-Syntax.

Bitte berücksichtigen Sie das hyperHTML von @WebReflection .

Ich mag Angular

Ich stimme Angular

Ich wähle Angular

nur eckig

Ich wähle Angular

eckig

Ich stimme Angular

Ich stimme Angular

Wenn Sie für ein Framework stimmen möchten, wäre es schön, den genauen Grund zu kennen und zu erfahren, wie es Gutenberg hilft.

Geben Sie den Leuten, die hierher kommen, um nur "Ich stimme X" zu sagen, einige Gründe an, warum wir auch X wählen sollten. "Ich stimme X" sagt uns nichts anderes, als dass du X magst.

Ich wähle eckig. Angular hat seit Version 2 einige große Veränderungen. Jetzt ist es vollständig, gut - stark und weit verbreitetes Gerüst -, da es wie ionische nicht schnell, aber stark studiert.

Bei so vielen Spam-Mails „Ich stimme abRahmen “, kreischt Github für mich.

Ich fordere andere Entwickler auf, Ihre Wahl des Frameworks unter https://vinayakkulkarni.github.io/poll/ https://vinayakkulkarni.github.io/poll/ zu wählen, anstatt nur "Ich stimme ..." zu veröffentlichen.

Ein weiterer Vorschlag ist, diese Konversation zu sperren. Die meisten großen Entwickler haben bereits zu Wort gekommen.

Am 18. September 2017, um 20:01 Uhr, schrieb Mingyue [email protected] :

Ich wähle eckig. Angular hat seit Version 2 einige große Veränderungen. Jetzt ist es vollständig, gut - stark und weit verbreitetes Gerüst -, da es wie ionische nicht schnell, aber stark studiert.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub https://github.com/WordPress/gutenberg/issues/2733#issuecomment-330241898 an oder schalten Sie den Thread https://github.com/notifications/unsubscribe-auth/AS3FbT23DvVwTLGL61tmK7KtuwZ- stumm

danke @kidwm für die Erwähnung von _hyperHTML_, aber ich denke, es ist besser, ihrer Richtung zu folgen:

Teilen Sie nicht nur mit, welches JS-Framework Ihnen gefällt, sondern auch, warum

Also lass mich versuchen, das zu tun ...

: zap: hyperHTML :

• PRO : Anfängerfreundlich und P / React-Benutzern vertraut (anstelle von JSX schreiben Sie Vorlagenliterale)
• PRO : blitzschnell und ohne VDOM; weniger Speicherverbrauch (Telefone für Schwellenländer freundlich)
• PRO : Benötigt keine Tools (erfordert transpilierte Template-Literale nur für IE <11)
• PRO : Vollständig basierend auf JS / DOM / HTML-Standards, aber auch kompatibel mit TypeScript
• PRO : Passt in weniger als 5 KB (min-zipped), ohne dass zusätzliche Polyfills oder Browser-Patches erforderlich sind
• PRO : 100% Codeabdeckung bis hin zu IE9-Macken
• PRO : teilt dieselbe API mit seinem NodeJS-Gegenstück ; 100% serverseitiges Rendering kompatibel
• PRO : Es kann vorhandenes DOM übernehmen, ohne SSR-Layouts / -Knoten zu zerstören
• PRO : Funktioniert mit benutzerdefinierten Elementen besser als P / React. Es kann auch zum Definieren von benutzerdefinierten Elementen verwendet werden
• PRO : Es kann genau das tun, was React , Vue.js , Polymer , Angular oder Marko tun, und es gewinnt in Bezug auf Größe, Bandbreite und Leistung

Entsprechend den bisher in diesem Thread verwendeten Metriken wird nun die CONS

• Nachteile : Selbst wenn es kampferprobt, vollständig testbedeckt und mit einer eingefrorenen API ausgestattet ist, handelt es sich um ein relativ junges Projekt (März 2017), sodass es hinsichtlich Popularität, Akzeptanz oder Anzahl der Mitwirkenden nicht mithalten kann
• Nachteile : Die Community hilft sehr und das Projekt wächst, aber bisher bin ich ein wichtiger technischer Mitarbeiter. Ich bin jedoch zu 100% diesem Projekt verpflichtet und bereit, es so weit wie möglich voranzutreiben. Außerdem diskutiere ich mit wenigen "_bigs_" über die Verwendung von _hyperHTML_ in einigen der nächsten großen Projekte von ihnen (ich werde nicht weiter spekulieren Sie können diesen letzten Teil jedoch ignorieren.

: dart: Ich bin der festen Überzeugung, dass die Zukunft des Web darin besteht, die Plattform so weit wie möglich zu nutzen. Dies ist definitiv viel besser als vor 10 Jahren und dank moderner ECMAScript-Spezifikationen einfacher zu schreiben, zu lesen und zu warten. _hyperHTML_ repräsentiert den "aktuellen Zustand der Webkunst" in Bezug auf Potenziale, während jeder andere Anwärter in dieser Liste in der Zeit vor der vollständigen ES6 geboren wurde.

Ich verstehe, dass Community-Größe, Mitwirkende und GitHub-Stars wichtig sind, aber ich denke, dass Tests, browserübergreifende Codeabdeckung und die Anzahl der Fehler ebenfalls berücksichtigt werden sollten, und ich gebe mein Bestes, um die Anzahl von _hyperHTML_ und Freunden in der Nähe zu halten Null (es ist momentan eigentlich Null, neben einer Diskussion, die kein Fehler ist).

Last but not least, wenn niemand neuen Lösungen eine Chance gibt und nur nach Stars und Hype urteilt, werden neue Lösungen länger dauern, als diese sollten, um populärer zu werden.

Natürlich habe ich über meine neueste Lösung gesprochen, meine Überlegungen könnten als subjektiv angesehen werden, aber insbesondere mein letzter Satz über das Geben einer Chance für neue Lösungen war sehr allgemein, nicht nur über meine Bibliotheken: smiley:

Freundliche Grüße

Ich mag eckig

muss eckig und google sein.

Ich liebe eckig

Angular ist nur ein realer Rahmen!

Ich wähle Angular, nicht AngularJs.

Nur eckig ist ein echter Rahmen!

Ich fange an zu vermuten, dass diese Kommentare von Bots gemacht werden.

@OP : Bitte sperren Sie diesen Thread.

Ich stimme für Angular (NICHT AngularJS).

Angular ist ein Platorm. Das Google-Team leistet eine Menge großartiger Arbeit, um den Entwicklungsfortschritt zu vereinfachen. Dazu gehören die Komponente, das Modul und der Router. Mit der Abhängigkeitsinjektion können Sie viel Arbeit sparen, um alle Abhängigkeiten zu arrangieren Mit dem Angular-Cli können Sie viel Arbeit sparen, um ein brandneues Projekt zu starten. Sie öffnen einfach die Box und Ihre App ist gut kompiliert mit AOT, Baumschütteln und vielen anderen Optimierungen.

TypeScript ist ein weiteres großartiges Tool mit Angular. Es wird von MicroSoft bereitgestellt, auch bekannt als die gesamte Angular-Plattform, die mit ts erstellt wurde. Sie erstellen Ihre App auch mit ts! Es ist ein großartiges Werkzeug, um das Leben zu erleichtern, wenn die Menge an Code immer größer wird. Sie können das Refactoring in der IDE (wie vscode) mit nur einem Klick durchführen. Durch die statische Typprüfung können Sie die Fehler so früh wie möglich finden. TS bietet auch eine gute Implementierung von OOP. Sie können Ihren Code viel besser arrangieren und wiederverwenden.

Es gibt auch viele Komponenten, die auf Winkel basieren, wie Meterial Design2, Primeng, und ich möchte Ihnen Jigsaw empfehlen, das von unserem Team erstellt wurde. Es wird vom Big Data-Produkt von ZTE China übernommen. Es unterstützt jetzt alle Apps von ZTE.

Anglar ist eine gute Wahl!

An alle Bots: 🖕

Wahrscheinlich hat jemand in einer AngularJs-Community gepostet. Ich denke, die Leute können den Thread stummschalten, wenn sie keine weiteren Nachrichten mehr erhalten möchten.

Ich denke, dass irgendwann ein ähnliches Gespräch zu diesem Thema an einem Ort stattfinden muss, an dem es nur WordPress-Mitwirkende gibt.

Ich möchte einige meiner Gedanken zu diesem Thema teilen, die ich größtenteils bereits in der EmberJS Slack Community Group geäußert habe. Wenn Sie 10 Minuten Zeit haben, um die Diskussion dort zu lesen, würde ich sie empfehlen: https://embercommunity.slackarchive.io / wb-marketing / page-2 / ts-1505456102000189 Es gibt ziemlich viel, aber ich würde wärmstens empfehlen, es

Meine Hauptpunkte in dieser Diskussion sind wie folgt:

• Wenn man einen 2-4-wöchigen Anstieg der Implementierung von etwas im Ember-Framework mit einer anderen Bibliothek vergleicht, gewinnen die anderen Bibliotheken kurzfristig, aber Ember gewinnt für ein längerfristiges Projekt
• Bei der Überlegung, welche Bibliothek oder welches Framework dazu gehören soll, ist es wichtig, nicht nur die technische Implementierung, sondern auch die Aspekte der "Soft Skills" zu berücksichtigen (Community-Größe, Engagement zur Unterstützung von LTS, Beteiligung der Community an den Kernentscheidungen des Projekts).
• Ember hat eine Erfolgsgeschichte darin, Anwendungen, die mit dem ember-cli "unter der Haube" erstellt wurden, erheblich zu verbessern, dh ohne dass der Anwendungscode aktualisiert werden muss. Es gab auch Fälle von geringfügigen Upgrades des Anwendungscodes (mit eingeschlossenem Code-Mod unter Verwendung von Dingen wie Ember-Watson ), bei denen Sie eine signifikante Leistungs- und Produktivitätssteigerung erzielen.

Ich möchte in diesem Kommentar nicht zu sehr ins Detail gehen, da ich gerne einen Aufsatz mit 10.000 Wörtern zu den oben genannten Punkten schreiben könnte. Ich möchte jedoch meine Zeit jedem anbieten, der dieses Problem mit jemandem diskutieren möchte, der eine "Ember-Denkweise" hat.

Wenn jemand von den Entscheidungsträgern einen einstündigen Anruf bei mir haben möchte, um gezieltere Fragen zum weiteren Ember-Ökosystem zu stellen, würde ich dies gerne tun. Sie können mich auf meinem Twitter erreichen (DMs offen). Ich bin möglicherweise kein Mitglied des Kernteams, aber ich erstelle Ember-Apps seit vor 1.0 und habe alle Upgrade-Prozesse mit verschiedenen Apps durchlaufen

Ich arbeite für "Mein eBay" bei eBay. Wir haben gerade unsere erste Single-Page-App veröffentlicht . Wir haben jede Entwicklungsphase mit MarkoJS genossen. Wie ich, wenn Sie das Streaming-Programmierparadigma von Node lieben, unterstützt MarkoJS Streaming und asynchrones Rendern. Weitere Fakten, die mir an MarkoJS gefallen haben:

• seine effiziente Bindung des Verhaltens von UI-Komponenten, die auf dem Server und im Browser gerendert werden.

• Sehr effiziente Eventdelegation

• Schnelle Serialisierung des Status vom Server zum Browser

@vinayakkulkarni Ich finde deine Idee nett, aber das Problem ist, dass ich durch einen Browserwechsel mehr als 1 Stimme abgeben kann (ich habe es nicht mit demselben Browser versucht).

Sie sollten wahrscheinlich eine Twitter-Umfrage verwenden (aber es gibt bereits eine) oder ein Anmeldesystem implementieren, um Stimmen eindeutig zu machen.

Server-Rendering ist hier für die Konversation nicht relevant. Node wird nicht Teil des erforderlichen WordPress-Stacks. Wie schnell diese Frameworks in Node gerendert werden, ist für eine Entscheidung nicht relevant.

Vue.js! Schauen Sie sich dieses Projekt an: https://github.com/bstavroulakis/vue-wordpress-pwa

Ich habe Angular (nicht AngularJS) gewählt, es hat die größte Community, ein stabiles und vollständiges Ökosystem.

Angular ist sehr langsam und mit v4 basiert es auf Typoskript, es ist nutzlos für die WordPress-Entwicklung.

Ich wähle Angular aufgrund der Reife der Plattform

Ich würde für Vue stimmen, weil es einfacher zu lernen ist und weil mein Lieblings-Framework Ember Js zu groß für den Job ist und Glimmer Js noch zu neu ist. :-)

Server-Rendering ist hier für die Konversation nicht relevant.

In meinem Fall habe ich gerade eine Funktion erwähnt, die andere für relevant hielten

Der Knoten wird nicht Teil des erforderlichen WordPress-Stacks

_hyperHTML_ kann jeden serverseitig gerenderten Inhalt abrufen, einschließlich PHP. Ich bin ein Zend-zertifizierter Ingenieur und habe bereits mit WordPress / Journalisten / Verlegern zusammengearbeitet. Mein Hinweis war nicht aus heiterem Himmel.

Wie schnell diese Frameworks in Node gerendert werden, ist für eine Entscheidung nicht relevant.

Die Tatsache, dass ein Framework auch im Backend funktioniert, serverseitig gerenderte Inhalte aufnehmen kann und sogar mit NativeScript kompatibel ist, ist vielleicht ein Plus, das heute irrelevant ist, aber eine zukunftsfähige Funktion, die ein offenes Projekt in Betracht ziehen könnte.

@webreflection Ich abzielt . Es war eher eine Antwort auf den Kommentar über mir, in dem Markos "Streaming-Paradigma" hervorgehoben wurde, aber es sollte alle Kommentare zur BE-Rendering-Leistung abdecken.

Aussicht

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

Dieser Beitrag wird nicht veröffentlicht, und stattdessen möchte ich sagen, dass das Gutenberg-Team einen Schritt zurücktreten und Gutenberg mithilfe einer anderen Bibliothek neu schreiben wird. Es wird Gutenberg wahrscheinlich um einige Wochen verzögern und die Veröffentlichung möglicherweise auf das nächste Jahr verschieben.

Und noch wichtiger:

Automattic wird auch alles verwenden, was wir für Gutenberg auswählen, um Calypso neu zu schreiben

Calypso verwendet bereits serverseitiges Rendering. Siehe: https://github.com/Automattic/wp-calypso/blob/master/server/render/index.js#L58

Mein Verständnis ist also, dass SSR-Leistungen relevant sind.

Ich liebe auch eckig！
AngularJS js reales Framework！

Ich stimme für Angular

@chriscinelli Das ist Automattic, nicht WordPress. WordPress selbst führt kein Server-Rendering mit Knoten durch, daher ist die Leistung unter diesen Bedingungen für das Projekt nicht relevant.

Offensichtlich ist Angular die beste Wahl

Ich stimme für Angular

Ich stimme für Angular

Ich stimme für Vue.js.
Dies spart die meiste Zeit, insbesondere beim Umgang mit Ansichtsebenen.

Ich muss für Vue stimmen !!!

Wirf eine eckige Welle

@trotyl Dieser Kommentar ist nicht akzeptabel. Ich habe Ihren Kommentar bearbeitet, um ihn zu entfernen.

Oh, bitte nicht AngularJS
Jetzt ist Angular.

@mAAdhaTTah Aus Wikipedia:

WordPress wurde am 27. Mai 2003 von seinen Gründern Matt Mullenweg und Mike Little als Gabel von b2 / cafelog veröffentlicht

Obwohl WordPress größtenteils von der umliegenden Community entwickelt wurde, ist es eng mit Automattic verbunden , dem von Matt Mullenweg gegründeten Unternehmen.

Dies ist Calypso: https://developer.wordpress.com/calypso/ und Calypso verwendet SSR.

Wie ich in meinem vorherigen Kommentar geschrieben habe , geht aus dem Blog-Beitrag , in dem die ReactJS-Unterstützung von Matt eingestellt wurde, ziemlich klar hervor, dass Gutenberg und Calypso auf der gleichen Technologie bleiben sollen. Automattic wird Calypso-Seiten von ihren Servern mit SSR bereitstellen.

Ich denke, dies reicht aus, um die SSR-Leistung für diese Entscheidung relevant zu machen.

In einer weit entfernten Zukunft könnte jedoch ein neues verrücktes Projekt herauskommen, sobald sich Wordpress-Entwickler an Preact (oder Vue oder Marko oder ein anderes Framework) gewöhnt haben, und sie beschließen, noch mehr Teile von Wordpress über Knoten bereitzustellen. Das wird SSR noch wichtiger machen. Daher können SSR-Leistungen noch wichtiger sein.

Da das Gespräch zur Erörterung von SSR weitergegangen ist, halte ich es für ratsam zu erwähnen, dass dies für Ember eine sehr hohe Priorität hat und mit dem Aufkommen von Ember-Fastboot ziemlich ausführlich durchdacht wurde

Obwohl ich Fastboot (mit großer Wirkung) mit einigen Clientanwendungen verwende, da dies eine hochrangige Technologiediskussion ist, würde ich empfehlen, sich an @tomdale zu

@chriscinelli WordPress das Community-Projekt und Automattic das Unternehmen sind immer noch getrennte Einheiten. Wenn Automattic aufgrund von SSR für das eine oder andere argumentieren möchte, können sie dies, aber es ändert nichts daran, wie wir, die WordPress-Community, den Rahmen der Wahl für den WordPress-Kern berücksichtigen sollten, der dies nicht tut und wirklich nicht kann. Knoten müssen ausgeführt werden.

Wie auch immer, ich habe mich von diesem Thread abgemeldet. Wenn Sie diese Diskussion offline fortsetzen möchten, befindet sich meine E-Mail-Adresse in meinem Profil.

erfordert nicht und kann wirklich nicht, dass ein Knoten ausgeführt wird.

Bitte machen wir die SSR-Fähigkeit nicht zu einem Unterscheidungspunkt. Frameworks, die in der Lage sind, SSR-Knoten zu erstellen, können überhaupt ohne SSR-Knoten leben: Dies ist nur eine zusätzliche Funktion, keine Anforderung oder Abhängigkeit.

Ich würde für Vue.js stimmen

Ich bin ein hochrangiger Bogen, der zum MIT gegangen ist und einigermaßen schlau sein soll. Ich mache das seit vielen Jahren und habe hier und da ein paar Entwickler interviewt. Ich weiß, dass das Web voller kluger Leute ist, aber jeder, der glaubt, dass die Einfachheit von Vue mit der Komplexität von Angular gleichzusetzen ist, hat die Perspektive verloren, was "komplex" ausmacht. Komponentenbasiertes Javascript, wie Google es konzipiert hat, ist völlig nicht trivial. Es ist lächerlich komplex. Vue ist nicht. Vue ist so einfach wie PHP. Ich sage das Offensichtliche, denn "Vue ist leichter zu lernen" kommt nicht einmal der Beschreibung nahe, wie viel einfacher Vue ist als Angular. Und hier ist der Haken: Ich denke, es ist auch viel einfacher als Reagieren.

React war für Durchschnittsbürger die Grenze zwischen Easy-Peasy und Google-Level. Für kleine Geschäfte würde ich sagen, dass React komplex genug ist, um kleine Teams herauszufordern. Die Reaktion ist komplexer als beispielsweise PHP / Wordpress. Durch die Auswahl von React erhöhte Wordpress / Automattic die Anforderungen für den Einstieg von Entwicklern in die Wordpress-Entwicklerwelt. Ich bin sicher, Hunderte von Menschen werden schreien: "Reagieren ist einfach" und "Das Web wird intelligenter", aber am Ende des Tages ist komplexer immer noch komplexer.

Ich denke demütig, dass ein Rückzug nach Vue näher an den WP-Wurzeln liegt und die WP-Community insgesamt weniger technisch belastet. Abgesehen von Web-Paradigmen - manchmal ist einfach gut.

Angular und Vue sind zwei verschiedene Dinge

Vue, React, MarkoJS, Inferno, Preact usw. sind Bibliotheken, die nur die Ansichtsebene abdecken. Alle, einschließlich Angular, haben die Möglichkeit, HTML zu erstellen und das DOM deklarativ zu mutieren. Angular möchte ein vollständiges Framework für die Frontend-Entwicklung bereitstellen und hat viel mehr Dinge als die Ansichtsebene.

Die Syntax von React ist die älteste in diesem Beispiel. Facebook hat ziemlich gute Arbeit geleistet, um eine sehr komplexe Bibliothek zu binden, die viele Dinge (vielleicht zu viele) auf einer sehr begrenzten Protokolloberfläche erledigt. Sie müssen diese Komplexität in React nicht kennen, um zu wissen, wie Sie sie verwenden und damit produktiv arbeiten können. Sie können das Grundlegende lernen und in einem halben Tag damit beginnen.

Jede andere Bibliothek in dieser Liste hat von React gelernt. Sie versuchten, die Syntax zu vereinfachen, die Leistung von React zu verbessern, die Größe des Javascript-Codes zu reduzieren, der erforderlich ist, um dieselben Aufgaben auszuführen, und einige Funktionen hinzuzufügen.
Preact hat großartige Arbeit geleistet, um eine Schnittstelle, die React sehr ähnlich ist, in nur 3 KB zu halten.
Inferno und Marko haben die Rendering-Leistungen massiv optimiert.
Marko und Vue haben die Syntax stark vereinfacht, um den Boilerplate-Code zu reduzieren.
Marko fügte außerdem eine optionale Jade / Pug-ähnliche Syntax hinzu, um den Code trockener zu halten und asynchrone Vorlagen zu erstellen, die alles für den Benutzer einfach und intuitiv halten.

Bei all diesen Bibliotheken neben Angular müssen die Ingenieure jedoch eine Strategie und Mechanismen zum Abrufen von Daten, Routing usw. entwickeln. Redux und seine Middlewares sind eine beliebte Methode, mit der Gutemberg die Datenschicht verwaltet.

Bei der Migration von React braucht Gutenberg nicht "nur noch etwas zu ändern". Selbst wenn Angular bestrebt ist, sich für den Benutzer agnostisch zu halten, ist die Verwendung mit Redux und Javascript (im Vergleich zu Typescript) keine natürliche Wahl, obwohl Bibliotheken wie https://github.com/angular-redux/ng-redux entwickelt und unterstützt wurden für Javascript ist verfügbar. Wenn man sich die bisherigen Stimmen ansieht, scheint es, dass die Gutenberg-Community stark gegen das Google-Framework ist. Angular wird also höchstwahrscheinlich keine Option sein.

PHP und jedes dieser Javascript-Frameworks sind völlig unterschiedliche Biester

Sie können ein PHP-Backend und ein App-Frontend für eine einzelne Seite haben, aber es gibt keine Synergien und kleine Ähnlichkeiten.

Jede Javascript-App ist mindestens eine Größenordnung komplexer als das Schreiben von einfachem PHP-Code, der mit etwas jQuery bestreut ist. Alle modernen Javascript-Apps müssen sich mit den beiden großen Komplexitätsmonstern auseinandersetzen: Statefulness und asynchrone Abläufe . Sie werden in den letzten Jahren nur durch Unveränderlichkeit und async / await gemildert. Der Entwicklerfluss wird langsam, wenn die Anwendung wächst. Wenn Sie Code ändern, müssen Sie ihn neu kompilieren, neu starten und die App muss erneut initialisiert werden. Es wurde eine enorme Menge an Werkzeugen gebaut, um Hot-Reloads zu implementieren, und selbst wenn sie fantastisch sind, sind sie noch lange nicht perfekt.
Unabhängig davon, welche Bibliothek Sie für die Ansichtsebene auswählen, müssen Sie sich mit der zusätzlichen Komplexität auseinandersetzen.

In PHP ändern Sie den Code, speichern eine Datei und können die Seite sofort neu erstellen, ohne sie zu erstellen oder neu zu laden. Funktioniert alles. Und was noch wichtiger ist, PHP ist völlig zustandslos . Jedes Mal, wenn Sie die Seite neu laden, haben Sie eine leere Tafel. Sogar die globalen Variablen haben bei jeder Anforderung einen sauberen Status (aber es ist keine gute Entschuldigung, sie zu verwenden = P). Ich habe seit einigen Jahren keinen PHP-Code mehr geschrieben, aber ich vermisse immer noch seine Einfachheit und seine Entwicklererfahrung. Wenn Sie ein modernes Framework wie CakePHP, Symphony oder Laravel verwenden, verpassen Sie im Vergleich zu anderen Sprachen und Frameworks, die von erfahrenen Ingenieuren eher begrüßt werden, nicht viel. Die Ausnahme ist die Geschwindigkeit. PHP zahlt seine Einfachheit mit Laufzeitleistungen. Jedes Mal, wenn Sie eine Seite neu laden, muss der gesamte Code erneut ausgeführt werden. Die Leistung von HHVM und PHP7 hat sich stark erhöht, aber im Allgemeinen sind sie noch weit von dem entfernt, was Sie mit node.js erreichen können.

Fazit

Es spielt keine Rolle, welche Bibliothek Sie kürzlich für das Frontend verwendet haben. Auch wenn Sie es lieben, bedeutet es nicht, dass es die beste Wahl für Gutenberg ist.
Die Tatsache, dass _die meisten von Gutenbergs Hauptverantwortlichen_ eine bestimmte Bibliothek mögen, ist jedoch wichtig.

Schlussendlich:

Ein Mann, der gegen seinen Willen überzeugt ist, ist immer noch der gleichen Meinung

Ich denke, es gibt eine ziemlich große Menge an Informationen in diesem Thread über Vor- und Nachteile verschiedener funktionsfähiger Bibliotheken.

Gutenbergs und Wordpresss Mitwirkende sollten allein gelassen werden und sich möglicherweise in "verschlossenen Türen" treffen, weg von den Frontend-Fanboys.
Es kann an der Zeit sein, Ihre Werte, Ziele und Einschränkungen zu klären und den Rahmen basierend auf der Maximierung Ihres Ergebnisses auszuwählen.

Und nochmals viel Glück bei Ihrer Entscheidung 😃

Ich habe meine Stimme für Vue abgegeben. Anfängerfreundlich und robust. Als ich anfing, Vue zu verwenden, hatte ich das Gefühl, als ich anfing, mit WordPress zu entwickeln. + 💯

@ bunte Töne nur anfängerfreundlich ist gar nicht gut genug! Jedes Projekt hat einen Lebenskreislauf, der größte Teil der Arbeit befindet sich im Wartungsfortschritt.

@ChrisCinelli Einige Klarstellungen und Meinungen:

Angular möchte ein vollständiges Framework für die Frontend-Entwicklung bereitstellen und hat viel mehr Dinge als die Ansichtsebene.

Vue verfügt über offizielle Bibliotheken für Routing, Statusverwaltung, Tests, Flusen und mehr sowie ein offizielles CLI-Tool. Alle diese sind unter der vuejs-Organisation, werden von Kernmitgliedern gepflegt und mit Vue selbst synchronisiert, aber das Beste daran ist, dass Sie sie nicht lernen oder verwenden müssen (daher die 'Progressive Framework'-Philosophie). Im Gegensatz zu React ist dies ein Rahmen in seiner offiziellen Form. Kleines Wortspiel: All dies ist zwar einfacher zu lernen, schneller und leichter als Angular. :Lächeln:

Marko fügte auch eine optionale Jade / Pug-ähnliche Syntax hinzu

.vue -Dateien können einen beliebigen Präprozessor für die Vorlage, das Skript oder den Stil verwenden (z. B. Mops, Typoskript, Coffescript, Sass, Stift ...). Verwenden Sie, was am besten zu Ihrem Projekt passt!

Die Ingenieure müssen eine Strategie und Mechanismen zum Abrufen von Daten entwickeln

Dies ist nur ein Beispiel, aber das Abrufen von Daten muss nicht überarbeitet werden:

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

Von dort aus können Sie ein sehr einfaches Vue-Plugin erstellen, um den Code noch präziser zu gestalten.

Vue selbst sollte nicht die richtige Bibliothek für diesen Job sein, da es immer bessere dedizierte Bibliotheken gibt (aus diesem Grund bieten wir beispielsweise standardmäßig keine Datumsfilter an, da Sie stattdessen ohnehin moment oder eine andere großartige Bibliothek verwenden würden). . Wir sind auch dabei, ein Kochbuch mit empfohlenen Pfaden und Praktiken für verschiedene Geschäfts- und Anwendungsfälle zu schreiben.

Wenn Sie Code ändern, müssen Sie ihn neu kompilieren, neu starten und die App muss erneut initialisiert werden.

Der einzige wirkliche Unterschied ist der Build-Schritt, der heutzutage mit Tools wie dem offiziellen vue-cli oder poi einfach sehr gut .

Sie müssen sich mit der zusätzlichen Komplexität auseinandersetzen.

IMHO scheinen einige sehr beliebte PHP-Frameworks komplexer und schwieriger zu erlernen zu sein als einige Frontend-Bibliotheken / Frameworks wie Vue. (Das Gegenteil ist auch sehr wahr.)

Aufgrund meiner mehr als zweijährigen Erfahrung beim Aufbau eines blockbasierten Editors ähnlich wie Gutenberg denke ich, dass bei der Auswahl des richtigen Frameworks einige Anlaufschwierigkeiten zu berücksichtigen sind, z

• Wie würde sich VueJS / Marko / Angular in Drag & Drop integrieren? Wie würde Drag & Drop in Gutenberg funktionieren? Klonen Sie beim Ziehen ein Geisterelement oder verwenden Sie das vorhandene Element? Wo können Sie beim Ablegen Platzhalter einfügen, um einen Block abzulegen?

• Wie würde VueJS / Marko / Angular (und sein virtuelles DOM) mit Content Editables und der DOM Range & Selection API funktionieren? Browserübergreifende Inkonsistenzen mit diesem Bereich und dieser Auswahl können hier sehr schwer zu erkennen sein.

• Inwieweit funktioniert das Kopieren / Ausschneiden / Einfügen im Gutenberg-Editor? Kann ich eine Textauswahl zwischen mehreren Blöcken treffen und ein Ausschneiden / Kopieren / Einfügen durchführen? Befinden sich bearbeitbare Inhalte in den einzelnen Blöcken oder ist alles in einem inhaltsbearbeitbaren Master enthalten?

• Wenn es Gutenberg-Blöcke gibt, die eingebettete Iframe-Dateien enthalten, z. B. das Einbetten eines YouTube-Players oder eines Twitter-Feeds in einen Blog-Beitrag, führt das Verschieben dieses Blocks von einer DOM-Position an eine andere Position dazu, dass sich der Iframe neu lädt. Weitere Einschränkungen sind die Unfähigkeit, Ereignisse vom Iframe zurück in den Editor zu übertragen (stellen Sie sich vor, Sie ziehen ein Blockelement über den Editor und Ihr Cursor bewegt sich jetzt auf dem standortübergreifenden Iframe und alles funktioniert nicht mehr).

Alle Frameworks eignen sich hervorragend für die Arbeit mit Virtual DOM, aber viele WYSIWYG-Anwendungen werden außerhalb des Virtual DOM verwendet. Ich denke, die Bereiche, auf die man sich bei der Bewertung des richtigen Frameworks für Gutenberg konzentrieren sollte, sind, wie gut das Framework mit der Behandlung von DOM-Ereignissen umgehen kann und wie hoch verwaltbar es ist, es außerhalb des Frameworks zu erstellen und stecken Sie es wieder ein.

Aussicht

Wordpress ist für neue Entwickler leicht zu erlernen und bietet auch viel Leistung, wenn Sie etwas genauer hinschauen. Gleiches gilt für Vue.
Ich würde mich freuen, wenn WP dieses Framework verwendet!

Meine Stimme ist VUE!

In Bezug auf die Erstellung benutzerdefinierter Webkomponenten, die meiner Meinung nach in Zukunft sehr wichtig sind, bietet diese Website eine Bewertung für jedes aufgelistete Framework mit Testparametern und Bewertungen. Es ist lehrreich und würde jeden ermutigen, es noch einmal zu geben:

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

Meine Stimme für VueJS. Toller Rahmen, ich denke, Laravel hat es bewiesen.

WP + Sage 9 (root.io) + VueJS => perfekter Stapel

Möglicherweise liegt auch ein Problem mit Preact vor.

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

Die Verwendung von Preact kann Sie schlechter stellen als die Verwendung von React. Facebook darf Sie daran hindern, zu reagieren oder zu predigen, selbst wenn Sie die Klage nicht eingeleitet haben. Dieser Anwalt scheint der Meinung zu sein, dass Preact sein Urheberrecht vor Gericht nicht aufrechterhalten kann und als Reaktion auf eine Reaktion angesehen wird.

Sag mir, wenn ich falsch liege. Ich weiß nicht viel über Recht, wollte aber hilfreich sein.

Ich habe das gelesen und es ähnelt der Rechtsberatung, die wir nach unserer Entscheidung erhalten haben
aufgeben Reagieren Sie in unseren Projekten. Es ist nicht so, dass das Risiko riesig ist. Eher wir
wollte das Risiko für nachgeschaltete Kunden minimieren. Dieser Anwalt fügt nur ein
übereinstimmende Meinung. Wir verwenden stattdessen Polymer und Vue, beide funktionieren hervorragend
für bestimmte Anwendungsfälle.

Am 20. September 2017, 23:04 Uhr, schrieb "Coding Friend" [email protected] :

Möglicherweise liegt auch ein Problem mit Preact vor.

https://blog.cloudboost.io/3-points-to-consider-before-
Migration-weg-von-reagieren-wegen-Facebook-bsd-
Patent-Lizenz-b4a32562d268

Die Verwendung von Preact kann Sie schlechter stellen als die Verwendung von React. Facebook wäre
darf dich daran hindern, zu reagieren oder zu predigen, selbst wenn du nicht initiiert hast
die Klage. Dieser Anwalt scheint zu glauben, dass Preact nicht mithalten kann
Es ist urheberrechtlich vor Gericht und wird als Verstoß gegen die Reaktion angesehen.

Sag mir, wenn ich falsch liege. Ich weiß nicht viel über Recht, wollte aber hilfreich sein.

- -
Sie erhalten dies, weil Sie kommentiert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/WordPress/gutenberg/issues/2733#issuecomment-331045326 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AH2_iHc8Rg54IDHqe8GIyVTdSbcJbZ9Iks5skeBngaJpZM4PYie9
.

Ich habe mir geschworen, WP nie wieder zu berühren, nachdem ich den schrecklichen Code gesehen habe, aber wenn Sie VueJS verwenden, könnte ich es mit ein wenig Valium überdenken.

Haftungsausschluss: Ich bin kein Anwalt. Das Folgende ist streng meine Meinung.

@ Codingfriend1 dieser Artikel hat wenig praktischen

Es werden drei Annahmen getroffen:

1. Facebook hat Patente, die breit genug sind, um das Predigen abzudecken.
2. Wenn ein Unternehmen, das preact verwendet, z. B. ABC, FB wegen Patentverletzung verklagt, verwendet FB Reaktionspatente, um ABC zu verklagen.
3. Das Patent von Facebook hat seine Berechtigung.

Schauen wir uns alle Annahmen genauer an:

1. Facebook hat Patente, die breit genug sind, um das Predigen abzudecken.

Es gibt keinen Beweis dafür bis heute. Beachten Sie, dass alle Patente öffentlich sind. Preact-Quellcode ist allgemein bekannt.
Darüber hinaus hat Jason Miller (Preact-Autor) behauptet, dass "keiner von Preact patentierbar ist - es ist viel zu offensichtlich."

Daher würde ich sagen, dass diese Annahme wahrscheinlich nicht wahr ist. Es ist möglich, aber unwahrscheinlich.

1. Wenn ein Unternehmen, das preact verwendet, z. B. ABC, FB wegen Patentverletzung verklagt, verwendet FB Reaktionspatente, um ABC zu verklagen.

Dies wird den Ruf von Facebook zerstören. Ich erwarte zwar, dass FB gegen Zähne und Nägel kämpft, aber wenn man das Patent von React auf diese Weise verwendet, wird FB als "Patenttroll" bezeichnet.

In der Zwischenzeit verfügt FB über genügend Ressourcen, um mit legalen Mitteln zu kämpfen. Daher halte ich diese Annahme ebenfalls für unwahrscheinlich.

1. Das Patent von Facebook hat seine Berechtigung.

Ja, das ist eine Annahme, keine Tatsache.

"Ein Patent haben" und "ein gültiges Patent haben" sind zwei verschiedene Dinge.
Ich habe diesen fantastischen Artikel gelesen, in dem das Gericht Patente für ungültig erklärt hat.

Es besteht immer die Möglichkeit, dass das Patent von FB zu weit gefasst ist, um einen Wert zu haben.
Jetzt würde man denken, wenn Facebook ein Patent hat, wird es einige Verdienste haben. Logischerweise ist es jedoch zu weit gefasst und daher unbegründet, wenn es das Predigt abdeckt. Diese Annahme steht also in direktem Widerspruch zu Annahme 1.

In Anbetracht der Tatsache, dass Facebook Patente verwendet, um sich zu verteidigen, ist es wahrscheinlicher, dass Facebooks Patente breit und unbegründet sind, anstatt durchsetzbar zu sein.

Fazit:

Beachten Sie, dass alle drei Annahmen nicht getestet wurden. Wenn sich herausstellt, dass sie alle wahr sind - und dies ist technisch möglich -, dann: "Ja, die Verwendung von Preact ist gefährlich."

In der Praxis ist die Wahrscheinlichkeit, dass alle drei Annahmen zutreffen, jedoch zu gering, insbesondere die Annahme 1 und 3 zusammen.

Bis und sofern das Gericht nichts anderes entscheidet, würde ich sagen, dass die Verwendung von preact (und anderen vdom-Bibliotheken) ziemlich sicher ist.

In Bezug auf Punkt 1 hat Facebook ein Patent namens Efficient Event Delegation in Browserskripten . Das ist im Grunde die live() -Funktion von jQuery (später Teil von on() in der jQuery-API)!

Unabhängig von der Gültigkeit der Annahmen ist der Grund, warum WordPress sich von React entfernt, nicht, dass WordPress Bedenken hinsichtlich Facebook hat. Und ich zitiere aus dem Ankündigungsbeitrag, der in der obigen Ausgabe verlinkt ist ( markieren Sie meinen):

Ich denke, die Klausel von Facebook ist tatsächlich klarer als viele andere Ansätze, die Unternehmen verfolgen könnten, und Facebook war einer der besseren Open-Source-Mitwirkenden da draußen. Aber wir haben eine Menge Probleme zu lösen, und die Welt davon zu überzeugen, dass die Patentklausel von Facebook in Ordnung ist, ist nicht unsere Aufgabe.

Auf dieser Grundlage haben die Wahrnehmung, die Verwirrung und die Fragen, die das Patent mit sich bringt, WordPress vertrieben. Ich denke, die gleichen Bedenken gelten auch für Preact, wie in meinem früheren Kommentar erläutert .

In Bezug auf Punkt 1 hat Facebook ein Patent namens Efficient Event Delegation in Browserskripten. Das ist im Grunde die live () - Funktion von jQuery (später Teil von on () in der jQuery-API)!

Bedeutet das, dass sie die Idee der Eventdelegation überhaupt erfunden haben?! Ich sehe dort einige Zitate, die aus dem Jahr 1995 stammen. Was bedeutet das?

@ChrisCinelli in Bezug auf das, was Sie als "Wendepunkt eines exponentiellen Wachstums" im Fall von Marko bezeichnet haben.

Ich glaube, das ist einfach eine Frage der Größenordnung. Wenn ein Projekt 5.000 oder sogar 10.000 Github-Sterne hat, kann ein einzelnes Ereignis wie beispielsweise ein Link auf der obersten Seite von Hackernews 1.000 Sterne pro Tag bringen, was im Fall von Marko 20% der aktuellen Anzahl entspricht.

Auf der Skala von 65.000 Sternen, die Vue hat, ist es nicht so sichtbar. Sie können sogar sehen, dass aufgrund der Funktionsweise des Star-History-Skripts irgendwann die Schwankungen überhaupt nicht mehr angezeigt werden und es bis zum Ende nur eine gerade Linie ist.

Eine solche Situation gibt es nicht nur bei Marko selbst, sondern auch bei Inferno oder in letzter Zeit bei MoonJS, einem von Vue inspirierten Mikroframework. Man könnte sogar sagen, dass Preact an einem ähnlichen Punkt zu sein scheint, weil es in letzter Zeit aufgrund des gesamten Dramas der React-Patente so viele Sterne bekommen hat.

Sie können beobachten, wovon ich in der folgenden Grafik aus derselben Quelle wie Ihrer spreche:

Die Zeit wird zeigen, ob diese Leute das Framework tatsächlich in der Entwicklung ausprobieren, es in der Produktion verwenden und es später weiter verwenden werden. Ich wünsche Marko alles Gute wie jeder anderen Open Source Bibliothek.

Was Vue betrifft, so ist es ein stabiles Wachstum ohne große Schwankungen. Mit der aktuellen Geschwindigkeit sollte es vor Weihnachten reagieren. Zumindest auf Github. :) :)

Was ist mit @aurelia?
Website: aurelia.io
@EisenbergEffect hat dies erstellt.

Für mich ist es ein großartiger Rahmen!

1. Einfache Konventionen (können angepasst werden)
2. Einfaches HTML
3. Vanilla JS
4. Keine Rahmenintervention!

Sie können sogar die Bibliothek Ihrer Wahl (jQuery, Vue.js, Preact, Ember, HyperHTML usw.), die Sie verwenden möchten, einbinden und Aurelia beibringen, wie man sie verwendet!

Es ist so einfach und standardbasiert, dass Sie nicht einmal Community-Unterstützung benötigen. Wenn Sie wirklich der Meinung sind, dass Community-Unterstützung wichtig ist, sind Sie auch hier (mit mehr als 10.000 Sternen).

Ressourcen für @aurelia :

1. Wir stellen Aurelia vor
2. Aurelia Blog
3. Aurelia Docs

Es sieht so aus, als würde React unter MIT erneut lizenziert: https://code.facebook.com/posts/300798627056246

Die Entscheidung sollte jetzt rückgängig gemacht werden, nehme ich an.

Holly Molly! React ist wieder im Geschäft. WordPress hat das getan? Nicht sicher! Es ist 3 Uhr morgens und ich freue mich riesig darüber! Was ist mit dir!

Relicensing React, Jest, Flow und Immutable.js

Nächste Woche werden wir unsere Open-Source-Projekte React, Jest, Flow und Immutable.js unter der MIT-Lizenz neu lizenzieren. Wir lizenzieren diese Projekte erneut, da React die Grundlage für ein breites Ökosystem von Open Source-Software für das Web ist und wir den Fortschritt aus nichttechnischen Gründen nicht zurückhalten möchten.

Diese Entscheidung fällt nach mehreren Wochen der Enttäuschung und Unsicherheit für unsere Gemeinde. Obwohl wir immer noch der Meinung sind, dass unsere BSD + Patents-Lizenz den Nutzern unserer Projekte einige Vorteile bietet, erkennen wir an, dass wir diese Community nicht entscheidend überzeugen konnten.

Aufgrund der Unsicherheit über unsere Lizenz wissen wir, dass viele Teams den Prozess der Auswahl einer alternativen Bibliothek zu React durchlaufen haben. Wir entschuldigen uns für die Abwanderung. Wir erwarten nicht, dass wir diese Teams durch diese Änderung zurückgewinnen, aber wir wollen die Tür offen lassen. Die freundliche Zusammenarbeit und der Wettbewerb in diesem Bereich treiben uns alle voran, und wir möchten uneingeschränkt teilnehmen.

Diese Verschiebung wirft natürlich Fragen zu den übrigen Open-Source-Projekten von Facebook auf. Viele unserer beliebten Projekte behalten vorerst die BSD + Patents-Lizenz. Wir evaluieren auch die Lizenzen dieser Projekte, aber jedes Projekt ist anders und alternative Lizenzoptionen hängen von einer Vielzahl von Faktoren ab.

Wir werden die Lizenzupdates nächste Woche in die Veröffentlichung von React 16 aufnehmen. Wir arbeiten seit über einem Jahr an React 16 und haben die Interna komplett neu geschrieben, um leistungsstarke Funktionen freizuschalten, von denen jeder profitieren kann, wenn er Benutzeroberflächen in großem Maßstab erstellt. Wir werden bald mehr darüber berichten, wie wir React umgeschrieben haben, und wir hoffen, dass unsere Arbeit Entwickler überall inspirieren wird, ob sie React verwenden oder nicht. Wir freuen uns darauf, diese Lizenzdiskussion hinter uns zu lassen und zu dem zurückzukehren, was uns am wichtigsten ist: den Versand großartiger Produkte.

Meiner Meinung nach ist React mit der MIT-Lizenz und der aktivsten und größten Open-Source-JS-Community die endgültige Wahl.

Meine Stimme ist jetzt mit React zurück . - Glauben an die Menschheit wieder hergestellt.

Stimmen Sie mit 👍 statt mit ähnlichen Kommentaren ab.

Ich möchte Wordpress mein RIESIGES DANKESCHÖN für die Teilnahme an der Änderung von React lincencing aussprechen.

Ich denke immer noch, dass Vue die bessere Lösung wäre. Viele der Stärken von Vue gelten immer noch, aber ich möchte darauf hinweisen, dass Anfängerfreundlichkeit und das Verzichten auf einen Build-Schritt meiner Meinung nach Killer-Features in der WordPress-Umgebung sind.

für die Masse
sicher
für vueJS

Ich habe mich auch für Angular2.0 + (nicht AngularJS) entschieden, das die größte Community, ein starkes Entwicklerteam und ein stabiles und vollständiges Ökosystem hat.

@CrazyBBer Wo finde ich einige Daten zur größten Community, Angular 2/4? Es würde mir bei einem Blogbeitrag helfen.

Wie auch immer, Leute, es ist vorbei, React ist hier, um bei WordPress zu bleiben, und selbst als Vue-Enthusiast finde ich, dass sich die Situation angesichts der Menge an Code, die bereits mit React geschrieben wurde, am besten ändern könnte.

@ahmadawais @gustojs Reddit-Mitarbeiter haben Bedenken geäußert, dass das MIT nur das Urheberrecht abdeckt, sodass Entwickler bei der Verwendung von React KEINE Patenterteilung erhalten, von der ich annehmen würde, dass sie immer noch ein Problem darstellt.

Auch diese Aussage nervt mich wirklich:

Wir erkennen an, dass wir diese Gemeinschaft nicht entscheidend überzeugen konnten.

Effektiv sagen "Wir haben uns nicht geirrt - Sie Entwickler haben uns einfach nicht verstanden".

@ahmadawais : Ich denke immer noch, dass es eine bessere Wahl wäre, mit Vue zu arbeiten, da Sie ein perfektes Beispiel dafür gesehen haben, wie unbeständig die React-Lizenzierung sein kann. Zuerst hatten sie jetzt BSD + Patents license und wechselten zum MIT. Wer weiß, dass sie in naher Zukunft möglicherweise wieder zu einer Lizenz / einem Patent von FB wechseln und dann alle zum Trocknen aufgehängt werden. Vue war von Anfang an MIT und ist mehr Community-orientiert als ein großes Unternehmen.

Plus was @ atanas-angelov-dev gesagt hat.

Dann macht es keinen Sinn, jetzt zu wechseln.
Ich denke, Vue bietet eine bessere Perspektive, aber es würde bedeuten, alles neu zu schreiben

Ahh! Komm schon Leute, gib Aurelia einfach eine Chance, oder?
Es wurde von einem der führenden Entwickler des Angularjs-Teams erstellt.
Sie können wie bei Vue.js von einer kleinen Einführung zu einem vollständigen Framework wechseln

Sogar das @ azure- Portal-Team sagte, wenn sie jetzt angefangen hätten, hätten sie Aurelia dem Knockout
Und wer weiß?! sie könnten jetzt nach und nach nach Aurelia migrieren.

Fangen Sie klein an, ich weiß, es wird Ihnen gefallen!

Nirmal4G,
Ihre These klingt so umsatzstark, dass es lächerlich ist.
Tatsächlich glaube ich, dass das gesamte Framework die gleichen Mängel aufweist wie diese 404-Seite, auf die Sie in Ihrem Beitrag direkt verweisen.
http://aurelia.io/get-started.html

@ bovas85 Nicht im Verkauf, ich bin nicht einmal Teil dieses Teams. Sie wissen nicht einmal, dass ich ihr Framework verwende.

@ cr101 / cc

Beurteilen Sie das Buch nicht nach seinem Einband

Ich habe viele beliebte Frameworks verwendet, bevor ich überhaupt von Aurelia wusste. Wenn ich sie stapeln musste, indem ich alle Kriterien für meine Bewerbung abwägte (glauben Sie mir, es ist eine große Bewerbung), dann führt Aurelia die Liste an, gefolgt von Vue.

Ich glaube, das gesamte Framework weist dieselben Mängel auf wie diese 404-Seite, auf die Sie in Ihrem Beitrag direkt verweisen.

Jeder Link, den ich gepostet habe, führt nie zu einer 404-Seite. Es ist Githubs Schuld, eine http-zu-https-Site umzuleiten. Es ist jetzt behoben. Sehen Sie, ein Fehler. Sagen Sie mir jedes Framework, das keine Fehler aufweist, ich wage Sie.

Es ist nur so, dass Sie mit anderen Frameworks viele redundante (und dennoch nützliche) Abstraktionen haben. Die W3C-Community nimmt niemals ein öffentliches Framework-Design in ihre API auf, also haben Sie es, viele Abstraktionen.

Jedes Framework ist so auf Abwärtskompatibilität ausgerichtet, dass es die Vorwärtskompatibilität verliert, aber Aurelia tut dies nicht, solange Sie sich an die W3C- und ECMAScript-Spezifikationen von HTML halten. JS Ihr Code funktioniert einwandfrei.

_Wenn es keine Aurelia gibt, würde es mir nichts ausmachen, bei Vue zu bleiben. Es ist das nächstbeste.

Es geht nur darum, einen Standard zu akzeptieren, als einen neuen Weg zu finden, ihn neu zu erfinden.

@ Nirmal4G Bitte Vergleich zu vue in Layout und die Logik zusammensetzt . So sehr ich nicht einmal an LOC als für irgendetwas relevante Metrik glaube, scheint mir das Lesen von unbewiesener FUD nicht fair zu sein.

@WebReflection Halt deine Pferde, ich habe nicht gesagt, dass du schlimmer bist als Vue. Entschuldigung, wenn ich dich beleidigt habe.

Meine Anwendung verwendet alles, was Sie darauf werfen können. Ich habe einen Prototyp mit vielen Frameworks ausprobiert. Eines der Kriterien, die ich hatte, war das LOC, aber aus visueller Sicht. Nicht aus dem Grund, den Sie denken, kann die Leistung eines Frameworks verbessert werden, sondern es sind die Designentscheidungen, die mit dem Namen verbunden sind.

Ich habe HyperHTML bewertet. Die Leistung war beeindruckend, keine Polyfills sind großartig, aber leider hat es für meine Anforderungen den Schnitt nicht geschafft.

Jedes Framework hat eine bessere Sache. Mein Wunsch ist es, dass, wenn jemand das beste aller Frameworks mit besserem Design zusammenfügen kann, das göttlich wäre, aber das wird nicht passieren. Ich muss also das Gleichgewicht finden, in dem sich ein Framework in Zukunft verbessern kann und wo es nicht wird.

Es ist wirklich gut zu hören, dass React jetzt MIT sein wird.
Ich freue mich sehr über dieses Projekt und freue mich darauf, WordPress nach langer Zeit wieder zu verwenden, sobald React und WP API vollständig unterstützt werden. :) :)

Lassen Sie uns abwarten, wie die tatsächliche React-Lizenz aussehen wird. MIT oder MIT + Patente ..? ;)

Persönlich mag ich React, finde aber Vue produktiver. Ich würde mit beiden glücklich sein, aber ...

... Angesichts der starken Unterstützung von Vue durch die Community würde ich vorschlagen, dies zusätzlich zur Lizenzierung zu berücksichtigen.

Vue scheint einfach eine geeignetere Wahl für WordPress zu sein.

Facebook hat 4 Elemente aus seiner Reihe von Prozessfallen entfernt. Diese sind jetzt alle MIT-lizenziert:

• Reagieren
• Scherz
• Fließen
• Immutable.js

Die Facebook-Lizenz der Kategorie X gilt weiterhin für:

• Native reagieren
• GraphQL
• Garn
• Relais
• Atom IDE
• und wahrscheinlich alles andere, was von ihnen gemacht und aus "offenen" Quellen bezogen wurde

Ich sage immer noch, geh mit Vue. Es lohnt sich auf lange Sicht. Reagieren ergab für mich ohnehin keinen Sinn für Wordpress. Es ist so stark in die PHP-Community eingebettet, dass Vue immer als die sinnlichste Wahl erschien (und es ist nicht schmerzhaft, wie React zu verwenden).

Die Facebook-Lizenz der Kategorie X gilt weiterhin für:

Native reagieren
GraphQL
Garn
Relais
Atom IDE
und wahrscheinlich alles andere, was von ihnen gemacht und aus "offenen" Quellen bezogen wurde

@TheJaredWilcurt Entschuldigung, aber Sie möchten vielleicht Garn aus dieser Liste entfernen. Garn hat keine solche "Facebook Category X" -Lizenz -> https://github.com/yarnpkg/yarn

@ atanas-angelov-dev

Die Leute auf Reddit haben Bedenken geäußert, dass das MIT nur das Urheberrecht abdeckt, sodass Entwickler bei der Verwendung von React KEINE Patenterteilung erhalten, von der ich annehmen würde, dass sie immer noch ein Problem darstellt.

MIT ist eine großartige Lizenz. jQuery ist ebenfalls MIT-lizenziert. Ich hoffe, du weißt das.

@vinayakkulkarni Ich denke immer noch, dass es eine bessere Wahl wäre, mit Vue zu arbeiten, da Sie ein perfektes Beispiel dafür gesehen haben, wie unbeständig die React-Lizenzierung sein kann. Zuerst hatten sie jetzt eine BSD + Patents-Lizenz und wechselten zum MIT. Wer weiß, dass sie in naher Zukunft möglicherweise wieder zu einer Lizenz / einem Patent von FB wechseln und dann alle zum Trocknen aufgehängt werden. Vue war von Anfang an MIT und ist mehr Community-orientiert als ein großes Unternehmen.

So geht es nicht. Ich habe Samuels Kommentar auf Facebook zu einer ähnlichen Frage gelesen. Sobald Sie es MIT lizenziert haben, können Sie es entweder aufteilen, um die Lizenz zu ändern, oder Sie können es einfach nicht. Ich bin allerdings kein Anwalt.

Ich persönlich denke auch, dass Facebook dies als Geste von Treu und Glauben getan hat und nicht, um Menschen auszutricksen. Das bedeutet mir etwas.

Ich persönlich denke auch, dass Facebook dies als Geste von Treu und Glauben getan hat und nicht, um Menschen auszutricksen. Das bedeutet mir etwas.

Das ist keine sehr logische Aussage. Sie belohnen eine Gruppe, weil sie aufgehört haben, etwas Negatives zu tun, anstatt die Gruppe zu belohnen, die das Negative überhaupt nicht getan hat. Wie oben erwähnt, verwenden sie auch weiterhin Lizenzen der Kategorie X in anderen ähnlichen Projekten, was für mich kein Zeichen von Treu und Glauben ist.

Vue hat eine VIEL sanftere Lern- und Adoptionskurve.
Und das war von Anfang an die Hauptidee von WordPress.

@ahmadawais Ich weiß - MIT ist so gut wie Lizenzen, aber und dies ist ein großes "aber", Facebook hat anscheinend Patente auf React und während MIT Ihnen erlaubt, den Code für jeden Zweck zu verwenden, können Sie dennoch gegen Facebook verstoßen Patente (nehmen Sie all dies mit einem Felsbrocken Salz - IANAL)

Und um beim Thema zu bleiben, muss ich sagen, dass ich viel von dem sehe, was WordPress auch in Vue großartig gemacht hat - meiner bescheidenen Meinung nach ist keine andere geeignete Bibliothek so einfach zu erlernen und zu verwenden wie Vue.

Facebook hat offenbar Patente auf React

Welcher Teil von React ist Ihrer Meinung nach patentiert? (nichts in React ist patentiert, versuchen Sie zuerst eine Recherche) zeigen Sie Links, nicht nur "anscheinend" .., diese Art von Kommentaren hilft überhaupt nicht. Wenn Sie Ihre Lieblingsbibliothek empfehlen möchten, machen Sie es richtig, zeigen Sie ihre Vorzüge und verbreiten Sie nicht nur FUD.

Warum der ursprüngliche Wechsel zu BSD + Patenten, wenn keiner von React Patente hinter sich hat? Facebook hat nicht gesagt, was sie sind oder was sie nicht sind.

Warum 2 Jahre lang mit der Lizenzierung herumspielen und nur einen Teil ihres Portfolios ändern, nachdem sie konsequent gesagt haben, dass sie es nicht ändern würden, und gesagt haben: "Beschäftige dich einfach damit, es ist uns egal, ob du es verwendest oder nicht."

Warum sollten Sie React Native, GraphQL usw. usw. von der "neuen" Lizenzierung ausschließen? Zu was wird eine zukünftige Version von React wechseln? Es gibt keine Garantie, wenn Sie eine zweistufige Lizenzierung von Facebook haben, je nachdem, wer sich darüber beschwert ...

Was passiert, wenn ein Teil des React Native-Codes in React gerollt wird? Wo stehen Sie, wenn sich eine GraphQL-Implementierung in eine Codebasis einfügt?

Diese Aktion von Facebook wirft mehr Fragen auf als sie beantwortet und bedeutet dennoch, dass jede einzelne Verwendung von React ein potenzielles Risiko für echte Open Source-Projekte darstellt.

Nehmen Sie einfach die Bibliothek ohne Gepäck an, das bereits in der PHP-Welt etabliert ist - Vue.

@bjrmatos https://www.google.com/patents/US20170221242 Ich denke!

Noch eine +1 für Vue. Facebook verwendet während seiner Projekte immer noch zwei Lizenzen. Das ist nicht gut.

@PericlesSouza Sie ignorieren einfach die großen Anstrengungen, die ein Unternehmen wie Facebook unternimmt, um Dinge zu verbessern und das Web voranzubringen. Alle Ihre Fragen können beantwortet werden, wenn Sie nur den Beitrag über die Änderung am MIT lesen. Ich weiß nicht wirklich, warum Sie diese irrationale Besorgnis über die MIT-Lizenz immer noch äußern. Mit der Änderung befindet sich React in derselben Position wie jedes andere "True Open Source" -Projekt (ich weiß nicht, was Sie als True Open Source-Projekt bezeichnen übrigens).

@ Raymonf Nun , im Grunde genommen verletzt jedes moderne Framework dieses Patent bereits (einschließlich Vue), sodass sich jeder in derselben Position befindet, unabhängig davon, ob Sie React, Vue oder ein anderes Framework verwenden, das das im Link beschriebene Konzept implementiert (übrigens jedes Web) Wenn das Projekt bereits zwei oder drei Patente anderer Unternehmen verletzt, werden Sie überrascht sein, welche Art von Dingen derzeit von Unternehmen patentiert werden. Wenn Sie sich darüber wirklich Sorgen machen, bedeutet dies, dass Sie kein Framework verwenden können, das die Benutzeroberfläche auf diese Weise aktualisiert. In diesem rechtlichen Kontext gibt es also keine bessere oder schlechtere Alternative.

Ich möchte mich nicht wieder auf diese Art von Gesprächen einlassen, da es unmöglich sein wird, eine Einigung zu erzielen, sodass ich meine Kommentare beenden werde. Die React-Community ist mit dem Wechsel zum MIT zufrieden (selbst die größeren Kritiker der ursprünglichen Lizenz).

Viel Glück für das WordPress-Team bei der Entscheidung, das Hauptproblem bezüglich der React BSD + Patents-Lizenz ist gelöst, es ist nun ihre Aufgabe, zu entscheiden.

Daher hat Facebook kürzlich seine Lizenz für React geändert. Bedeutet das, dass WordPress weiterhin React verwendet oder das Standard-Front-End-Framework weiterhin ändert?

@bjrmatos das ist überhaupt nicht wahr

Grundsätzlich verletzt jedes moderne Framework dieses Patent bereits

Beispielsweise verwendet hyperHTML kein virtuelles DOM, sondern verwendet direkt die DOM-API (nicht patentierbar) durch regelmäßige Rückrufaufrufe (nicht patentierbar) und den einzigen unterschiedlichen Algorithmus zum Verwandeln von c hildNodes: before in c hildNodes: after in Listen von Knoten basiert auf der Levenshtein-Entfernung (nicht patentierbar) und der geringsten Anzahl von Spleißoperationen (nicht patentierbar, das habe ich geschrieben und es ist ISC ).

Und obwohl ich an diesem Punkt denke, dass dieser Thread veraltet und sinnlos ist, verstehe ich nicht die Notwendigkeit, FUD weiter zu verbreiten. Wenn Sie eine Wahl getroffen haben und sie Ihnen gefällt, gibt es keinen Grund, allen anderen zu sagen, dass sie etwas falsch machen oder in den gleichen Schwierigkeiten sind wie Sie. Ich wünschte, wir könnten uns darauf einigen.

@noncototient das ist eine Millionen-Dollar-Frage, nicht

Ich habe mich hier gerade abgemeldet, da die Diskussion etwas sinnlos wird.
Ich denke, viele gute Punkte wurden weiterentwickelt und es war eine Lernerfahrung für alle, die diese Ausgabe sorgfältig gelesen haben.

Ich stimme zu, das ist jetzt sinnlos. Ich schlage vor, diesen Thread zu sperren (oder vielleicht nur Mitwirkende). Es gab genügend Rückmeldungen zu diesem Thema, und jetzt erreicht es den Punkt, an dem es nur zu nicht konstruktiven Argumenten führen wird.

Wird diese Ausgabe geschlossen?
@WordPress scheint nicht daran interessiert zu sein, jetzt auf ein neues JavaScript-Framework zu migrieren. 🤔

Für mich persönlich mag ich @vuejs. Aber jetzt scheint es egal zu sein. 😅

Persönlich würde ich Vue trotzdem sehr bevorzugen.

Für mich und viele andere Menschen ging es nie um die Lizenzierung. Dies war nur eine Ausrede, um sich von React zu entfernen.

Marko ist wahnsinnig mächtig und einfach. Wir führen derzeit eine vollständige Neufassung eines dynamischen Webshops mit 50.000 Produkten durch, dessen Funktionen sehr umfangreich sind. Gehen Sie diesen Weg und schauen Sie nicht zurück.

Marko ist gut, aber Prarko ist 100 Byte kleiner (GZipped) und bei einem selbstoptimierten Test 0,01% schneller. Deshalb müssen wir das stattdessen verwenden, auch wenn es sonst niemand tut. Obwohl morgen Plarko mit zusätzlichem Fibre veröffentlicht wird, was alles überflüssig macht.

Sorry, aber so geht der Rest dieses Threads.

Lassen Sie uns abwarten, wie die tatsächliche Lizenzierung aussieht, welche Auswirkungen die zweistufige Lizenzierung von Facebook hat und welche Entscheidung das WordPress-Team trifft, nachdem es das Problem gründlich untersucht hat.

Ich meine, ursprünglich wurde nach Eingaben für Motoren gefragt, die die Community mag. Und das scheint das zu sein, was die Leute posten, aber einige Leute springen einfach über die Leute hinweg, um Kommentare einzusenden, die mit dem übereinstimmen, was gefragt wurde. Ein bisschen seltsam.

Alle hier genannten Bibliotheken / Frameworks sind ausgezeichnet; Einige sind für einige Szenarien besser geeignet als andere. Jeder wird seine Befürworter haben, jeder wird die anderen in Bezug auf Leistung / Merkmale überspringen, abhängig von ihren Entwicklungszyklen.

Beginnen Sie vielleicht mit einer einfachen Frage, wie ich es bei den meisten Projekten tue:

1. Brauchen wir einen SPA Rahmen?

Wenn die Antwort ja lautet, geben Sie an, warum. Das gibt Ihnen eine Reihe von Kriterien, anhand derer Sie die potenziellen Kandidaten bewerten können. vielleicht für serverseitiges Rendern, vielleicht Routing usw.

Wenn nicht, stellen Sie die nächste Frage:

1. Brauchen wir wirklich eine Template-Engine?

VanillaJS hat die größte Community der Welt und keine Lizenzprobleme. Es ist auch standardkonform;) und bietet mit ES6-Modulen möglicherweise eine geeignete Grundlage für die Kernentwicklung, mit der Möglichkeit, die Plugin-Unterstützung für die Verwendung von Template-Engines wie React, Vue, Preact, Aurelia usw. usw. zu verwenden, unabhängig davon, in was veröffentlicht wird die kommenden Jahre, wie von den Entwicklern gefordert.

Matt Mullenweg hat seine Antwort gepostet ...

Ich bin überrascht und aufgeregt, die Nachricht zu sehen, dass Facebook die Patentklausel, über die ich letzte Woche geschrieben habe, fallen lassen wird. Sie haben angekündigt, dass mit React 16 die Lizenz nur reguläres MIT ohne Patentzusatz sein wird. Ich begrüße Facebook für diesen Schritt und hoffe, dass die Verwendung von Patentklauseln in allen Open-Source-Projekten überprüft wird.

Unsere Entscheidung, sich von React zu entfernen, hat aufgrund ihrer früheren Haltung viele interessante Diskussionen in der WordPress-Welt ausgelöst. Insbesondere bei Gutenberg gibt es möglicherweise einen Ansatz, mit dem Entwickler Gutenberg-Blöcke (Gutenblocks) in die Bibliothek ihrer Wahl schreiben können, einschließlich Preact, Polymer oder Vue, und jetzt könnte React auch eine offiziell unterstützte Option sein.

Ich möchte mich bei allen bedanken, die bisher an der Diskussion teilgenommen haben. Ich weiß das sehr zu schätzen. Die lebhafte Debatte und Diskussion in den Kommentaren hier und in Hacker News und Reddit war großartig für die Leidenschaft, die die Menschen mitbrachten, und die Gelegenheit, so viele verschiedene Sichtweisen kennenzulernen. Es war sogar noch besser, dass Facebook zuhörte.

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

@ahmadawais @m

Unsere Entscheidung, sich von React zu entfernen, hat aufgrund ihrer früheren Haltung viele interessante Diskussionen in der WordPress-Welt ausgelöst. Insbesondere bei Gutenberg gibt es möglicherweise einen Ansatz, mit dem Entwickler Gutenberg-Blöcke (Gutenblocks) in die Bibliothek ihrer Wahl schreiben können, einschließlich Preact, Polymer oder Vue, und jetzt könnte React auch eine offiziell unterstützte Option sein.

Diese Situation scheint für alle ein Gewinn zu sein. Lassen Sie uns abwarten, wie sich das tatsächlich auswirkt.

Schließen Sie dieses Problem jetzt. Es zeigt nur, wie launisch die Welt ist. Es ist traurig zu sehen, dass Menschen nicht bei ihrem Wort bleiben.

[Bearbeiten: wegen anstößiger Aussage entfernt]

Viel Glück für alle, die Gutenberg und die schwere Lernkurve des Lernens nutzen müssen. Reagieren Sie damit.

Frieden.

👋 Ich denke, wir haben hier alle viele Diskussionen geführt. Ich möchte mich bei allen bedanken, die sich genug darum gekümmert haben, über dieses Thema zu sprechen und es zu kommentieren. IMHO sieht es so aus, als ob alle Optionen, die wir derzeit haben, gute Optionen sind.

Wenn wir eine bessere Framework-agnostische API erhalten, kann man jedes gewünschte JS-Framework in seinen Apps verwenden. Mit der MIT-Lizenz hat React eine ebenso starke Position im Kern wie jede andere Bibliothek mit einer guten (lesekompatiblen) Open Source-Lizenz.

🎯 Wenn Sie für ein bestimmtes JavaScript-Framework rooten oder eines (Kernteams) erstellt haben, empfehlen wir Ihnen, aktuelle Beispiele für die WordPress-Entwickler zu erstellen, damit die Leute mit der Idee spielen können, Ihr bevorzugtes JavaScript-Framework in den von ihnen verwendeten WordPress-basierten Apps zu verwenden bauen.

Ich schließe dieses Ticket für jetzt. Und in der Hoffnung, mehr zum Erfolg von WordPress als Plattform und als Community beizutragen. Ich erwarte dasselbe von allen hier. Ich bin fest davon überzeugt, dass dies ein Achterbahn-Abenteuer für jeden sein wird, der mit der WordPress-Software arbeitet.

In einiger Zeit werden wir möglicherweise die Software verbessern, um es den Benutzern (~ 30% der Internetseiten) zu erleichtern, wie es vor ein paar Jahren war. Ich habe hier Wurzeln für WordPress, wie Sie alle!

Prost!

Aus Matts Kommentar geht nicht wirklich hervor, ob die Entscheidung, sich von React zu entfernen, aufgehoben wurde.

Erstens wurde die tatsächliche Lizenz, die Facebook verwenden wird, noch nicht veröffentlicht . Es ist also nicht wirklich sinnvoll, so zu tun, als wäre alles vorbei.

Zweitens geht es nicht um die zweistufige Lizenzierung, die Facebook verfolgt: React ist möglicherweise MIT, React Native ist jedoch + (nicht bekannt gegeben) Patente .

Also ... was ist mit den Komponenten, die von beiden gemeinsam genutzt werden?

Was ist mit React Native Code, der in React verwendet wird? Wird Fibre zwischen zwei verschiedenen Lizenzen geteilt? Oder findet GraphQL-Code Eingang in React?

Was passiert mit WordPress, wenn es den Weg von React geht und all diese verwandten Facebook-Projekte unter einer anderen Lizenz veröffentlicht werden? Dann entscheidet Facebook, dass einige Aspekte von React tatsächlich einer React Native Patent Grant oder einer Fibre unterliegen Patenterteilung?

Im Ernst, denken Sie sehr, sehr sorgfältig darüber nach. Warum riskieren Sie es, wenn es Alternativen gibt, die die Mehrheit bevorzugt, die dieses Problem nicht haben - Vue.

Ich würde einer Lizenzvereinbarung nicht vertrauen, die sich mit dem Wind ändert, anstatt richtig durchdacht zu sein. Die Anwälte von Facebook könnten dies aus einer Laune heraus ändern.

Bleib bei echtem Open Source.

@PericlesSouza Die Lizenz wird genau das sein, was sich die Leute hier aus der Beschreibung des Blogposts vorstellen: eine Standard-MIT-Lizenz, nichts weiter. React hängt nicht von React Native ab. Die Teile, die von beiden geteilt werden, befinden sich im React-Projekt, nicht in React Native. React und seine FB-eigenen Abhängigkeiten werden unter MIT verfügbar sein, sobald unser Team die Zeit hat, die Änderungen zu übernehmen. Wir planen kein lustiges Geschäft.

@sophiebits

Sie arbeiten für Facebook. Wenn Sie kein Anwalt sind, der befugt ist, im Namen von Facebook zu sprechen, spielt es keine Rolle, was Sie behaupten. Es ist nicht einmal wichtig, welchen Code Sie schreiben. Es tut uns leid.

"Imagining" -Lizenzen stehen nicht vor Gericht.

Können Sie beispielsweise kategorisch angeben, warum Facebook die Patenterteilung angenommen hat, was die Patente waren (oder nicht waren) oder warum sie sagen, dass sie sie jetzt ändern, ohne "IANAL" (Ich bin kein Anwalt) zu sagen?

Die Teile, die von beiden geteilt werden, befinden sich im React-Projekt, nicht in React Native

Aber können Sie das mit einer gesetzlichen Garantie sagen? Nein?

React und seine FB-eigenen Abhängigkeiten werden unter MIT verfügbar sein, sobald unser Team die Zeit hat, die Änderungen zu übernehmen

Welche Teile werden entfernt, damit React unter MIT veröffentlicht werden kann? Welche nicht FB-eigenen Abhängigkeiten, die vermutlich nicht MIT-konform waren, haben Sie bereits verwendet? Werden die Anwälte von Facebook garantieren, dass wirklich alles mit dem MIT übereinstimmt? Wie lange dauert es, bis Apache Software Foundation dies zertifiziert?
.

Es scheint, dass ich zu Recht hervorgehoben habe, dass Code zwischen zwei Projekten geteilt wird, die anscheinend eine zweistufige Lizenzierung haben werden.

Du verdrehst meine Worte. Code, der zwischen React und React Native geteilt wird, wird unter MIT lizenziert. Alles, was Sie als Glasfaser betrachten, wird unter MIT lizenziert. React wird keinen Code enthalten oder davon abhängen, der unter BSD + Patents oder einer anderen Patenterteilung lizenziert ist, die Sie so verachten. Wir entfernen keine Teile aus React. Die einzige mir bekannte FB-abhängige Abhängigkeit von React ist die Objektzuweisung, die ebenfalls unter MIT steht.

Ich schlage nicht vor, dass Sie meine Worte als rechtliche Garantie nehmen. Wir sind uns beide bewusst, dass meine Kommentare hier die Lizenz von React selbst nicht ändern. Sie können sich dafür entscheiden, skeptisch zu sein und müssen mir jetzt nicht glauben, aber in ein oder zwei Tagen werden Sie sehen, dass das, was ich hier sage, wahr ist.

@sophiebits

Ich verdrehe Ihre Worte nicht - und ich respektiere sowohl Ihre Arbeit als auch Ihre Bereitschaft, sich hier zu engagieren.

Ich sage nur, dass wir uns immer noch in der Position befinden, in der wir begonnen haben, es sei denn, wir erhalten rechtliche Verpflichtungen von Facebook durch autorisierte Mitarbeiter des Unternehmens, die von externen Open-Source-Stellen überprüft wurden. Niemand kann sicher sein, wie die tatsächliche rechtliche Situation ist ist, wie Sie zustimmen, indem Sie Folgendes angeben:

Ich schlage nicht vor, dass Sie meine Worte als rechtliche Garantie nehmen. Wir sind uns beide bewusst, dass meine Kommentare hier die Lizenz von React selbst nicht ändern.

Und:

Alles, was Sie als Glasfaser betrachten, wird unter MIT lizenziert.

Es spielt keine Rolle, was ich als Fibre betrachte, es hängt ganz davon ab, was die Facebook-Anwälte und angemeldeten Patente als Fibre definieren.

Warum soll React Native derzeit anders als React lizenziert werden, wenn es Code mit React teilt? Macht das die MIT-Lizenz nicht ungültig?

Ich stelle auch fest, dass Sie GraphQL nicht erwähnt haben. Sonst noch etwas, was ich vermisst habe?

Der springende Punkt beim Debakel um die React-Lizenzierung ist die mangelnde Rechtssicherheit.

@sophiebits

Ich nehme Ihre Bearbeitung als Antwort auf meine Punkte zur Kenntnis:

React wird keinen Code enthalten oder davon abhängen, der unter BSD + Patents oder einer anderen Patenterteilung lizenziert ist, die Sie so verachten. Wir entfernen keine Teile aus React. Die einzige mir bekannte FB-abhängige Abhängigkeit von React ist die Objektzuweisung, die ebenfalls unter MIT steht.

Aber Sie sagten, Sie würden Teile aus React entfernen und den Code "in den nächsten Tagen" einchecken.

React und seine FB-eigenen Abhängigkeiten werden unter MIT verfügbar sein, sobald unser Team die Zeit hat, die Änderungen zu übernehmen

Und du hast das IANAL vergessen ... :-)

Oh, eigentlich hast du es lange gesagt:

Ich schlage nicht vor, dass Sie meine Worte als rechtliche Garantie nehmen. Wir sind uns beide bewusst, dass meine Kommentare hier die Lizenz von React selbst nicht ändern.

Noch einmal:

Der springende Punkt beim Debakel um die React-Lizenzierung ist die mangelnde Rechtssicherheit.

Ich stimme dem Punkt zu, dass es noch keine Rechtssicherheit gibt. Aber ich persönlich glaube, dass dieser Thread seinen Lauf genommen hat; Markieren Sie es am besten nur als Mitwirkende und warten Sie, bis die eigentliche Lizenz veröffentlicht ist, und das Team kann ihre Bewertung vornehmen.

Jetzt abbestellen.

Bitte nicht entleeren Reagieren, Facebook hat seine Entscheidung getroffen https://thenextweb.com/dd/2017/09/25/facebook-re-licenses-react-mit-license-developer-backlash/

@vinayakkulkarni Obwohl ich verstehe, dass ich eine Leidenschaft für etwas habe, ist es kein Grund, einen Kommentar

@sophiebits nur eine kleine Notiz, um Danke zu sagen, dass Sie in diesen Thread gekommen sind, es wird geschätzt.

Dies mag ein Thema für einen neuen Thread sein, aber leider klärt die MIT-Lizenz (auch die Standardlizenz) das Problem der "Unsicherheit" bei Patenten nicht, was zu einer früheren Entscheidung von WordPress geführt hat.

Gibt Ihnen die MIT-Lizenz das Recht, patentiertes IP zu verwenden? Lesen Sie, was ein Anwalt dazu zu sagen hat: Die MIT-Lizenz, Zeile für Zeile

- Frans Bouma (@FransBouma), 23. September 2017

Das MIT gewährt Ihnen offenbar keine Patentlizenz. Facebook hat Patente in React, die es Ihnen in seiner aktuellen Lizenz gewährt. Mit der aktuellen Lizenz wissen Sie zumindest, dass Ihnen alle Lizenzen gewährt werden, und wissen, unter welchen Bedingungen sie widerrufen werden. Mit einem MIT erhalten Sie nicht einmal eine Lizenz.

Die Patenterteilung bedeutet jedoch, dass es sich um Patente handelt (oder was gewährt sie?). Außer niemand weiß, was die Patente sind. Facebook hat es nicht gesagt, nicht einmal, als es ihnen gewährt hat, und nicht, als es angekündigt hat, das Stipendium zu entfernen.

Unabhängig davon, was ich persönlich oder das WordPress-Team denken, dass dies bedeutet, scheint immer noch die Verwirrung über die rechtliche Situation der (noch nicht aufgeführten) Facebook-Patente auf React vorhanden zu sein, die jeder, der sie verwendet, [[kann - oder - möglicherweise müssen Sie sich keine Sorgen über Verstöße machen, wenn Sie Facebook heute verklagen oder einfach React nach der neuen Lizenz verwenden.

Auch hier kann das Problem die Unsicherheit sein oder auch nicht, und das, was ich vorschlage, ist nicht gelöst.

Zur Erinnerung, die Mehrheit, die ihre Meinung zu diesem Thread abgegeben hat, möchte eine Vue-basierte Lösung.

Hierfür gibt es mehrere Gründe, die nicht darauf beschränkt sind, dass Vue keine Verwirrung bei der Lizenzierung aufweist (was immer noch bei der zweistufigen Lizenzrichtlinie von Facebook bleibt):

1. Vue wurde von Grund auf so konzipiert, dass es schrittweise mit Funktionsinseln hinzugefügt werden kann, um eine schrittweise Verbesserung der Codebasis zu ermöglichen.

2. Zusätzlich und optional bietet es offiziell unterstützte Statusverwaltungs- und Routing-Lösungen.

3. Es unterstützt mehrere Prozessoren für HTML und bietet Entwicklern die Wahl zwischen Vorlagensprache - HTML, JSX, Pug usw. oder Renderfunktionen.

4. Einzeldateikomponenten und CSS mit Gültigkeitsbereich (Stylus, SASS, SCSS, PostCSS, CSS-Komponenten) - auf einfachste Weise. Fügen Sie einfach das Attribut scoped zu Ihren Komponenten hinzu. Style-Deklarationen, und fertig.

5. Unterstützung für integrierte berechnete Eigenschaften (mit Memoization) (dh ohne Abhängigkeiten wie MobX).

   6+. Überlegene Reaktionsleistung, viel geringere Lernkurve, höhere Akzeptanz in der PHP-Community. Schauen Sie sich zum Beispiel https://unpkg.com/vue hinzu und starten Sie die Codierung.

Vue ist einfach besser für WordPress geeignet.

Reaktion :

76.364 Github-Sterne
571 Offene Ausgaben (!)
4325 Geschlossene Ausgaben
178 Open Pull Requests (!)
5.644 Closed Pull Requests

Vue :

68, 246 Github-Sterne (Flugbahn soll React bis Weihnachten überholen)
62 Offene Probleme (viel reaktionsschneller auf Fehlerbehebung, Hinzufügen der gewünschten Funktionen)
5.629 Geschlossene Ausgaben
17 Open Pull-Anforderungen
863 Closed Pull-Anforderungen

@Meligy

Das MIT gewährt Ihnen offenbar keine Patentlizenz. Facebook hat Patente in React, die es Ihnen in seiner aktuellen Lizenz gewährt. Mit der aktuellen Lizenz wissen Sie zumindest, dass Ihnen alle Lizenzen gewährt werden, und wissen, unter welchen Bedingungen sie widerrufen werden. Mit einem MIT erhalten Sie nicht einmal eine Lizenz.

Die Patenterteilung bedeutet jedoch, dass es sich um Patente handelt (oder was gewährt sie?). Facebook hat es nicht gesagt, nicht einmal, als es ihnen gewährt hat, und nicht, als es angekündigt hat, das Stipendium zu entfernen.

Darin liegt das Problem mit nicht ganz Open Source von einem großen Unternehmen. Letztendlich werden ihre Anwälte die guten Absichten der Entwicklungsteams jetzt oder in Zukunft außer Kraft setzen.

Facebook hat ihre + Patents-Lizenz als aggressive Verteidigung von "etwas oder irgendetwas" eingestuft, und jetzt werden wir gebeten zu glauben, dass genau dasselbe "etwas oder irgendetwas" für React nicht existiert, aber immer noch für React Native und GraphQL usw.

Kann Automattic versprechen, dass sie sich selbst belasten und React tragen, gabeln, selbst entwickeln, wenn Facebook seine Lizenz und Meinung zu React erneut ändert?

Für mich sieht es so aus, als würde Facebook eine Falle für WordPress stellen. 25% aller Websites auf der Welt sind ein großer Fang.

Bitte markieren Sie diesen Thread so schnell wie möglich als _contributors only_. Es wäre großartig, jedes Contributor-Ergebnis zu lesen, anstatt nur FUD und Spekulationen, ohne sich vollständig abmelden zu müssen. Vielen Dank.

@WebReflection Die Stakeholder von Wordpress sind nicht nur die Hauptentwickler, sondern auch die erweiterte Community.

@PericlesSouza unter Berufung auf Github-Sterne ist nichts. Und dass dieses Problem von Leuten überstürzt wird, die lächerliche Behauptungen aufwerfen, bedeutet nicht, dass wir Fakten ignorieren sollten: https://npmcharts.com/compare/react , angle, @ angle / core , ember-cli, vue

Vue ist nicht viel mehr als ein Ausrutscher auf dem Radar. Die erstaunliche Mehrheit verwendet React und würde mit Sicherheit auch Ihren Aufzählungspunkten nicht zustimmen.

@PericlesSouza unter Berufung auf Github-Sterne ist nichts. Und dass dieses Problem von Leuten überstürzt wird, die lächerliche Behauptungen aufwerfen, bedeutet nicht, dass wir Fakten ignorieren sollten: https://npmcharts.com/compare/react , angle, @ angle / core , ember-cli, vue

Vue ist nicht viel mehr als ein Ausrutscher auf dem Radar. Die erstaunliche Mehrheit verwendet React und würde mit Sicherheit auch Ihren Aufzählungspunkten nicht zustimmen.

NPM-Statistiken? Sie meinen, dass die gleichen Statistiken, die sie zugeben, jede einzelne Anfrage zählen, um zu überprüfen, ob Sie die neueste Version oder über jede Abhängigkeit als Anfrage für einen Download verwenden oder nicht? (Sie gaben dies in ihrem Blog zu, als die Leute über ihre Behauptungen "Milliarden Pakete pro Monat" lachten).

Wenn Sie diesen Weg gehen möchten, verwenden alle jQuery.

Versuchen Sie vielleicht Zahlen für Pakete, die dieses Abhängigkeitsverzerrungsfeld nicht haben:

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

Ganz anderes Bild als das, das Sie präsentiert haben.

Oder wie wäre es mit der Nutzung der Website:

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

Was durch BuiltWith-Statistiken unterstützt wird:

Oh, und ich lasse dieses Bild einfach hier - von dem Zeitpunkt an, als das Team die Community selbst gefragt hat. Sie sollten ihnen zuhören, anstatt sie mit Verachtung zu behandeln.

@PericlesSouza Es macht keinen Sinn, vue-cli mit create-react-app zu vergleichen, da es andere sehr beliebte Build-Tools für React gibt, wie Next.js und GatsbyJS .
Viele React-Entwickler verwenden nicht einmal eine CLI und verwenden stattdessen ihre eigenen benutzerdefinierten Webpack-Build-Skripte, genau wie Gutenberg und Calypso.

Die Realität ist, dass das React-Ökosystem viel größer ist als das von Vue. Nehmen wir zum Beispiel die Material-Benutzeroberfläche für Vue.js mit 4.339 Sternen, während die Material-Benutzeroberfläche für React 29.078 Sterne hat.

Eine native Auswahlfeldkomponente, die ähnliche Funktionen wie Select2 ohne den Aufwand von jQuery bietet: Vue select hat 1.348 Sterne, während React select 8.493 Sterne hat.

@PericlesSouza , @drcmda , all diese Daten können auf viele Arten angefochten werden, sogar die npm-Statistiken mit den Clis. Wenn Sie AngularCLI und EmberCLI hinzufügen, werden Sie völlig unterschiedliche Daten sehen, was nichts bedeutet:

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

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

Quelle: https://insights.stackoverflow.com/survey/2017#technology -frameworks-Bibliotheken-und-andere-Technologien

In dieser Konversation sollte es jedoch nicht darum gehen, welches Framework am häufigsten verwendet wird, sondern welches für die Wordpress-Umgebung insgesamt besser ist.

@PericlesSouza @willgm Die Regeln gelten für beide. Beide werden genauso gezählt, ziemlich unaufrichtig zu behaupten, dass es nicht fair ist. Das Festhalten an optionalen CLIs oder suggestiven Websites, auf denen "Likes" und "Stars" gezählt werden, ist zwecklos. Sogar der Stackoverflow ist sehr subjektiv und ich habe bis heute noch nicht einmal von der "builtwith ..." - Site gehört, und die CLI-Statistiken spiegeln wider, wie viele eine CLI verwenden (die Mehrheit nicht).

Die Daten aus der offensichtlichsten und wichtigsten Quelle, die reale Produktionsumgebungen unter genau denselben Umständen widerspiegeln, sind die einzige Statistik, die Sie nicht mögen. Ich verstehe, dass sie nichts daran ändern, wie sie ist.

In dieser Konversation sollte es jedoch nicht darum gehen, welches Framework am häufigsten verwendet wird, sondern welches für die Wordpress-Umgebung insgesamt besser ist.

Und ich nehme an, Sie wissen, welches am besten geeignet ist. Sie denken, die 400.000 Menschen pro Tag, die React off npm bekommen, sind alle falsch. Vue könnte alleine konkurrieren, braucht nicht wirklich einen Mob, der in Issue-Tracker stürzt.

@PericlesSouza @willgm Die Regeln gelten für beide. Beide werden genauso gezählt, ziemlich unaufrichtig zu behaupten, dass es nicht fair ist. Das Festhalten an optionalen CLIs oder suggestiven Websites, auf denen "Likes" und "Stars" gezählt werden, ist zwecklos.

Nee. React hat 16.800 abhängige Pakete, die die Zahlen verzerren. NPM gibt zu, dass alles, was sie als Download zählen, ein 200-Ergebniscode ist, wenn eine URL aufgerufen wird, als Ergebnis einer Abhängigkeitsprüfung oder eines Bots oder eines Spiegels oder irgendetwas. Übrigens sagen sie auch, dass die meisten Downloads in China, wo Vue sehr beliebt ist, von Spiegeln stammen und nicht gezählt werden.

Gemessen an Ihrem Sprachgebrauch - "Festhalten", "suggestive Websites", "vergeblich" - haben Sie keine wirklichen Argumente zu diesem Thema, während ich, wie vom Team gefordert, die positiven Aspekte der Verwendung von Vue veröffentlicht habe (siehe oben ).

Sterne zählen - andere tun dies, wenn sie auf den Erfolg von React hinweisen, aber Sie entschlüsseln ihren Wert, wenn Sie die Popularität von Vue anzeigen? Sie erwähnen auch nicht die viel höhere Anzahl ausstehender Probleme ( 571 ) und die bemerkenswerte Anzahl ausstehender Pull-Anfragen ( 178 ), die noch für React anstehen, was im Vergleich zu der höheren Reaktionsfähigkeit der Vue-Community bei der Fehlerbehebung und Das Hinzufügen von Funktionen ist ein berechtigter Grund zur Besorgnis, wenn die Verwendung von React vorgeschlagen wird.

Was mich bringt zu:

Counting Likes - nun, das war der springende Punkt in diesem Thread, der vom Team gestartet und von der Community angefragt wurde - ich denke, das Ergebnis gefällt Ihnen einfach nicht. Hier ist es wieder und sehr schlüssig ist es:

Nee. React hat 16.800 abhängige Pakete, die die Zahlen verzerren.

@PericlesSouza Wie kommst du zu diesem Schluss

Es macht ungefähr keinen Sinn, ein Paket in einem Tracker herauszusuchen, der jedes Paket gleich behandelt. Auf der anderen Seite bedeutet das Zählen von Likes nichts anderes als, dass die Community XY wusste, wo sie abstimmen muss.

@dcrmda

Ich denke, er meint damit, dass jedes Mal, wenn Sie ein Paket installieren, das von React abhängig ist und NPM zum Überprüfen von Versionen und Abhängigkeiten trifft, NPM dies als download des Pakets zählt, auch wenn dies nicht der Fall ist heruntergeladen.

Wenn er das meint, dann ist er ganz richtig; NPM erklärt ausdrücklich, dass sie dies tun; Sie beschreiben ihre "Methodik" als "absichtlich naiv" (sie erwähnen auch, dass Bots und Spiegel die Zahlen verzerren können, da sie keinen Mechanismus haben, um zu bestimmen, wofür eine Anfrage ist, sie zählen sie einfach). Und React hat mehr abhängige Pakete, daher ist dieser Effekt stärker ausgeprägt.

Wie für viele abhängige Pakete - ja Reagieren Sie als älteres Framework, es hat mehr und es braucht sie irgendwie. Ich entwickle sowohl mit React als auch mit Vue, und mit Vue benötigen Sie tendenziell weniger zusätzliche Pakete, da der Kern ziemlich vollständig ist und der offizielle Router und Vuex auch der Philosophie der geringen Abhängigkeiten folgen. Vue selbst ist nicht von Paketen abhängig, React ist von wenigen abhängig. Sie haben diesbezüglich unterschiedliche Ansätze.

Ein anderes Beispiel ist, dass Benutzer dazu neigen, ein Integrationspaket zwischen beispielsweise Bootstrap und React zu verwenden oder Bibliotheken wie Stilkomponenten, Klassennamen usw. zu verwenden. Bei Vue ist dies im Allgemeinen nicht erforderlich, obwohl solche Projekte auch existieren. Ich finde es viel einfacher, mit Vue zu arbeiten, da ich sofort CSS mit Komponentenbereich ohne zusätzliche Bibliotheken oder Konfiguration haben kann und meine eigenen einfachen Integrationen mit CSS-Frameworks nach Bedarf schreiben kann, anstatt eine ganze Integrationsbibliothek zu importieren und dann einen Baum auszuprobieren -ausschütteln der 75%, die ich nicht brauche.

@PericlesSouza Sie haben ein paar ziemlich relevante Artikel in Ihrem 'Pros of

Benannte Slots, um wiederverwendbare Vorlagenkomponenten wie Standardformulare, Eingaben, Layouts usw. zu ermöglichen. Dies ist flexibler als die Verwendung von untergeordneten Elementen.

Bedingte Komponenten mit der optionalen Fähigkeit, den lokalen Status beizubehalten, ohne die nicht aktive Komponente zu zerstören.

Das HTML-Element 'Is' ist eine Vue-Komponentensyntax für Zeichenfolgenvorlagen, die das Anheben gerenderter HTML-Elemente verhindert, die zu ungültigem HTML führen.

Einweg-Datenfluss mit Requisiten, aber mit einem stark vereinfachten "Emit" - und "Event Bus" -Fluss, um Geschwister oder Eltern zu benachrichtigen oder zu aktualisieren. Dies kann nützlich sein für die Interkommunikation zwischen:

Mehrere Vue-Instanzen auf einer Seite, die bestimmte Regionen steuern. Diese Technik ist nützlich für dynamische Dashboards oder steckbare Widgets sowie für die Speicherverwaltung.

Globale und lokale Registrierung von Komponenten und benutzerdefinierten Richtlinien.

Verkettbare Filter zusätzlich zu den berechneten Eigenschaften.

Alle oben genannten sind Teil der zentralen Vue-Bibliothek.

React ist ein großartiges Framework, und ich verwende es gerne, aber ich persönlich denke, Vue ist für diesen vorgeschlagenen Anwendungsfall besser geeignet.

@ Mcquiggd

Ja, ich war gehetzt und hatte keine Zeit, eine vollständige Liste der Vorteile von Vue zu erstellen.

Es ist interessant, dass Sie erwähnt haben, dass React Abhängigkeiten hat, da ich bemerke, dass es von fbjs abhängt . Ich habe Teile hervorgehoben, die Alarmglocken auslösen sollten, wenn Leute über React nachdenken, mit der zweistufigen Lizenzierungsstrategie von Facebook, während Code zwischen unterschiedlich lizenzierten Projekten ausgetauscht wird. Hinweis: Alles daran ist besorgniserregend, insbesondere wenn Sie die Liste der Projekte sehen, die davon abhängen, aber unterschiedliche Lizenzen haben.

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

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

Zweck

Um Facebook das Teilen und Konsumieren unseres eigenen JavaScript zu erleichtern.

Hinweis: Wenn Sie den Code hier verbrauchen und nicht auch ein Facebook-Projekt sind, sollten Sie auf eine schlechte Zeit vorbereitet sein. _Diese Bibliothek wird unter Berücksichtigung unserer Anwendungsfälle veröffentlicht und ist nicht unbedingt für die breite Öffentlichkeit gedacht. Wir werden Ihre Funktionsanfragen wahrscheinlich nur annehmen, wenn sie unseren Anforderungen entsprechen.

571 Offene Ausgaben (!)

Es ist jetzt 338. (Ich habe ein paar Tage damit verbracht, sie aufzuräumen.)

In den letzten Monaten war das React-Team damit beschäftigt, eine neue, weitgehend abwärtskompatible React 16- Version vorzubereiten. Es war unsere größte Veröffentlichung aller Zeiten, daher waren wir keine Antwort auf den Issue-Tracker. Das tut mir leid. Es stellte sich heraus, dass React 16 auch eine Reihe dieser Probleme gelöst hat. :-)

Ich möchte darauf hinweisen, dass die meisten der 338 verbleibenden Probleme Feature-Anfragen und Diskussionen sind. Eine Suche nach dem Bug- Label gibt mir ungefähr 60 Probleme. Angesichts der Tatsache, dass das React-Ökosystem derzeit größer als Vue ist, ist es keine Überraschung, dass Menschen auf mehr Randfälle und Inkonsistenzen stoßen und mehr Diskussionen beginnen. Sie erwarten auch, dass React to polyfill mehr Browser-Inkonsistenzen ausfüllt, so dass viele der Fehler auf eine fehlende Abdeckung dieser zurückzuführen sind. Darüber hinaus bewahren wir die Dokumentation im selben Repository auf, sodass sich einige dieser Probleme auf Dokumente beziehen.

Ich hoffe, dies gibt Ihnen einen Einblick, warum wir tendenziell eine höhere Anzahl von Problemen haben als Vue.

Es ist interessant, dass Sie erwähnt haben, dass React Abhängigkeiten hat, da ich bemerke, dass es von fbjs abhängt. Ich habe Teile hervorgehoben, die Alarmglocken auslösen sollten, wenn Leute über React nachdenken, mit der zweistufigen Lizenzierungsstrategie von Facebook, während Code zwischen unterschiedlich lizenzierten Projekten ausgetauscht wird. Hinweis: Alles daran ist besorgniserregend, insbesondere wenn Sie die Liste der Projekte sehen, die davon abhängen, aber unterschiedliche Lizenzen haben.

Leider ist dies unbegründete FUD, Punkt. Ich bin mir nicht sicher, was Ihre Motivation für die Verbreitung ist, aber React wurde als MIT erneut lizenziert, und dazu gehört auch jeder Code, von dem React abhängt (z. B. fbjs). Hier gibt es kein hinterhältiges Schema.

Sie können selbst sehen, dass die Lizenz fbjs fünf Tage vor Ihrem Kommentar unter https://github.com/facebook/fbjs/commit/c69904a511b900266935168223063dd8772dfc40 ebenfalls in MIT geändert wurde. Die vor einigen Tagen erschienene React 16-Version enthält kein einziges Nicht-MIT-Byte.

Die Tatsache, dass andere Projekte von fbjs abhängen, aber eine andere Lizenz haben, ist völlig irrelevant, genauso wie es irrelevant ist, dass Ihr Anwendungscode wahrscheinlich nicht MIT ist, sondern von Vue abhängt.

PS Ich denke, Vue ist großartig und ich möchte niemandem auf React drängen. Aber ich möchte sicherstellen, dass wir diese Diskussion auf Fakten stützen. :-) Wir sind immer offen für Kritik und ich bin sicher, dass sowohl Vue als auch React voneinander lernen können.

Das alles ist ein aufregendes Gespräch.

Ich muss fragen - warum überhaupt ein Framework / eine Bibliothek? Wie bereits erwähnt, scheint der Webkomponenten-Standard das zu liefern, wofür ReactJS, Vue und andere entwickelt wurden (da der Standard nicht existierte).

Sie können Statusbibliotheken wie Redux gut mit Webkomponenten verwenden. Ähnliches gilt für Routing-Bibliotheken. SSR ist mit Webkomponenten nicht ganz so entwickelt, aber es gibt auch Leute, die dort arbeiten. Teilweise ist der größte Wert von React die verschiedenen unterstützenden Bibliotheken, die nicht unbedingt durch die Verwendung der Plattform verloren gehen.

Was bietet Ihnen das XXX-Framework gegenüber Plattform-Webkomponenten?

Aufregendes Gespräch in der Tat ...

Die vierte Lizenz für React.

1. Ursprünglich Apache 2.0. Hätte gut gehen sollen, oder? Was war das Problem?
2. Dann BSD + Patente. Ohne zu offenbaren, welche Patente existieren oder nicht.
3. Dann leichte Änderungen, angeblich um Google zu gefallen. Ohne Einzelheiten darüber, warum.
4. Jetzt MIT mit nicht spezifiziertem Refactoring von React, jedoch nicht für direkt verwandte Projekte wie React Native, GraphQL usw. und der gemeinsamen Abhängigkeit von der öffentlichen Beschreibung "Um Facebook das Teilen und Konsumieren unseres eigenen JavaScript zu erleichtern. In erster Linie können wir so Code versenden, ohne uns zu viele Gedanken darüber machen zu müssen, wo er lebt. "

Anscheinend ist das alles überhaupt kein Grund zur Sorge.

[Bearbeitung von Tammie Lister entfernt: Persönliche Hinweise wie diese sind nicht akzeptabel]

@PericlesSouza Sie können argumentieren, dass uns nicht vertraut werden sollte, da die Lizenzen zuvor verwirrend waren. Das ist gültig, wenn es Ihr Argument ist. Aber die Lizenzen sollten jetzt nicht verwirrend sein.

Reaktion ist MIT.
Seine Abhängigkeit fbjs ist MIT.
Der Code, den React und React Native gemeinsam nutzen (der im React-Repo enthalten war und bleibt), ist MIT.
React, einschließlich aller seiner Abhängigkeiten, ist MIT.
Create React App ist nicht erforderlich, um React zu verwenden, aber es ist auch MIT.
Relay und graphql-js sind für die Verwendung von React nicht erforderlich, aber auch MIT.

Wir haben React 16.0 mit der neuen Lizenz veröffentlicht. Es ist einfach, dies zu überprüfen.
Wir haben auch eine neue Version von React 15.x mit der MIT-Lizenz als 15.6.2 veröffentlicht.
Wir planen, alle zukünftigen Versionen von React auch unter der MIT-Lizenz zu veröffentlichen.

Hinzu kommt, dass ein anderer Facebook-Mitarbeiter in diesem Thread zugegeben hat, dass React (MIT für 16? Was für <16? 17+? Beobachten Sie das package.json besser genau) und React Native-Freigabecode, für den ein Refactoring erforderlich war (und dann ihren Kommentar bearbeitet) diese Aussage zu entfernen, nachdem ich sie zitiert habe).

Ich bin dieser Ingenieur. (Ihr.)

Sie haben https://github.com/WordPress/gutenberg/issues/2733#issuecomment -331737418 kommentiert, dann habe ich https://github.com/WordPress/gutenberg/issues/2733#issuecomment -331738521 geantwortet.

Hier ist der ursprüngliche Inhalt unserer beiden Kommentare, der in meinem E-Mail-Client aufgezeichnet wurde:

Hier ist der Inhalt genau in diesem Moment:

Nachdem ich meinen Kommentar abgegeben habe, haben Sie Ihren Kommentar so bearbeitet, dass er viel länger ist, einschließlich der zusätzlichen Frage:

Welche Teile werden entfernt, damit React unter MIT veröffentlicht werden kann?

Das war nicht in Ihrem ursprünglichen Kommentar. Als Antwort auf Ihre Bearbeitung habe ich meinen Kommentar bearbeitet, um Folgendes hinzuzufügen:

Wir entfernen keine Teile aus React. Die einzige mir bekannte FB-abhängige Abhängigkeit von React ist die Objektzuweisung, die ebenfalls unter MIT steht.

Was Sie dann für angemessen hielten, um mich im folgenden Kommentar anzurufen. Wie kann ich es wagen, meinen Kommentar zu bearbeiten, um eine Frage zu beantworten, die Sie in Ihrer Bearbeitung hinzugefügt haben? Ich habe keine Ansprüche bezüglich React und React Native Sharing Code entfernt oder bearbeitet.

- -

Bitte hör auf, mich mit Gas anzuzünden. Es ist anstrengend.

@youknowriad Würdest du so freundlich sein, diesen Thread zu sperren? Ich kann mir keine produktivere Diskussion hier vorstellen.

Wenn noch jemand hier berechtigterweise über die Lizenz besorgt ist, wenden Sie sich bitte an DM und ich werde mein Bestes tun, um dies zu klären.

Was Sie dann für angemessen hielten, um mich im folgenden Kommentar anzurufen. Wie kann ich es wagen, meinen Kommentar zu bearbeiten, um eine Frage zu beantworten, die Sie in Ihrer Bearbeitung hinzugefügt haben? Ich habe keine Ansprüche bezüglich React und React Native Sharing Code entfernt oder bearbeitet.

Offensichtlich habe ich auf Ihre Bearbeitung geantwortet. Ist das Ihr Problem?

Es ist kein Gaslicht erforderlich, lediglich Offenheit und Konsistenz von Facebook, dem React-Entwicklungsteam und der Lizenzierung. Wie die vier Lizenzierungsmodelle in Reacts relativ kurze Lebensdauer anzeigen würden, fehlt Ihr (aktueller) Beitrag leider.

Die Lizenzierung kurz beiseite legen: Was bietet React heute noch einmal, das über Webkomponenten hinaus gewonnen wird? Angenommen, Sie verwenden in beiden weiterhin eine Auswahl unterstützender Bibliotheken (z. B. Redux).

Mit Webkomponenten kann WordPress viele Elemente erstellen, die für verschiedene Front-End-Frameworks / -Bibliotheken verwendet werden können. Dies würde Endbenutzern mit React, Vue, Angular oder einem beliebigen Front-End ermöglichen, WordPress-Komponenten "einzuspielen".

@sophiebits Ich

@ Brian-McBride

Sie machen einen guten Punkt, und ich glaube, es wurde früher im Thread angesprochen - "Warum nicht Vanille-Javascript verwenden", standardbasiert, vollständig konform.

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

Wie ich schon sagte, seien Sie sehr vorsichtig mit Ihrer Versionskontrolle, wenn Sie React verwenden.

Ja, wir haben versehentlich drei Dateien mit dem falschen Header festgeschrieben, aus Pull-Anforderungen, die vor der Lizenzänderung geöffnet waren. Keiner war in einer veröffentlichten Version (und konnte es auch nicht sein - einer war Unit-Test, zwei waren Teil der Website).

Fehler passieren. Wir haben es behoben, als wir herausfanden, und ich habe unserem CI ein Skript hinzugefügt, um in Zukunft zu überprüfen, ob keine versehentlichen Verweise mehr hinzugefügt werden. Sie können es in diesem Commit sehen.

Eine weitere Sache, die meiner Meinung nach freie Softwareprojekte berücksichtigen sollten - Facebook profitiert von der Verwendung von React.

Die Werte von Facebook stimmen jedoch im Allgemeinen nicht mit denen der Bewegung für freie Software überein - von unethischer Manipulation der Benutzer bis hin zu Angriffen auf die Netzneutralität ("Free Basics"), Unfähigkeit, Daten zu löschen, Unfähigkeit, die Datenerfassung zu blockieren, Zensur, ummauerter Garten , Echokammern und mehr.

[Facebook] ist wie damals, als mein Bruder mich dazu brachte, mich selbst zu schlagen und zu fragen: "Warum schlägst du dich selbst?" Dann würde er meiner Mutter sagen, dass es nicht seine Schuld war.

Da ich Facebook über viele Jahre hinweg gesehen habe, bin ich zunehmend zu dem Schluss gekommen, dass ich dieses Unternehmen in keiner Weise mehr unterstützen möchte, sodass ich persönlich keine FB-Software verwende, wenn Alternativen bestehen.

Ich habe ein Buch über React gelesen und es sieht aus Programmiersicht großartig aus - aber die Alternativen sind auch großartig und sie kommen nicht mit dem Gepäck, Facebook zu unterstützen.

Ich denke, dass freie Softwareprojekte immer unabhängige freie Softwarebibliotheken bevorzugen sollten, wenn sie verfügbar sind. Es gibt viele großartige Alternativen für WordPress, einschließlich Vue, Webkomponenten, Ember und Mithril. Vue hat eine enorme Unterstützung in der PHP-Community und hat keine ethischen Probleme damit verbunden. Es scheint also, als würde es gut passen. Wenn es nur um das Dashboard geht, lohnt es sich vielleicht, sich etwas noch Interessanteres als JavaScript anzusehen: Elm .

Es sollte nicht darum gehen, was im Moment trendy oder cool ist, sondern darum, was den nächsten Generationen die größte technologische Freiheit bietet - direkt oder indirekt.

Nur ein weiterer Gedanke zu berücksichtigen ...

Vielen Dank an alle, die ihre Meinung geäußert haben, während sie versucht haben, ein respektvolles Gespräch zu führen. Ich möchte mich auch ganz besonders bei @sophiebits , @gaearon , @ blake-newman und allen anderen Vertretern von Projekten

Die Konversation ist inzwischen zu den JavaScript-Meetings im Slack-Kanal # core-js übergegangen. Hier finden Sie eine gute Zusammenfassung . Wenn Sie an diesen Diskussionen teilnehmen möchten, laden wir Sie ein, sich uns dort anzuschließen. Alternativ haben wir zwei Ansätze zur Interoperabilität, die Beiträge, Tests und Feedback verwenden können: # 2463 und # 2791.

Und damit hat dieser Thread seinen Lauf genommen. Wir schließen das Problem, empfehlen Ihnen jedoch, das Gespräch an den oben genannten Orten fortzusetzen.

Dieser Thread hat einige gute Diskussionen hervorgebracht, aber einige davon haben inakzeptables Verhalten gezeigt und wurden bearbeitet. Es ist wichtig zu bedenken, dass https://wordpress.org/about/etiquette/ für jedes WordPress-Projekt gilt und wir keine Verstöße oder solche tolerieren, die sie begehen. Vielen Dank an alle, die rücksichtsvoll und respektvoll zum Gespräch beigetragen haben.