Gutenberg: グーテンベルクのJavaScriptフレームワークの選択（〜WordPress）

私の投票はVueJSです

VueJSを選びます

Vueには素晴らしいコミュニティがあり、今後の選択となるはずです。

Angular JS

VueJSに投票します。 上で概説したように、それは初心者にやさしく、Laravelでうまく使用されています。 それはそれを完璧な選択にします。

VueJSにも投票します

「Vueが好き」または「XYが欲しい」と叫ぶだけでは、ここでの意思決定にはあまり役立たないことに注意してください。 投票したい場合は、さまざまなフレームワークを評価するときに調査結果を文書化する場所として機能する可能性のあるスレッドを乱雑にするのではなく、絵文字反応などを使用することをお勧めします。

Vueで行きます。 学び、適応する方が簡単です。 さらに、Preactよりも議論の余地はありません。

時々出てくる「キーパーソン依存関係」の問題に対して、それはすべてのWordPress機能プラグインまたは未知のテクノロジーが何であるかではありませんか？ Koopは古いメディア処理を構築し、Westonは大量のカスタマイザー作業を行い、Matíasと他の数人はGutenbergに取り組んでいます。過去数年間に起こった、WordPressのほぼすべての主要な変更には、小さなグループの人々が取り組んでいます。またはそれを理解します。

私はこれを間違った見方をしている可能性がありますが、どの選択でも「キーパーソン依存」は赤いニシンのように見えます。 採用により、キーパーソンの依存関係が完全に排除されます。 WordPressはかつてキーパーソン（マイクとマット）の依存関係プロジェクトでもありました。 それは養子縁組を避けるための弱い議論だと思います。

繰り返しになりますが、私はこれを完全に間違って考えている可能性がありますが、それは私が時々ポップアップするのを見る一般的な考え方であり、その一見高い重要性を理解していません。

@swissspidyのコメントに追加するには、伝えるのではなく表示することも役立ちます。 人々が置き換えについて強く感じている場合は、変更と、ブランチでのコードの外観を示してください（＃2734がPreactに対して行っているように）。 最終的な決定がどうであれ、グーテンベルクはディスカッションスレッドを乱雑にするよりも、探索するほうがよいでしょう。

私はVueJSに投票します！ コミュニティが適応するのははるかに簡単です。

Webコンポーネント（Polymerなし、ただし仮想DOMが必要な場合はlit-htmlなどを使用）を真剣に検討する必要があると思います。 プラットフォームと標準の使用は、どのライブラリやフレームワークよりもはるかに優れています。 すべてのフレームワークと自然に相互運用可能な、堅牢で将来的に安全なコンポーネント構造を実現します。 （Vue、Angular、React-現在は程度が異なります：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

必要に応じて、このプロジェクトでVueまたはWebコンポーネントを試すことができてうれしいです。

グーテンベルクのPR＃2463もチェックしてください_ "フレームワークにとらわれないブロックの相互運用性（バニラ、ビュー）" _

いくつかの理由から、Vue.jsに傾倒することをお勧めします。

1. PHPフレームワークLaravel内での確かな実績。
2. より多くの人々が貢献できるように、ピックアップと採用が簡単なようです。
3. Reactから離れる場合は、それをクリーンで明確にシフトさせましょう（Preactを使用すると、ある意味でそれに固執しているように見えます（React））。

私の意見ですが、それはより良い選択のようであり、他の多くの人々はVueを好むようであり、少なくともそれはとにかく考慮すべきことです。

Vueは、Preactよりも勢いがあり、コミュニティのサポートも優れているようです。 それはより多くの問題を解決し（状態管理が付属しているため）、より穏やかな学習曲線を持っています。 ドキュメントは_excellent_です。

Preactに関する私の懸念は、法的に安全であると感じるにはReactに似すぎており（Reactの特許はPreactをカバーしている可能性があります）、単純な移植にはReactとは異なります（ヘルパーライブラリやプラグインなどを壊すのに十分な違いがあります）。

ずっと赤ちゃんをVue！

• [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/）

GithubStars->こちら
Vue.jsがあれば、WordPress開発者にとって絶対にワクワクするでしょう🖖

Vueは、時間の経過とともに優れたコミュニティを開発し、フレームワークを定期的に更新/アップグレードしてきました。

PS。 素晴らしいコミュニティ体験のためにhttps://chat.vuejs.orgに参加してください..そこに本当にdopeass開発者がいます:)

@jbreckmckye会話を

それは反応中の特許とは何の関係もありません（Facebookが持っているかどうかさえわかりません...そうでなければ、preact、vue、そして同様のフレームワークを持つ他の誰かが今までに訴えられたでしょう）

Vue.jsのコアメンバーとして、バスファクターの問題に取り組みたいと思います。 これは現在非常に提起されている点であることがわかっており、現在、いくつかの懸念に対処するための対策を講じています。

1）npmのVue.js組織アカウント。チームとして簡単に公開できます
2）物事を実行し続けるための詳細を内部的に管理する（ウェブサイトなど）
3）貢献者を誘惑し、成長するコミュニティをサポートするために、オープンコレクティブを初期化します。 https://medium.com/the-vue-point/vue-is-now-on-opencollective-1ef89ca1334b
4）Vueエコシステムは急速に成長しており、コアリポジトリの貢献の多くはコミュニティ自体からもたらされています。 https://www.youtube.com/watch?v=993X1kiisFE
5）公式のVueリポジトリを見ると、実際にはそれらの多くがEvan以外の他のコアチームメンバーによって大幅に維持されていることがわかります

全体として、Vue.jsは急速に成長しており、「バスファクター」は大幅に減少しています。 @philiparthurmooreが指摘しているように、Evanは常に大きな関与を持ち、それは良いことです。

ここにはVueJSファンがたくさんいるようです。 誰かが実際に大規模なコードベースをReactからVueに移行しましたか？ 移行パスはどのようなものですか？

私が見ることができることから、PreactはReactとAPI互換であることを考えると、はるかに実用的な選択のように思えます。 一方、Vueに移行するには、はるかに大規模な書き直しが必要になります。

@patrickgalbraithそれは実際にPreactを検討する間違った理由です。 移行が容易であるという理由ではなく、そのメリットで判断する必要があります。 Preactで次の問題が発生する可能性があります

• VueJSと比較して小さなコミュニティ
• コードの臭い—非常によく似たライブラリへの移行は、悪い習慣を強いる可能性があります（より速いパスであるという明らかな理由のため）
• Preactに固執することは、とにかくReactに固執するようなものです（スレッドで読んでください）

私はPreactを限られた方法でしか使用していないので、これはまさに私が思うことです。

@ blake-newman立ち寄って、それを片付けてくれてありがとう。 💯

移行が容易であるという理由ではなく、そのメリットで判断する必要があります。

うん。 これは長期的な決定です。

@patrickgalbraithプロジェクト全体が完了した場合、私はそれを公正な議論と見なします。 ライセンスの問題を回避するための移行部分になるためです。

@ahmadawaisのように、プロジェクトはまだ初期段階にあるため、それほど問題にはなりません。

また、Vue、React、およびPreactには非常によく似たパラダイムがあります。 2つを簡単に切り替えることができます。違いがあります。

この場合、おそらく完全に実用的ではありませんが、移行の平和を助けることができるツールもあります。 https://github.com/SmallComfort/react-vue

これは同じツールを比較しているわけではありませんが、この記事では考慮すべき大きなポイントがあります。 https://medium.com/unicorn-supplies/angular-vs-react-vs-vue-a-2017-comparison-c5c52d620176

@ blake-newmanは、開発から6か月以上経過していることを考えると、本当に初期段階にすぎませんか？ また、カリプソも2歳以上であることを忘れないでください。

とにかく、ReactとVueを簡単に切り替えることができるとあなたが言ったことを考えると、それは問題ではないと確信しています。プルリクエストを見るのを楽しみにしています。

ステンシルも有望に見えます。

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

私の意見では、これらの2つのポイントはVueの強力な根拠になります。

• 初心者にやさしいと..
• 膨大な量のコミュニティサポート

私の意見では、どちらもWordPressプロジェクトの2つの中心的な柱です。

私は一人かもしれませんが、過去6か月ほどの間、エヴァンのPatreonをかなり注意深く見ていました。彼が資金を調達できなかった場合、彼はさらに多くの仕事を引き受ける必要があると書かれています。

プロジェクトの資金が少なく、基本的に1人の人が書いた場合（6か月未満の時点）、これは実際のリスクです。 彼のPatreonの数は実際には最近減少しています。 主人公が財政が揃っていないとそれに取り組むことができないかもしれないと言った場合、財政は非常に現実的なリスクです。 1人の（素晴らしい）開発者がSF家賃を支払うことができるかどうかに依存する、大規模で長期的なプロジェクトのフレームワークの選択は大きな問題です。

もちろん、Vueは他の会社によって寛大にサポートされる可能性がありますが、それを知るのは難しいです。

コミュニティの採用は、フレームワークの寿命を保証するものでもありません。 気づかなかった場合、フレームワークは常に「死ぬ」。

とは言うものの、コアVueチームのメンバーが、名前でさえ、唯一の貢献者の問題/バス要因に実際に対処するために現れたことに感銘を受け、単一の開発の問題はそれほど問題ではないかもしれないといういくつかの理由を与えました。 しかし、それはごく最近の過去の本当の問題でした。

Vueに投票します

• シンプルなAPI / 1週間で最も基本的なことを学ぶことができます
• vuexによる単純なフラックスの実装
• 速い結果：P
• 成長するコミュニティ
• MIT

上記のすべての理由から、Vueへの別の投票。 メール通知が有効になっている方にはお詫び申し上げます。

@ michaelbdavidson7 、Vueは最終的にEvanの
私も感じている@ahmadawaisは「キーパーソン依存」に関しては正確ではありません。

この目標が達成されれば、私はプライベートな収益化チャネルについて考える時間を減らし（たとえば、サポート/コンサルティング契約を結ぶ）、代わりにVueコミュニティ全体に利益をもたらすコンテンツに取り組むことができます...

^その目標は達成されておらず、近いものでもありません。 彼がまだ契約について考えているかもしれないと彼が言ったことを意味していると仮定すると、それが変更された場合、それはごく最近の開発と見なされるべきです。 それは今のところまだそこにあります。 キーパーソンが家賃の支払いを契約している場合、彼はフレームワークに取り組み続けることができないリスクがあり、それが変更された場合、それはごく最近変更されました。

フレームワークを名前で叫んでいる皆さんは、過去数年間何も学んでいません笑。

@ michaelbdavidson7目標は、エヴァンがフルタイムで取り組んでいることをサポートすることで達成されました。 追加の目標は、彼をさらに部分的にコミュニティでサポートすることです。 したがって、コミュニティをサポートすることを唯一の目的とするオープンコレクティブキャンペーンの誕生。

また、寄付による収入源はPatreonキャンペーンだけではないことも指摘しておきます。残念ながら、Patreonはすべての企業がスポンサーになるのに適しているわけではありません。 したがって、一部の寄付は個別に支払われ、請求されます。

数が減ったのは、スポンサーの1人が中国出身であり、1年間に中国から支出できる金額に制限があるためです。 これは一時的なものであり、サポートに戻ることを願っています。

エヴァンがワークショップを行うことで得られる他の収入経路は、コミュニティだけでなく彼にとっても役立ちます。 このようにして、彼は図書館がどのようになり、使用されるかを学ぶことを支援するために直接の露出を得ることができます。 ですから、実際には見た目ほど悪くはありません。

Vueは持続可能であり、私はEvanを代表して話すことはしませんが、彼は現在の財政状況に非常に満足していると確信しています。

Reactについて私が感謝したことの1つは、そのアクセシビリティドキュメントでした。 これは、新しいフレームワークを考えるときに知っておくべきことだと思います。 ここで説明するアクセシビリティの原則は、防御的に記述されたWebアプリに適用されますが、フレームワーク固有のドキュメントがあると役立つ場合があります。

Vue.jsには、アクセシビリティに関する

最終的には、a11yのプログラムによるテストを単純かつ自動化して、a11yのエラーと警告の大部分を排除できるフレームワークがあれば素晴らしいと思います。

ライセンスだけで簡単に移行したい場合は、InfernoJSを検討できます。 https://github.com/infernojs/infernoフットプリントが小さく、ランタイムが速い、ほぼ同じAPIを提供します。 そのMITライセンス。 私はインフェルノのメンテナーの一人であり、移行を手伝うことができます。

@Havunen立ち寄ってくれてありがとう。 先日、インフェルノを調べていましたが、まだ試していません。 とにかく有望に見えます！

文脈上、インフェルノの作者はFacebookに雇われています

markoJShttp ： //markojs.com/に投票します

グーテンベルクは、InfernoとPreactの両方がサポートしていないいくつかの新しいReact 16機能、つまりポータルと場合によってはフラグメントを使用します。これらの機能の使用がグーテンベルクにとって重要である場合、Reactのようなライブラリについて話すときに考慮される可能性があります。

私がお勧めしたいDIO 8を、用語のAPIのこの時点で16を反応させるために最も近いものである主な理由。

とは言うものの、Gutenbergが前述のReactのようなライブラリにエイリアスを設定し、変更や問題が発生することなく機能するかどうかを確認することは、好奇心の実験として適している可能性があります。

それらが完全に同じかどうかは@LinusBorgによって開発されたvue-portalがあります:)

@youknowriad私はFacebookに雇われました。 @HavunenとInfernoの背後にいるチームは、私なしで素晴らしい仕事をしています。 彼らがInfernoで行っている作業は素晴らしく、機会があればプロジェクトはInfernoをチェックする価値があります:)

私はMarko.jsの作成者の1人であり、検討のためにMarko.jsをリングに投入したいと思います。 多くのコミュニティメンバーが私たちに連絡を取り、このGitHubの問題を指摘してくれました。 Marko.jsはオープンソースに適したMITライセンスを持っており、eBay.comの構築に使用されており、強力で成長しているコミュニティがあります。 ReactとVueから多くの優れたアイデアがもたらされますが、（コンパイル時の最適化を通じて）物事をよりシンプルかつ高速にするために多大な努力を払い、可能な限り定型文を削除しました。 以下の機能のいくつかを強調したかっただけです。

UIコンポーネント

Markoのコンポーネントモデルは、概念的にはReactのコンポーネントモデル（入力、状態、イベントバインディング、ライフサイクルイベント、仮想DOMレンダリング、DOM差分/パッチなど）と非常によく似ています。 カリプソでの移行は、多くの認知的オーバーヘッドを必要としません。 Markoは、単一ファイルのUIコンポーネントもサポートしています。 MarkoUIコンポーネントは次のようになります。

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>

構文

MarkoはJSXを使用しませんが、JS式をサポートするHTMLのスーパーセットを使用します。 HTMLと非常に似ていますが、VueのようにHTMLに完全に限定されているわけではありません。 これにより、ループや条件などの構文が改善され、標準のHTML文字列と比較して式が使用されている場所がより明確になります。 Marko.jsテンプレートは非常に読みやすく、保守しやすいように感じます（Markoは簡潔なインデントベースの構文もサポートしています）。

サーバーサイドレンダリング

WordPressにとってそれがどれほど重要かはわかりませんが、Markoは、非同期レンダリングとストリーミングレンダリングをサポートするNode.jsでの高性能サーバーサイドレンダリングもサポートしています。

参考文献：

• Marko vs React
• Marko、Preact、Rax、React、Vueを使用したサーバー側レンダリングシュートアウト
• なぜマルコは速いのですか？
• 10の素晴らしいマルコ機能
• Meetup：UIの構築-React、Vue、Markoの比較（Markoクリエーターから）-ビデオ| スライド

マルコに投票します!! 🙂

WordPressチーム（@ahmadawais？@m？@swissspidy？）の誰かが、Markoに関する質問に答えるために簡単なチャットをしたい場合は、Markoチームが喜んでそうします。 ：call_me_hand：😸

@私は@mのブログにこれをコメントしましたが、もっと公開された形でここに投稿したいと思いました：

EmberとGlimmer.jsの両方を含むEmberエコシステムをお勧めします。
ドロップインエディターやその他のコンテンツ動作などの小さなWebコンポーネントの場合、Glimmerは優れたエクスペリエンスを提供し、フレームワークの外部で実行できるドロップインWebコンポーネントを作成します。

ルーティング、複雑な状態管理、アクセス制御、コンテンツ管理などが関係するグッテンベルクやカリプソのような大規模なプロジェクトの場合：Emberは最高のツールセットとエコシステムを提供します
多数の貢献者がいる場合：Emberのセットパターン、アドオン、およびビルドシステムは、アプリケーションの拡張時にアプリケーションのパフォーマンスと保守性を維持するのに役立ちます。
Ember Engineとインレポアドオンは、アプリケーションのオプション部分をモジュール化してエンドユーザーがインストールできるようにするのに役立ちます。

Emberは他のコンテンツ管理システムによって頻繁に使用されており、その取り組みはその上に構築され、学習され、共有されます。
@mのブログの以前のコメントで述べたように、 Ghostは管理者と編集者にEmberを使用しますが、EmberはDrupalヘッドレス、 Cardstack 、およびConde Nast 、 Bustleなどのコンテンツ会社でも使用されます。
これは、タグリスト、コンポーネントベースのエディター（具体的にはMobiledocエディター）などの一般的な機能が、 エコシステムの一部として利用できることを意味します。

コミュニティと開発者の経験から、EmberはWordpressエコシステムに最もよく一致します（Wordpressで5年以上働いた開発者として）。
Emberには、組み込み、十分に文書化されている、またはアドオンを介して利用できる多くのベストプラクティスがあります。 これにより、「これは私のアプリで機能しますか」という質問が減り、セキュリティやパフォーマンスのバグの可能性を減らすのに役立ちます。
Emberはカスタマイズ可能な抽象化に基づいて構築されています。つまり、複雑さをエンド開発者から抽象化し、難しいコードの範囲を制限して、カスタマイズを簡単で楽しいものにすることができます。
Emberアドオンは、自動検出され、すぐに使用できるデフォルトの構成であるため、Wordpressのプラグインやテーマと厳密に一致しますが、エンドユーザーのニーズに合わせてさらにカスタマイズできます。
Ember Observerと呼ばれるEmberアドオン用の既存のキュレーションツールがあり、最も人気があり、最もよく維持され、最も安定したアドオンを見つけるのに役立ちます。

カリプソとグッテンベルクは、成熟したニーズを持つ大規模で野心的なプロジェクトです。 Emberコミュニティには、アクセシビリティ、国際化、および最新のWebアプリケーションの他の要件に対する成熟したソリューションがあります。

私はEmber.jsラーニングチームの一員であり、主要な貢献者と緊密に協力しています。EmberとGlimmerがどのようにあなたのニーズに合うかについて、他のEmberチームメンバーと話したり、会話を始めたりしたいと思います。

Reactポータルについての言及があり、Emberにはこの機能を提供するためのEmber Wormholeと呼ばれるよく維持されたアドオンがあり、ダイアログやドキュメントヘッドの変更などの機能を提供するために、この上に多くのアドオンが構築されていることを別の2¢に入れたいと思いました。 、 もっと。

Markoは、ネイティブの非同期レンダリングのサポートとサーバー側の高速パフォーマンスに投票します。!!!

@ patrick-steele- idem ＆@

もっと掘り下げます。

私は、アプリが他のアプリ内で実行されている非常に大規模な企業組織と、小さなスタンドアロンアプリケーションを使用する非常に小さなスタートアップの両方で、Ember.jsを使用してきました。 Ember.jsの強力な意見と慣習は、チームとアプリケーションの成長に合わせて生産性と保守性の高いコードベースを維持するのに役立ちました。 これにより、プロジェクト間で（エンジンまたはアドオンを介して）コードを共有できるようになるだけでなく、規則を学習した開発者が生産性を高め、ほぼすべてのEmberアプリケーションに貢献できるようになります。

Emberの最大の利点は、停滞のない安定性です。 テンプレートを変更することなく、レンダリングエンジンを完全にリファクタリングした新しいバージョンのEmberがリリースされたとき、パフォーマンスが大幅に向上しました。 抽象化レベルは、成長する可能性があり、遠い将来に拡張する必要がある最新のリッチWebアプリケーションに最適のようです。

変更が必要な場合、移行が中心的な関心事であり、非推奨ガイドがあらゆる段階で役立ちます（最近では、JavaScript AST / CST変換を使用してアプリケーションを自動的にアップグレードします）。

@rtabladaで言及されていないEmberを使用する他の人気のあるWebアプリケーションには、 Twitch.tv 、 Herokuダッシュボード、 Travis CI 、およびDiscourseが含まれます。

@SaladForkアップデートに感謝します。私は、コンテンツ管理の分野で主に企業に名前を付けることから始めました。

大規模なオープンソースのEmberアプリケーションの例は次のとおりです。

• Travis CI
• Hospital Run-特にアフリカの低接続でオフラインで使用するために構築されたEMR（電子医療記録）システム
• 幽霊

彼がどれだけ詳細に説明できるかはわかりませんが、 @ tehvikingにpingを

Markoのパフォーマンス、柔軟性、非常に明確でわかりやすい構文に投票します。

マルコも+1。 髪の毛が抜けて灰色になる前にフロントエンドの作業を行っていたので（昔のように）、これは私が長年探していたフロントエンドのフレームワーク/ライブラリです。 それは私が@ patrick-steele- idemと@mlrawlingsと一緒にeBayで働くのが好きな大きな理由でもあります。

MarkoJSが私の投票権を持っています。 使いやすさとパフォーマンスを考えると、非常に過小評価されています。

私はmarko-widgetと効率的なmarkoが大好きです。 単に卓越した無駄のないフレームワーク。 他のフレームワークよりもはるかに高速です。 ベンチマークはこちら

私はMarkoJSに投票します、私たちは長年ハンドルバーショップでした。

マイクロサービスに移行し、プラットフォームのコンポーネントベースのアーキテクチャを有効にするという戦略的な動きをしたとき、サーバー側のレンダリングとクライアントのレンダリングの両方のバランスをとる適切なフレームワークを探していました。 私たちは、南アフリカやメキシコなどの新興市場を含む6つの異なる市場に分類されているプラ​​ットフォームであり、データが大きな懸念事項であり、数年前のデバイスでのユーザーのブラウジング要件を実際に尊重するサイトが必要です。より少ないデータ。 また、ユーザーは購入したいアイテムが見つかるまでサイトを前後にナビゲートします。つまり、ユーザーがナビゲートするときに、非常に高速なサーバーレンダリングを実行する必要があります。

慎重に検討した結果、MarkoJSがサポートしているという事実を考慮して選択しました。

1. 優れたサーバーパフォーマンスを備えた高速サーバーレンダリング
2. できるだけ早く最初のバイトを押し出します
3. マイナーコンポーネントを構築し、データの準備ができたときに非同期でレンダリングする機能
4. プラグアンドプレイコンポーネントアーキテクチャを構築する機能
5. React / Vueと同じかそれ以上のアーキテクチャでクライアントのレンダリングを最大化します。
6. レンダリングのテストだけでなく、コンポーネントの状態にも使用できるコンポーネント駆動型テスト

（eBayクラシファイド広告のサクセスストーリー）

Angularの場合は+1（AngularJSではありません）。

Angular CLIは、すべてのフレームワークの中で群を抜いて最高であり、バージョン間のシームレスな移行のための移行計画が用意されているため、非常に適しています。

Plus Angularは、WordPressがコンサルタントやフリーランサーのプラットフォームとして成長し続け、底辺への競争ではなくなる場合に、WordPressがある程度の愛情を注ぐことができる企業分野で広く採用されています。

すべてのレベルの開発者の強力なコミュニティがあります。 コアチームは、Googleで働いているかどうかについて話すのがいつも素晴らしいです。 WordPressは主に（ほとんどの高レベルの開発者にとって）彼らが関与しているコミュニティなので、コミュニティに関して言えば、Angularは非常に適しています

私は最近、サーバーレンダリング環境でのVueについて話をしました（スライドはこちら）。過去数か月間、.NET環境でVueを使用して作業してきたので、環境で作業するための他のオプションはないと確信しています。そのように。 バックエンドがサイトの大部分を制御し続けることを可能にしながら、高度な対話性のためにJSにプルする必要があるものをコンポーネント化できるという非常に優れた組み合わせが得られます。

つまり、WordPressが現在持っているものの上に構築するのにほぼ完璧です。 他のサーバーでレンダリングされたJSライブラリは、おそらくノードを必要とします。 Vueはしません。 <gutenberg-editor>ようなコンポーネントを登録して、WordPressに文字通り<gutenberg-editor>をHTMLで送信させることができます。 Vueは、WordPressから送信されたHTMLを使用してページをブートストラップできます。 その点ではWebコンポーネントに少し似ており、サーバーレンダリングを取得するために別のBEテクノロジーを必要としません。

Laravelのようなフレームワークがデフォルトとしてそれを選んだ理由の1つです：それは非ノードバックエンドに統合するのがとても簡単です。 WordPressも同じ理由で採用すべきだと思います。

私はVuejsに投票し
彼のコメントに関する@borantulaの同じケース

私のCTOはVuejsをチームに紹介しました-フロントエンドの初心者で、彼らはすぐにそれに参加し、今ではVuejsに満足しています。 私のチームは多くのプロジェクトでWordPressを使用しています。
現在、VuejsとCustom Elementを使用して、バックエンドでWordPressを使用するプロジェクトのフロントエンドを作成しています。 それは非常にスムーズに動作します。

@ blake-newmanとEvanが言ったように、Vuejsはもはや単一のキーパーソンに依存しなくなったので、 @ ahmadawaisが言及したCONSはもはや存在しなかったと

MARKOは私たちのウェブアプリでうまく機能します。 プログレッシブレンダリングは魅力のように機能します。

PreactやMarkoJS（コメントで頻繁に参照されます）については何も言えませんが、1年前に私たちのチーム（主に当時php + jQueryに取り組んでいた）に紹介したVueについて話すことができ、JavaScriptの理解が徐々に変わります。 jQueryの精神状態から抜け出す。

グーテンベルクだけでなく、WordPressの長期的な目標、インターフェースでより多くのJavaScriptを備えたよりAPI指向のプラットフォームに移行することは良い選択だと思います。 学習曲線が簡単で、慣れていると、他のWP開発者も参加するようになります。

私はVueJSがLaravelコミュニティでどのように繁栄し、ほとんどの人にとって事実上の選択になるかを見ました。WordPressコミュニティでもそうなると思います。

Backbone.js

/ s

私はMarkoJSの後ろに私のサポートを投げたかった。

2年前、会社のインフラストラクチャをExpressJSとJade（現在はPUG）からMarkoJSに移動しました。 私の会社は、エコシステム全体で複雑で再利用可能なコンポーネントを作成したいと考えていました。 開発者はスピードと再利用性を望んでいました。 設計者は、設計負荷を減らすことを望んでいました。 それ以来、振り返っていません。

現在、Markoで作成された複数のクライアント向けWebサイトと、CMSシステム全体もあります。

最終的に、私は次の目的でMarkoJSを選択しました。

• KoaやExpressJSなどのフレームワークでも高速サーバーレンダリング
• ページデータの非同期レンダリングを処理します
• より大きなエコシステムのためのプラグアンドプレイコンポーネントを構築する機能
• React / Vueよりも優れたパフォーマンス
• 非常に簡単なテンプレート構文

また、MarkoJSチームは文字通り優れていることを指摘したいと思います。 @ patrick-steele- idemと参加しています。

👍MarkoJSの場合

PreactはReact-API互換ライブラリです。つまり、PreactはReactのエコシステムと利用可能な多数のOSSパッケージ/コンポーネントから直接恩恵を受けます。 Vueのエコシステムはそれに比べてはるかに小さいです。 サードパーティのVueパッケージ/コンポーネントのドキュメントは中国語です。

「私はXYZに投票します」ということはもうしないでください。この問題を購読している人に不必要な返信を送る以外は、会話に追加することは何もしません。

🔥角度

• PRO： Reactの最大の競争相手
  たくさんの人のために。 質問はしばしば「AngularまたはReact？」です。 /「ReactまたはAngular？」。 Angularコミュニティは、間違いなくReactの選択肢の中で最大であり、急速に成長しています。

• PRO：たくさんの学習リソース
  公式のAPIドキュメントとガイドに加えて、Angularにはおそらく、教育資料、ブログ投稿、書籍、すべての主要な学習プラットフォームで無料と商用の両方の多くのビデオコースの最大のエコシステムがあり、ワークショップや会議でそれを教えるGoogleGDEがあります。

• PRO： Reduxとうまく統合します
  直接、またはRxJSを利用したNgrx（Angularチームのメンバーによるサポート）

• PRO：クラス最高のツーリングサポート

  • CLIには他のCLIよりもはるかに多くの機能があります

  • 特に言語サービスを使用したVSCodeでの非常に優れたエディターサポート

  • TypeScript用に作成され、最高のTypeScriptエクスペリエンスを提供します

• PRO：デフォルトで豊富で、意見があり、整理された機能
  Angular Modules（NgModule）を介した論理的な分離、およびフォーム、HTTP呼び出し、ルーティングなどの標準機能により、他の開発者がコードを読み、それに貢献することが容易になります

• PRO： RxJSとの最適な統合
  多くのAPIストリーム、および一般に1ページのイベントの多くのストリームに役立ちます

• PRO：組み込みのDI（依存性注入）システム
  特にRxJSと組み合わせると、拡張ポイントやプラグインシステムを作成するのに便利です。

• PRO：他のライブラリがカバーする他の多くのボックスをチェックします

  • パーミッシブライセンスを持つUIライブラリ
    PrimeNg、Angular Material 2、ngx-bootstrapなどがあります...

  • 遅延読み込み
    遅延読み込みルートの組み込みサポート、および手動での遅延読み込みモジュールもサポート

  • コンポーネント固有のCSS
    CSSがコンポーネントのみにスコープされ、コンポーネントがロードされたときにのみロードされ、グローバルCSSのフックがあることを確認します

  • サーバーサイドレンダリング
    すでにNodeとASP.NET Coreを使用しており、最近はより焦点を絞っています

  • テスト
    Angularは、ユニットテストを非常に簡単にするユニットテストフレームワークにとらわれないテストヘルパーを提供します。 デフォルトでは、Jasmineを使用してCLIからテストを生成します。これは、Jestに簡単に切り替えることができます。 また、オプションのSeleniumラッパーProtractorを提供して、E2Eテストを簡単にします（実際には必要ありませんが、AngularアプリにはSelenium .NETを使用していますが、Angular固有のものはありませんが、さらに簡単にしようとしています）。

  • モバイル/ PWAサポート
    GoogleはPWAの最大のサポーターであり、サポートはすでにAngular CLIで表示されており、Service WorkerとUniversal（サーバー側のサポート）、Ionic（Cordovaのサポート）、NativeScript（ネイティブアプリ）があります。

• PRO：ブラウザのサポートに焦点を当てる
  ドキュメントに専用のポリフィルページがあり、CLIにデフォルトで（コメント付きの）ポリフィルを挿入することで、AngularはIE <= 11などに必要な正確なポリフィルのループを維持するため、はるかに大きなポリフィルをロードする必要はありません。理由もなく設定されます。 それは彼らがブラウザのサポートに関心があるからです。

• PRO：大企業の支援
  Angularは、ここで説明した数少ないライブラリの1つ（唯一のライブラリですか？）であり、大企業が支援しています。
  ここに支援することで、いくつかのプロジェクトでそれを使用してエコシステムに貢献した企業だけでなく、開発者やテクニカルライターにフルタイムで働き、コミュニティリーダー（この場合はGDEやDevRel）に投資する公式のメンテナーになりますGoogleの）。
  これはCONではなくPROです。これは、追加の条項や失効メモなど、一部の人を混乱させたり怖がらせたりする可能性のあるものがないMITライセンスが付属しているためです。

プラグイン、 RESTAPIなどのいくつかのプロジェクトに

今日、Vuejsは急速に成長しています。 VuejsがWordPressコードに統合されている場合は、賢明な選択です。

@cyberwani @ thephilip @ evoratecなど。

@ntwbはすでに次のコメントに返信しています：

「私はXYZに投票します」ということはもうしないでください。この問題を購読している人に不必要な返信を送る以外は、会話に追加することは何もしません。

ですから、無駄なコメントはやめてください。 サポートを示すために、github絵文字を使用して、ライブラリを支持するコメントを高く評価することができます。

Vue。

ちなみに、現在Vueの背後にはAlibabaがあり、モバイルでVueapiを有効にするWeexApacheプロジェクトもあります。

私は本当にここにいくらかの節度を置きます、明確な議論のないあまりにも多くのファンの男の子

これが最後の警告です。次のステップは、コメントの削除を開始することです...

私自身、Marko、Preact、またはVue.jsを使用したことはありません。正直なところ、これらのいずれにも精通していません。WordPressコミュニティがこれらのフレームワークについて述べていることを聞いて、読んでみたいと思います。それらのそれぞれ、それぞれの技術的メリット、それぞれの周囲のエコシステム、ビルドツール、そして最後になりましたが、これらのプロジェクトの背後にある人々とコミュニティ。 😄

「私の投票はXYZに対するものです」を読みたくありません。投票を追加したい場合は、上にスクロールして、すでに上で述べた選択したフレームワークに絵文字_親指を立てる_反応を追加してください。 👍

以前のコメントから2つの新しいコメントが表示されるのにそれほど時間はかかりませんでした😞

そのために...あなたのコメントがhttps://github.com/WordPress/gutenberg/issues/2733#issuecomment-329705942の後に追加され、あなたが言ったのは_「私はXYZに投票します」_またはそれにテキストだけですコメントが削除される可能性が非常に高いため、同じ同類の今後のコメントも削除されます。

この問題に戻ってコメントが削除された理由がわからない場合は、これが理由です

@ahmadawaisコメントがいくつかあります。

グーテンベルクのReactから...への移行？

について：

@patrickgalbraithそれは実際にPreactを検討する間違った理由です。 移行が容易であるという理由ではなく、そのメリットで判断する必要があります。 Preactで次の問題が発生する可能性があります

• VueJSと比較して小さなコミュニティ
• コードの臭い—非常によく似たライブラリへの移行は、悪い習慣を強いる可能性があります（より速いパスであるという明らかな理由のため）
• Preactに固執することは、とにかくReactに固執するようなものです（スレッドで読んでください）

自明ではないコード行数のプロジェクトがある場合は、非常に注意する必要があると思います。 エンジニアは物事を書き直し、新しい言語とフレームワークを学び、そのコードを書き直すことができればより良い仕事をするだろうと考えています... Joelは、かなり前に非常に雄弁に書き直しの危険性について話しました。
Preactを使用すると、時間を大幅に節約できます。 完全に新しいフレームワークに移行するのにかかる時間を過小評価するかもしれません。 なぜ「それがPreactを検討するのは間違った理由だ」と書いたのかわかりません。 エンジニアとして、ソリューションの評価と選択に使用する基準のリストでは、コストと市場投入までの時間が高くなっています。
問題が本当にFacebookの特許である場合、Preactはそれを解決してコストを最小限に抑えます。 Preactは、ReactやVueよりもパフォーマンスが高く、フットプリントが小さく、ランタイムレンダリングが高速です。 AddyOsmaniの記事もチェックしてください。

Preactコミュニティの規模をどのように評価したかわかりません。 エコシステムと利用可能なコンポーネントについて話している場合、Preactを使用すると、Reactのオープンソースコンポーネントのほとんどを使用できます。 したがって、実際問題として、Preactに明示的に取り組んでいなくても、利用できるコードを作成している人がいます。 ReactのエコシステムはPreactのエコシステムの一部と見なすことができます。

なぜVueはまだあなたのお気に入りのオプションですか？

ここでの3番目のポイント「Preactを使用することは、とにかくReactを使用することに似ています」が、Preactを選択することを躊躇している主な理由だと思います。 私が間違っている？ 特許以外のReactの何が問題になっていますか？

全体像を見る

グーテンベルクのために選んだものはすべてカリプソにも使われると読みました。
グーテンベルクはフロントエンドでのみReactを使用しています。 サーバー側のレンダリングを見ると、状況はより複雑になりますが、Preactは依然としてより簡単な移行オプションのようです。

私はあなたがあなたの基準を見る必要があると思います。 書き直しを真剣に検討していて、同形レンダリングを維持することが重要である場合、 MarkoJSは候補のリストの上位にあるようです。

私がゼロから始めて、Reactエコシステムを無視することをいとわなかった場合、MarkoJSは非常に簡単です。

私はパフォーマンスを見ていますが、 MarkoJSにはライバルがいないようです。 Reactより40倍、Vueより6倍速いのは非常識です。 私の本では、30％の改善は関係ありませんが、10倍以上の改善がある場合は、真剣に注意を払う必要があります。
適度に成功したプレゼンスがあり、100台ではなく10台、または20台ではなく2台のサーバーを使用できる場合、大きな違いが生じます。

完全な開示私はPreactとMarkoJSのどちらにも感情的な愛着を持っていません。 私は、それらがエンジニアリングの見通しからの代替案よりも理にかなっていると思います。

あなたの決定で頑張ってください😃

@ChrisCinelliこれらはssr番号です...

私はDrupalの世界から来ました（私たちはこの問題を監視しています：D）ので、私はこれに利害関係はありません。 しかし、コメントを読むと、ここには約5つの「トップ」フレームワークがあり、誰もが選択したフレームワークを気に入っているので、それに小道具を与えることができます。

最近はスピードの面は関係ありません。 考慮すべき2つの要素は、a）本当にすべてを書き直したいのか、b）React開発者の移行はどのようになるのか、そして勝利したfwの学習は新しい開発者のようになるのかということだけです。

簡単に移行できるように、preact-compat、inferno-compat ...レイヤーがありますが、パフォーマンスが低下します。 一方で、時間の経過とともに移行がスムーズになり、すべてを一度に書き直す必要はありません。 ビジネスPOVから、これは非常に簡単です。 コミュニティのPOVと将来から、それは何の違いもありません。

今、DXはそれがすべてあるところです。 リアクティブfwの経験がある人なら誰でも、概念が同じで構文だけが異なるという理由だけで、新しいfwへの移行に問題はないはずです。 しかし、初心者、それが重要なのです。 新しいfwで生産的になるのはどれほど難しい/簡単か。 既存のコードを読んで理解するのはどれほど難しい/簡単か。 そして、これはa）優れたドキュメントとb）コミュニティ（フォーラム、SO、チャットルーム、ブログなど）にのみ依存しています。

私が言ったように、私はWPの男ではないので、どのFWを好むかは言いません。 しかし、世界中の何千人もの開発者に影響を与えるような大きな決定に関しては、頭を冷静に保つために2cを提供したいと思いました。

@ntwb ：コメントは削除していませんが、ある種の検閲として、ファンの男の子のコメントも削除すると思います。

なぜ：

コメントが＃2733（コメント）の後に追加され、「XYZに投票します」またはその趣旨のテキストだけがコメントが削除される可能性が非常に高い場合、同じ同類の今後のコメントも削除されます。

その上にファンボーイのコメントがたくさんあります。 なぜ彼らはとどまるのですか？
それは二重基準のようです。

Angular、それは明確な選択です。 RoyとMeligyは素晴らしいポイントを作り、100％サポートしていると思います。 WordPressは、使用中だけでなく、その開発方法論の観点からもエンタープライズ領域に移行しています。

楽しいソースをリンクします： https ：

@ChrisCinelli 「xyzに投票する」と言わないようにお願いしたからといって、どこから来たのかはわかりますが、コメントを削除するのは悪い形だと思います。それらのいずれかを削除します

推奨しなかったフレームワーク（上記のAngularを

以下は、Reactライセンスに関する弁理士/知的財産弁護士によって書かれた投稿からの引用太字のハイライトはソースからコピーされています）：

私はたくさんのことを手に入れました。「それでは、すべて[ここで代替フレームワーク]を使用しましょう。」 ちょっと待って。 Facebookの特許がReact（差分、コンポーネント化など）を対象としている場合、それらの特許はPreact / Vueなどを対象としている可能性があります。

しかし、Reactはあなたに特許を与えます！ 別のフレームワークを使用すると、最初から侵害者になります。 これはすべて、Facebookが特許を持っているかどうかと、それらを強制したいという彼らの願望に帰着しますが、これをn度まで戦争ゲームにしたい場合は、 Reactの代替手段の方がリスクが高くなります。

さて、私の理解が正しければ、WordPressはライセンス自体を心配しているのでReactを離れるのではなく、このライセンスをユーザーに引き継ぐ必要があるだけなので、混乱と決定を守る必要があります。

Reactの代替案に行くと、代替ライセンスが許容できる場合は防御することが少なくなる可能性がありますが、それでもWordPressに混乱が生じる可能性があります。

これが心配するものであるかどうかを決定するのはWordPress次第です。

@ChrisCinelli建設的な批判に感謝します。 両手を広げて歓迎します。

エンジニアとして、私はコストと時間がリストの上位にあることを知っています。 しかし、ここにあります。 これは特定の企業のプロジェクトではありません。 ここでの目標は異なります。

目標は、コミュニティに適したJSFWを見つけることです。 グーテンベルクはまだ立ち上げていません。 それがうまくいけば、Preactが明らかに勝者だったでしょう。

今、私たちはこれを処理する必要があります：

• JS FWは、より多くのコミュニティに簡単に採用できます
• 私たちが選択するJSFWには、独自のコミュニティとエコシステムが必要です。
• PHPベースのプロダクションFOSSソフトウェアでの確かな実績があれば尚可です。 Vue + Laravel
• 移行が容易であるという理由だけでなく、そのメリットに基づいてJSFWを選択する

私がWordPressで過ごした11年間、そして定期的なコアコントリビューターとして、Preactを選択すると多くの混乱が生じると思います。 中級/新規開発者にとって、学習曲線はすでに巨大です。

WordPressの改善のこの新しいフェーズの開始時に、Preact-Reactの互換性の混乱を経験すると、WordPressコミュニティを離れ、同様の学習曲線で他のことを学ぶ可能性があります。 （_HINT_：WordPress + Preact + Reactの代わりにLaravel + Vue）そしてところで、Drupal 8で何が起こるかを忘れていますか？

市民のコメントは削除しないでください。 この問題について意見を表明することには、明らかに圧倒的なニーズや要望があります。 人々がWordPressを気にかけていて、聞いてもらいたいと言っているので、それは良いことだと思います。 開発者だけでなく、WordPressコミュニティがフィードバックを提供するためにGithubに転送されたことを思い出してください。 本当に+1コメントを許容できない場合は、ユーザー名を保持する集計を上部に追加します。

合理的な議論を探しているだけなら、「X、Y、またはZに投票します」というコメントの多くはノイズのように見えるかもしれませんが、Vue.jsをサポートする人々の明確なパターンが現れています。 私の考えでは、グーテンベルクにコードを提供する人は100人、または数百人いますが、グーテンベルクと相互作用するプラグインやテーマを作成する人は数万人います。 グーテンベルクの成功は、エンドユーザーエクスペリエンスだけでなく、開発エクスペリエンスにもなります。 それだけではありませんが、WordPressを成功させる重要なことは、簡単に拡張できることです。

特定のフレームワークを念頭に置いていませんが、覚えておくべきことの1つは、ブラウザーのサポートがWebコンポーネント、Webコンポーネントを利用するフレームワーク、または少なくとも次のように構築された独自のコンポーネントで機能し始めていることです。それらは将来の証拠となるでしょう。 それをサポートしていないブラウザにWebコンポーネントをもたらすためのポリフィルもあります。

先ほどお話ししましたが、通知をオフにするためにここに来ましたが、少し重くします。

シングルページアプリを最初から構築していて、時間が重要であり、十分にサポートされ、文書化され、テスト可能なフレームワークが必要な場合、時間と宝物が大幅に安価であることを示す具体的な経験がたくさんあります。エンバーと一緒に行きます。

より多くのPWAを構築したり、サーバーでレンダリングされたページにコンポーネントをドロップしたりする場合、Emberは適切な選択ではなく、Vueのようなものが魅力的である理由がわかります。

コンベンション主導の側面から、Emberを使用して90を超える灯台スコアを持ついくつかのPWAを作成したことを追加します。

これを行う必要があった最後のプロジェクトでは、灯台のスコアを取得し、サーバー側のレンダリングを有効にしてアプリをデプロイするのに1時間未満かかりました。

灯台のスコアを高くするために必要なSSRとサービスワーカーのキャッシュは、非常に難しいプロセスになる可能性があります。
Emberを使用すると、このプロセスは非常に簡単で、十分に文書化され、保守されているアドオンをいくつかインストールするだけで済みます（ほとんどのアプリの場合）。
私の経験から、PreactにはPreact CLIのこれらの機能の両方がすぐに付属していますが、SSRの結果を壊す可能性のある一般的な（P）Reactの規則があります。
Vueを使用する場合、公式ドキュメントではNuxt.jsを使用するか、完全なSSRガイドに従うことをお勧めします。 これらは両方とも、基本的なVueドキュメントを超えて従う必要のあるパターンをさらに導入します。

誰にも言わないでください。ただし、冒とく的または虐待的でない限り、問題に関するコメントの削除は控えましょう。 私は完全に人々が会話を助けて集中したいと思うようになりますが、コメントを削除するというスパイラルに入るべきではありません。

VueJS @rtabladaと比較して、Emberについて「十分に文書化されている」ものが何であるかはわかり

私は個人的に、VueやReactと比較して、Emberから始めて問題が発生するでしょう。

@ahmadawais誰もがこの決定が大きな影響を与えることを忘れており、とにかく数年以内にフレームワークを変更したいと思うでしょう。 ですから、あなたは現代のフレームワークの良さを使いたいのですが、生と死のためにそれに縛られたくないのです。 不可能に聞こえますか？ そうではありません！

しばらく前に私は同様の問題を抱えていました、そして研究と試みの後に私は水を火と結びつけようとする解決策を思いつきました。 一言で言えば、Webコンポーネントのカスタム要素、好きなラッピングテクノロジー（Vue、React、Angularなど）、標準のDOMAPIの公開。

このようなソリューションでは、複数のコンポーネントがあり、それぞれに次のものがあります。

• あなたが好きなフレームワーク（しかしもちろんできれば1つだけ）
• 他のコンポーネントが簡単に使用できる標準のDOMAPI。 プレーンなJavaSciptを介して操作することもできます

当時Vueで作業していたので、Vue用のカスタム要素のアダプター（ https://github.com/karol-f/vue-custom-element ）を作成したので、優れた互換性があります（たとえば、Vueの$ emitは標準のDOMイベントを送信できます。プレーンJSまたは例：React / Angular）およびIE9 +互換性を介してキャプチャされます。

私はあなたのような解決策を見ることをお勧めします：

• 将来性があります
• 今日選択したフレームワークに縛られることはありません
• ユーザーには標準のHTML要素が表示され、好きなフレームワークやプレーンなJSとやり取りできます。
• ブラウザが通知し、コンポーネントがページ上にある場合はコンポーネントを自動初期化するため、手動でVueを初期化する必要はありません（このようにコンポーネントを遅延ロードすることもできます）

などなど。

このようなソリューションはVueとは関係ありません。他の任意のフレームワークを使用できます。 また、Webコンポーネントのカスタム要素は標準のブラウザ機能であり、どこにも消えることはありません！

よろしく！

私の考えでは、グーテンベルクにコードを提供する人は100人、または数百人いますが、グーテンベルクと相互作用するプラグインやテーマを作成する人は数万人います。 グーテンベルクの成功は、エンドユーザーエクスペリエンスだけでなく、開発エクスペリエンスにもなります。 それだけではありませんが、WordPressを成功させる重要なことは、簡単に拡張できることです。

Vueをサポートする上で非常に重要なポイントであるため、 @ dmccanによる上記のコメントの引用。

WordPressは、出版以上のものを民主化しました。 WordPressの親しみやすさのおかげで、いくつの成功した技術キャリアとビジネスが立ち上げられたのだろうか。 確かに私のもの。

私はVueJSに有利に帽子をかぶるつもりです。 ここでのローカルJavaScriptミートアップは、VueJSのコアチームのメンバーの1人が共同で主導しており、参加した人々が他の人々よりもはるかに速く参加できたようです。 私の以前の経験はAngularJSでしたが、VueJSは非常に簡単に習得でき、最初から始めていてもコーディングを開始できました。

エンタープライズ、つまりAngularについて話している人もいますが、WordPressはその分野である程度の愛情が必要かもしれませんが、機能などはさておき、開発者のオンボーディングを容易にすることに基づいて決定する必要があると思います。 メタボックスなどで見た議論により、プラグインの作成者は、クラシックエディターがなくなった場合に単に放棄するのではなく、自分の作業を「グーテンベルク化」することができます。

Vue.jsについて言及するのに良いいくつかのポイント:(個人的な考え、他のライブラリ、FW、オプションは高く評価されており、確かに独自の機能と長所があります）

• PRO必ずしもトランスパイラーを必要とせず、使用方法を強制する必要はなく、jqueryのようにWeb上で直接実行できます。

これは、プラグイン開発者がWordpressUIと統合するのに驚くほど役立ちます。 新しいvueインスタンスをウィジェットとしてページの任意の部分にアタッチできます。 また、大きなWordpressプロジェクトは、Vueがどのように使用されるかを想定していないため、コードベースに大幅な変更Vue.jsで段階的に採用できます。 これがLaravel / Vueがとても人気があり、一緒にうまく機能している理由の成功の鍵だと思います:)

• PRO JSXとcss-in-jsもサポートされています！

これは、React / JSXコードを使用する現在のWordPressプロジェクトを、変更要件が少なく、vue.jsにすばやく移行するのに役立つ場合があります。 （babelプラグインもあります： babel-plugin-transform-react-to-vue ）

• FACT Vueは、Preactと同じように、Angular / Reactとは異なり、GoogleやFacebookなどの大企業が所有するオープンソースプロジェクトではありません。

これは、Wordpressのような巨大なプロジェクトが潜在的なベンダーロックインから逃れるために重要なことです。 会社が所有していないオープンソースプロジェクトの場合、誰かがそれを開始する必要があります（したがって、「キーパーソン依存関係」はCONとして言及する意味がありません）。

私はVueJSに投票します。
私はそれについて何も知らないからではなく、それが英語でどのように発音されるのか見当がつかないからです。 しかし、私はJoomlaを何年も使用していて、いつも間違っていると発音していました。

冗談はさておき。
ここでは、古いメタボックスとカスタムフィールドをサポートする上でどのフレームワークが優れているかについて説明している人は多くありません。 私たちが今知っているように、Reactはそれで非常に悪かった。

さて、この問題から退会するだけです。

議論に集中するために、私はここでタスクの問題を作成しました： https ：

Laravelだからといって、Vueをお勧めします。 多くのWordPressの人々は、それが取った、またはまだ取っているコースに不満を持っており、WPを2番目の選択肢として維持しながら、LaravelをメインのCMSフレームワークとして使用するように切り替えました。 Preactは単なるクローンであり、大規模な互換性レイヤーであり、NovellDOSがMSDOS、PC DOS、またはその逆であったようなものです。

cu、w0lf。

ずっとVue.js ！

あなたは確かにHyperappを見るべき
長所

1. これは、Elm（モデル、ビュー、更新）アーキテクチャと非常によく似ています。
2. 「アクション」（モデルと順番ビューを更新するために呼び出される）と呼ばれるReducerのような組み込みのReduxがあります。
3. JSXを使用
4. 「関数型プログラミング」設計を奨励します
5. 1kbなので、ロードや理解が簡単です。

短所

1. それはまだ新しいですし、エコシステムもそうです。 しかし、あなたはそれに影響を与え、それに貢献することができます。
2. まだ明らかにされていない問題があるかもしれません。

グーテンベルクブロックの原理は、 Webコンポーネントの原理とうまく調和してい

参照： Polymer-砂糖を含むWebコンポーネント。

Vueは素晴らしいオプションであり、私がそう信じている理由は次のとおりです。

私は2016年の初めにVueを見始めました。私はそれが大好きで、それが「需要がある」かどうか、またはその成長が何かを書くものであるかどうかを判断したかったのです。 当時、Githubには16,000個の星があります。 それはクールですべてでしたが、Angular vs Reactのがらくたの中で、人々は実際にはそれに適応していませんでした。

2016年9月17日に、データのすべてを失い、最初からやり直すことになりました。ちょうど1年前、今日です。 （これが私の現在のデータセットです。 ）

過去1年間、私はVueの人気が（インターネットでの言及とGithubスターの追跡に関して）_記録破りの_速度で成長するのを見てきました。 Vueは365日で40,000個の星を集めました。 これは1日あたり平均109です。 それに比べて、世界で愛されている_React_は、この同じ時間枠で49,000から75,000に増加しました。 （1日あたり71）ユーザーの評価に関して、Vueは今後数か月でReactを上回ります。

誰もがReactの成長が史上最も素晴らしいと話していましたが、Vueが実際のタイトル所有者であることに気づいていませんでした。 彼らは、Vueが有名な支援（Facebook）ではなく、ツールとして本当に愛しているために成長していることに気づいていませんでした。

Vueは、Githubのトレンドリポジトリリストに1年以上毎日掲載されています。 それがReactを上回っている日の99％。 一日の10％、Reactはカットをしません。

これらはすべて、「人気が高まっているのでVueを使用してください！」と叫びます。 しかし、私が伝えたいのは、Vueは、あらゆるサイズのアプリケーション向けの優れた、直感的で強力なツール（「小さなアプリに最適」と誤って提示されることが多い）であるため、人々が本当に愛しているために成長したということです。 しかし、ツールだけではありません。 Vueはエコシステムです。 大規模なサポートコミュニティも付属しています。

追加するかもしれません... .vueファイルは天才です。 明らかにCSSモジュールに問題があり、外部ファイルにスタイルがあるため、Reactでスタイリングを処理するために非常に多くのツールが構築されています。 （Idk ...）しかし、Vueにはこの問題はありません。 Vueには、構文に組み込まれた制御ステートメントがあり、（上記のカスタム要素のコメントを見たので）カスタム要素でうまく機能するだけでなく...論理カスタム要素のライブラリ/フレームワークです。

Preactは素晴らしいです。 正直なところ、私は今日それを使って別のプロジェクトを始めました。 しかし、Preactを見ると、ブランド外のReactがあります。 革新的であったり、Webベースのソフトウェアの作成方法を進歩させたりするために構築されたものではありません。 これは、既存のツールと同じように見えて動作するように作成されましたが、パフォーマンスを向上させるために作成されました。

それは私の2セントです。 今、私は壊れています。

あなたの最終決定があなたを幸せにし、あなたの製品の未来のための素晴らしい基盤を提供することを願っています。

@ahmadawais ：

• 市場投入までの時間は、エンタープライズプロジェクトとオープンソースプロジェクトの両方にとって重要です。 出荷前に時間がかかりすぎて陳腐化したために出荷されなかったプロジェクトの例を見つけることができます。 いくつかのプロジェクトは、メジャーリリースに向けた作業中に放棄されることになりました。
• Preactに反対するということは、「ライセンス以外の理由でReactを間違えた」という意味です。 「中級/新規開発者にとって学習曲線はすでに巨大です」とは、ワードプレスの開発者がReactですでに失われていることを意味していると思います。 それは私を驚かせません。 しかし、Vueが、たとえ冗長でなくても、学習曲線の問題を解決するとは信じがたいようです。 古いPHP WPエンジンと任意の単一ページアプリのJavaScriptフレームワークは非常に異なっています。 VueとReactは非常によく似ています。
  WordpressとLaravelの競争がなぜ見られるのかわかりません。 私はここではナイーブかもしれません。 Drupal8の話についてはほとんど知りません。
  私の見解では、WordpressはCMSであり、技術ユーザーではないユーザーベースが大きく、機能がすでに組み込まれているため、開発者を魅了しています。 多くのテンプレートがあり、開発者は開発者以外の人がカスタマイズできる新しいサイトを非常に迅速に構築できます。
  LaravelはPHPフレームワークであり、私が知る限り、CMSの多くの機能を提供していません。 開発者はもっと自由が必要なのでそれを選ぶでしょう。
• Vue + Laravelでいくつかの成功を収めたことが、「VueはWordpressに適している」という意味でもあるかどうかはわかりません。 私はPHPと任意のJSのフレームワークとの間の非常に小さな固有の相乗効果があると思います。 コミュニティに適したフレームワークを見つけることが重要であることに完全に同意します。 wordpressが依存している現在の開発者コミュニティのほとんどがVueに精通していて、彼らがそれを気に入っている場合、これは最終的な決定に大きな影響を及ぼします。

エンジニアリングの観点から、MarkoJSとVueはどちらも新しいフレームワークだと思います。 彼らはReactから多くのことを学び、その中の冗長性の一部を取り除くことができました。 その意味で、MarkoはVueよりもさらに多くの定型コードを削除しているようです。 特に、Markoは、同じ場所に保持するのに適したまとまりのあるコードを保持し、HTMLにHTMLが適していること、JavascriptにJavascriptが適していることを残します。 また、10倍高速です。 ですから、最近Vueには多くのファンがいるという事実を除けば、MarkoよりもVueを好む理由はあまりありません。

申し訳ありませんが、Markoの構文とセットアップはVueJSと比較してひどいものです。 パフォーマンスに関しては、MarkoJSがどのように機能するかを理解するための時間を追加せずに、MarkoJSが大幅に高速化されているソースは見たことがありません。

@ bovas85の構文は主観的ですが、Markoの構文が「比較してひどい」というあなたの主張には根拠がないと思います。 本当に初期のバージョンのMarkoには、VueのHTMLベースの構文に近い構文があり、Markoの現在の構文を導入したリリースは、ユーザーから非常に好評でした。

私たちは、HTMLとJSを理解している開発者に馴染みのあるものにするために、Marko構文に多くの考慮を払い、最小限の定型文で可能な限りシンプルで強力なものにしたいと考えました。 並べて比較すると、Markoテンプレートに必要なコードが少なくなることがわかると思います（これは読みやすさと保守性に優れています）。

Marko構文とVue構文の違いの概要を確認できるように、簡単にまとめたドキュメントを次に示します。

構文：Marko vs Vue

以前にリンクしましたが、MarkoとVue（およびReact）のより詳細な比較については、以下を参照してください。

Meetup：UIの構築-React、Vue、Markoの比較（Markoクリエーターから） -ビデオ| スライド

パフォーマンスに関しては、チェックアウトできるベンチマークがいくつかあります： https ：

MarkoとVueを有効にしたベンチマークのクイックランは次のとおりです。

サーバー側のレンダリングパフォーマンス

_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

クライアント側のパフォーマンス

_Chromeバージョン63.0.3218.0（公式ビルド）カナリア（64ビット）_

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

これらはMarko.js用に作成したベンチマークであるため、明らかにこれらの結果を一粒の塩で取得しますが、公平を期すためにあらゆる努力をしました。

また、Marko.jsと使いやすさに関するコメントをいくつか追加したかっただけです。

Markoは常に、Node.jsとの最も単純な統合を目指してきました。 npmを介してmarkoパッケージをインストールした後、テンプレートをHTTP応答ストリームにレンダリングするために必要なすべてのコードを次に示します。

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

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

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

それはあなたがこれまでに得ようとしているのと同じくらい簡単だと思います。

Markoは、人気のあるJavaScriptモジュールバンドラーとも連携します： http ：//markojs.com/docs/bundler-integrations-overview/

トップレベルのMarkoUIコンポーネントをDOMにレンダリングするために必要なのは、次のとおりです。

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 http://www.stefankrause.net/wp/?p=431ベンチマークによると、markoJs
Vueらと同じくらいパフォーマンスが良いです。

したがって、一般的にクライアント側のスクリプトでは、MarkojsとVueは同等のパフォーマンスを発揮すると結論付けることができます。

もちろん、私がリンクしたベンチマークにはssrは含まれていません。 だから私はそれについてコメントしません。

Vueに投票します。 jQueryはすでにWordPressを使用するためのほぼ要件です。 jQueryに精通している人は、Vue構文に精通していると感じるはずです。 DOMに関するイデオロギーは、Angularのようなものほど極端ではありません。 これは、ユーザーにとって使いやすいWordPressプリンシパルにフォールバックします。

約2年前にCalypsoについて提案したように、HyperScriptAPIを使用するMithril.jsはReactの代わりに適しています。 標準のMITライセンスがあります。

Reactから別のvdomライブラリに変換するための手間のかかる作業の少なくとも一部を自動的に行うための新しいツールへのわずかな投資は、開発者の時間の節約で十分に報われる可能性があります-Automatticがヘッジするために事前に行うことの提案としてその問題で言及されていますReactへの賭け。

非vdomライブラリを考慮しなくても、考慮できる25を超えるvdomライブラリ（たとえば、inferno.js、maquetteなど）があります。このリストのように、2016年1月にvdomオプションを考慮した別のプロジェクト用

HyperScript APIを強調する（または少なくともサポートする） Mithril.jsまたは他のvdomが最良の選択であるいくつかの技術的な理由があります。

個人的には、ReactのJSXやAngular独自のテンプレートアプローチなどのJavaScriptを利用したUIを作成するためのテンプレートアプローチや、Vueを含む他の多くのUIシステムのテンプレートシステムは時代遅れだと感じています。 どうして？ 複雑なCSSスタイルシート（以前のWordPressプラグインのように）を使用してサーバー側で生成されたHTMLテンプレートベースのWebアプリを作成するための設定と「ベストプラクティス」は、単一ページのWebアプリを作成するための「最悪のプラクティス」になりつつあります。 複雑で最新のシングルページクライアント側アプリケーションを作成するための技術的ニーズは、クライアント側コードの複雑さが増すため、主にサーバーベースのコードの場合とは異なります。 つまり、テンプレートと複雑なカスケードスタイルシートを使用するという古い「ベストプラクティス」は拡張性がないため、コードの保守が困難になります。

新たな選択肢は何ですか？ 最新のWebアプリは、Mithril + Tachyons + JavaScript / TypeScriptを使用して、すべてのコードがJavaScript / TypeScriptだけである単一のファイルにコンポーネントを書き込むことができます。 このようなアプリは、CSSや、プログラミング言語の一部を（ひどく）再実装するHTMLの非標準バリアントで部分的に作成する必要はありません。 （まあ、タキオンまたは同様のライブラリの上に必要なカスタムCSSが少しあるかもしれませんが、ごくわずかです。）

これは私がそのように書いたコーディング遊び場の例であり、そのアプローチを使用するいくつかの例が含まれています。

したがって、HyperScript（およびvdomライブラリ）を使用してUIを作成することにより、Mithrilのようなバックエンドを他のほとんどすべてのvdomまたは非vdomソリューションに置き換えることができる可能性があります。 したがって、選択肢がある場合は、HyperScript APIを使用することを選択することで、基盤となるライブラリにバグやライセンスの問題があるリスクを軽減できます。

Tachyonsまたは同様のライブラリを使用することで、アプリケーションの成長に伴う保守不可能なCSSファイルのリスクを軽減します。

確かに、私は多くのWeb開発者がHTMLの調整で育ち、HTMLに見えるテンプレートが大好きであることを知っています。 したがって、彼らはJSXなどを愛し、アプリケーションの途中でそのような非コードのものをリファクタリングしたり検証したりすることがどれほど難しいかを無視して喜んでいます。 確かに、一部のIDEはJSXテンプレートのリファクタリングが向上しています。 しかし、私はデスクトップからWeb開発を始め、（通常は）コードから直接UIを生成するシステム（Swing、Tk、wxWidgetsなどを使用）を使用した組み込み開発を行いました。 標準ツールを使用すると、作業中のすべてのコードをリファクタリングして、多くの不整合を検出できるという考えが気に入っています。

ここで実行されているすべてのフレームワークは、選択したブラウザーでの速度のためにユーザーに目に見える違いがないと仮定すると、どのフレームワークが最良の選択であるかを評価するためのメトリックとしてフロントエンドのパフォーマンスを使用するのをやめることができます。

ただし、サーバー側のレンダリングを使用する

企業は、ブラウザのCPUではなく、サーバーのCPUの料金を支払います。 したがって、コストの観点から、 Markoのレンダリング時間が10倍速いということは、MarkoJSで最大10台のサーバーと同じトラフィックが、実際にはVueを実行している少なくとも100台のサーバーを使用することを意味します。

Wordpressがそれを無視できれば、私は喜んで会社に勤め、10倍の市場給与を受け取り、Vueを使用します。ちなみに、これはReactの優れた代替手段だと思います=）

フレームワークが軽いほど、つまり、すぐに提供できる機能が少なくなるほど、実行速度が速くなります。 それは哀れなほど明白です。 さまざまなアルゴリズムのパフォーマンスを比較することは1つのことですが、最大の要因が他の「もの」の実行量である場合、テストを作成する必要はありません。

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

@ahmadawais Angularコアチームはここにあります-カスタム要素サポートへの投資を含む、CMS /ウィジェットスタイルの開発に関連する多くの興味深い作業が進行中です（私のお金では、プラットフォームを構築するための賢い未来の賭けです）

スレッドをさらに乱雑にするのではなく、興味があれば、オフラインでy'allとチャットできれば幸いです。 グーグルドットコムのrobwormaldに私に連絡してください。 これで幸運を祈ります、私はあなたがこの電話をしなければならないことをうらやましくはありません;-)

私はここで簡単な世論調査を作成し

現在、結果ページとその認証に取り組んでいます。 （Firebaseの新機能）

PS。 Vueを使用してこれを作成するのに約1時間かかりました🖖

@vinayakkulkarni投票にMithril.jsを追加してみませんか？

@pdfernhout ：👍

完了。 MithrilJSをリストに追加しました。

• [x] VueJS
• [x]角度
• [x] Preact
• [x]燃えさし
• [x]マルコ
• [x]インフェルノ
• [x]アウレリア
• [x]ミトルヒル

人々が何を決めるか見てみましょう。
PS。 @ahmadawaisによるツイッターの世論調査もありました。

こんにちは。 私はDrupalのコアメンテナーです。 @ivanjarosが以前のコメントで述べたように、Drupalの管理UIの今後のビットについて、Preact、Vue、またはその他のものも評価しています。 私たちはあなたが選ぶものとは異なる何かに決着をつけるかもしれませんが、あなたが選ぶものは確かに私たちが私たちの選択で考慮するための少なくとも1つの要因になります。

私はこれまでにこれらの2つのDrupalの問題を開きましたが、今後さらに増える予定です。 それらの問題/議論があなたに役立つ場合に備えて、ここでそれらを相互参照するだけです。

• 複数のルートノードを返すコンポーネント
• スロット対vnode小道具

これらの2つの問題にもかかわらず、私はまだVueが強く好きであることに注意してください。 これらは、Vueの他のすべての利点を得るために、私たちが一緒に住んでも大丈夫なものかもしれません。

Vueの作者として、私は明らかに偏見があるので、ここでどのフレームワークを選択するかについてコメントすることは避けます。 しかし、「MarkoはVueよりも10倍速い」という声明が何度か出されているのを見て、それはある程度の説明に値すると思います。 また、議論を技術的な議論に脱線させたくないので、興味のある人のためにこの要点にいくつかの考えを書き留めました。

@ michaelbdavidson7財務上の懸念について：私はVueに1。5年以上フルタイムで取り組んでおり、Patreonのサポートは非​​常に安定しています。 Patreonの誓約の変動について推測するのではなく、Vueのコミットアクティビティを確認して自分で判断することができます。 さらに、オープンな資金拠出チャネルを持つということは、WP / AutomatticがメジャースポンサーになることでVueの持続可能性を簡単に確保できることを意味します（マット自身はすでに個人スポンサーです！）-これは実際には両方のプロジェクトの利益と一致します。

Vuejsに投票します

@ tungbt94なぜですか？

間違いなくVueJS

より大きな問題は、なぜこの特許発行の前に反応が選ばれたのかということです。 特許がない場合でも、reactを使用しますか？ preactを選択しないことについての多くのポイントは、reactを選択しないことと同じです。

私の投票はPreactです

私はReact以外の経験があまりないので、どのフレームワークを選択するかについては重視しません。
しかし、「大きなコミュニティ」の議論はそれほど重要ではない可能性があると思います。 どうして？ Automatticがフレームワークを決定すると、その農作業は何千もの新しいユーザーを獲得するからです。 そして、WPコミュニティが正しいことを知っていれば、それらの多くもそのフレームワークに貢献し始め、人気が高まります。

グーテンベルクとカリプソが現在どこにあるかを考えると、私はまだPreactが最良のエンジニアリングの選択だと思います。

ただし、Reactに似た橋を燃やすことにまだ強いと感じている場合、または最初から始めなければならない場合は、 MarkoJsが最良の選択であると

Githubの星が何らかの形でコミュニティと相関していると仮定すると、VueはMarkoJと比較してまだ10倍

Vueは直線的に成長しています：

しかし、 MarkoJsは指数関数的成長の変曲点にあるようです。

MarkoJsの主な作者である@ patrick-steele- https： //gitter.im/marko-js/markoで常に非常に反応が。

人々が最終的にMarkoJを選択する

個人的には、 @ ahmadawaisが、関連するJSライブラリオプションを使用およびサポートする多くのJS開発者から大きな関与を生み出した単一の問題を作成したことを祝福したいと思います。

この問題は、WordPressがこれまでの他のどのグーテンベルク通信よりもグーテンベルクを介したJavaScriptベースの開発に向かっていることをより多くのJS開発者に知らせるのに役立ったと思います。

私はAngularJSを使用していますが、毎回のメジャーアップデートが気に入らないので、VueJSを使用します。

マルコは+1。 私たちのチームが使用し、非常に満足している素晴らしいライブラリ。 非同期レンダリング、超高速（サーバーでは文字列に、ブラウザではvdomにレンダリング）、単一または複数ファイルのコンポーネント、およびIMOはそこにある最高のテンプレート構文です。

@WebReflectionのhyperHTMLを考慮に入れてください。

私はAngularが好きです

Angularに投票します

Angularを選択します

ちょうど角度

Angularを選択します

角度

Angularに投票します

Angularに投票します

フレームワークに投票したい場合は、正確な理由と、それがグーテンベルクにどのように役立つかを知っておくと便利です。

「私はXに投票します」とだけ言うためにここに来るのぞき見に、私たちもXに投票する必要がある理由をいくつか教えてください。 「私はXに投票します」は、あなたがXが好きであること以外は何も教えてくれません。

角度を選択します。 Angularはバージョン2からいくつかの大きな変更があります。 今では、それは完全に、良い、強力で広く使用されているフレームワークです。それは、イオンのように、迅速ではなく、強力に研究します。

非常に多くのスパムで「私は投票しますフレームワーク」、githubは私のためにしゃがんでいます。

仲間の開発者に、「私は投票します…」と投稿するのではなく、 https ： //vinayakkulkarni.github.io/poll/https：//vinayakkulkarni.github.io/poll/でフレームワークの選択に投票することをお勧めします。

また、別の提案は、この会話をロックすることです。 ほとんどの主要な開発者はすでにこれについて意見を述べています。

18 - 9月- 2017年には、20:01で、Mingyue [email protected]書きました：

角度を選択します。 Angularはバージョン2からいくつかの大きな変更があります。 今では、それは完全に、良い、強力で広く使用されているフレームワークです。それは、イオンのように、迅速ではなく、強力に研究します。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHub https://github.com/WordPress/gutenberg/issues/2733#issuecomment-330241898で表示するか、スレッドをミュートしますhttps://github.com/notifications/unsubscribe-auth/AS3FbT23DvVwTLGL61tmK7KtuwZeg- ucks5sjn7SgaJpZM4PYie9 。

_hyperHTML_について言及してくれた

好きなJSフレームワークを共有するだけでなく、その理由も共有してください

だから私はそれをやってみよう...

：zap： hyperHTML ：

• PRO ：初心者にやさしく、P / Reactユーザーに馴染みがある（JSXの代わりにテンプレートリテラルを作成する）
• PRO ：VDOMなしで高速に燃えます。 より少ないメモリ消費（新興市場の電話に優しい）
• PRO ：ツールは必要ありません（IE <11の場合にのみトランスパイルされたテンプレートリテラルが必要です）
• PRO ：完全にJS / DOM / HTML標準に基づいていますが、TypeScriptとも互換性があります
• PRO ：追加のポリフィルやブラウザパッチを必要とせずに5K（最小圧縮）未満に収まります
• PRO ：IE9の癖まで100％のコードカバレッジ
• PRO ：対応するNodeJSと同じAPIを共有し
• PRO ：SSRレイアウト/ノードを破棄せずに既存のDOMを採用できます
• PRO ：P / Reactよりもカスタム要素でうまく
• PRO ： React 、 Vue.js 、 Polymer 、 Angular 、またはMarkoが行うことを実行でき、それぞれのサイズ/帯域幅/パフォーマンスの点で勝ちます

さて、このスレッドでこれまでに使用されたメトリックに応じて、 CONS

• 短所：バトルテスト済みで、完全にテストカバーされており、APIが凍結されている場合でも、比較的若いプロジェクト（2017年3月）であるため、人気、採用、または貢献者の数の点で競合することはできません。
• 短所：コミュニティは大いに助けており、プロジェクトは成長していますが、これまでのところ主要な技術的貢献者は私です。 私はこのプロジェクトに100％取り組んでおり、できる限りプッシュするつもりです。さらに、次の大きなプロジェクトのいくつかで_hyperHTML_を使用することについて、いくつかの「_bigs_」と話し合っています（これ以上は推測しません）。ただし、この後半部分は無視してかまいません）

：dart：Webの将来は、プラットフォームを可能な限り使用することであると心から信じています。これは、10年前よりもはるかに優れており、最新のECMAScript仕様のおかげで、書き込み、読み取り、および保守がはるかに簡単です。 _hyperHTML_は、可能性の観点から「_Webアートの現在の状態_」を表しますが、このリストの他のすべての候補は、ES6以前の時代に生まれました。

コミュニティの規模、貢献者、GitHubスターが重要であることは理解していますが、テスト、クロスブラウザーコードカバレッジ、バグの量も考慮する必要があると思います。また、_hyperHTML_と友達の数を近くに保つように最善を尽くしています。ゼロ（バグではない議論を除いて、現在は実際にはゼロです）。

最後に、大事なことを言い忘れましたが、誰も新しいソリューションにチャンスを与えず、星と誇大広告だけで判断した場合、新しいソリューションが普及するまでに必要以上に時間がかかります。

もちろん、私は最新の解決策について話しました。私の考慮事項は主観的なものと見なされるかもしれませんが、特に新しい解決策にチャンスを与えることについての私の後者の文は、私の図書館だけでなく、非常に一般的でした：smiley：

宜しくお願いします

私は角度が好きです

角張っていてグーグルでなければなりません。

私は角度が大好きです

Angularは本当のフレームワークにすぎません！

AngularJではなくAngularを選択します。

角度だけが本当のフレームワークです！

私は疑い始めています、これらのコメントはボットによって作られています。

@OP ：このスレッドをロックしてください。

私はAngularに投票します（AngularJSではありません）。

Angularはコンパイラです。Googleチームは、コンポーネント、モジュール、ルーターなど、開発の進行を容易にするために多くの優れた作業を行います。依存性注入を使用すると、多くの作業を節約してすべての依存性を調整できます。 angle-cliを使用すると、新しいプロジェクトを開始するために多くの作業を節約できます。ボックスを開くだけで、アプリはaot、ツリーシェイク、およびその他の多くの最適化で適切にコンパイルされます。

TypeScriptはAngularを備えたもう1つの優れたツールであり、MicroSoftによって提供されます。つまり、Angularプラットフォーム全体がtsで構築されています。 あなたもtsでアプリを構築します！ これは、コードの量がどんどん大きくなっているときに作業を楽にする優れたツールです。ワンクリックでIDEでリファクタリング（vscodeなど）を実行できます。 静的な型チェックにより、バグをできるだけ早く見つけることができます。 TSはOOPの優れた実装も提供します。コードをより適切に配置し、再利用できます。

また、Meterial Design2、Primengなど、Angularに基づいて構築されたコンポーネントもたくさんあります。私たちのチームが作成した、 Jigsawをお勧めします。 ZTEChinaのビッグデータ製品に採用されています。 現在、ZTEのすべてのアプリをサポートしています。

Anglarは素晴らしい選択です!!

すべてのボットへ：🖕

おそらく誰かがAngularJsコミュニティに投稿しました。 これ以上メッセージを受信したくない場合は、スレッドをミュートできると思います。

最終的には、このトピックに関する同様の会話が、WordPressの寄稿者しかない場所で行われる必要があると思います。

私がEmberJSslackコミュニティグループですでにほとんど表明しているこの問題についての私の考えのいくつかを共有したいと思います。そこでの議論を読む時間が10分あれば、それをお勧めします： https ：

その議論の私の主なポイントは次のとおりです。

• Emberフレームワークに何かを実装する2〜4週間のスパイクを他のライブラリと比較すると、他のライブラリは短期的に勝つ傾向がありますが、Emberは長期的なプロジェクトで勝ちます
• どのライブラリまたはフレームワークを使用するかを検討するときは、技術的な実装だけでなく、「ソフトスキル」の側面（コミュニティの規模、LTSをサポートする取り組み、プロジェクトの主要な決定へのコミュニティの関与）も考慮することが重要です。
• Emberは、「内部」でember-cliを使用して構築されたアプリケーションに大幅な改善を提供した実績があります。つまり、アプリケーションコードをアップグレードする必要はありません。 アプリケーションコードをマイナーアップグレードする場合もあります（ ember-watsonなどを使用したcode-modが含まれています）。これにより、パフォーマンスと生産性が大幅に向上します。

上記の点について1万語のエッセイを喜んで書くことができたので、このコメントではあまり詳しく説明したくありません。 しかし、この問題について「燃えさしの考え方」を持っている人と話し合いたい人には、私の時間を提供したいと思います。

意思決定者の誰かが私と1時間の電話をかけて、より広いEmberエコシステムについてもっと鋭い質問をしたいのであれば、喜んでそうします。 Twitterで私に連絡することができます（DMが開いています）私はコアチームメンバーではないかもしれませんが、1.0より前からEmberアプリを構築しており、さまざまなアプリですべてのアップグレードプロセスを実行しています👍

私はeBayの「MyeBay」で働いています。 最初のシングルページアプリをリリースしました。 MarkoJSを使用した開発のすべてのフェーズを楽しんだ。 私のように、ノードのストリーミングプログラミングパラダイムが好きなら、MarkoJSはストリーミングと非同期レンダリングをサポートしています。 MarkoJSについて私が気に入ったその他の事実：

• サーバーとブラウザーでレンダリングされたUIコンポーネントの動作の効率的なバインド。

• 非常に効率的なイベントの委任

• サーバーからブラウザーへの状態の高速シリアル化

@vinayakkulkarniあなたのアイデアは素晴らしいと思いますが、問題は、ブラウザーを変更することで複数の投票を残すことができるということです（同じブラウザーで試したことはありません）。

おそらくTwitterの投票を使用するか（ただし、すでに投票があります）、ログインシステムを実装して投票を一意にする必要があります。

サーバーのレンダリングは、ここでの会話とは関係ありません。 Nodeは必要なWordPressスタックの一部になることはないため、これらのフレームワークがNodeでレンダリングされる速度は、決定には関係ありません。

Vue.js！ このプロジェクトを見てくださいhttps://github.com/bstavroulakis/vue-wordpress-pwa

私はAngular （AngularJSではなく）を選択しました

Angularは非常に遅く、タイプスクリプトに基づくv4では、ワードプレスの開発には役に立ちません。

プラットフォームの成熟度に応じてAngularを選択します

Vueに投票するのは、習得が簡単で、私のお気に入りのフレームワークであるEmber Jsが大きすぎて、GlimmerJsがまだ新しいためです。 :-)

サーバーのレンダリングは、ここでの会話とは関係ありません。

私の場合、他の人が関連性があると思った機能について言及しました

ノードは必要なWordPressスタックの一部にはなりません

_hyperHTML_は、PHPを含む、サーバー側でレンダリングされたコンテンツを取得できます。 私はZend認定エンジニアであり、すでにWordPressを使用してジャーナリストや出版社と協力してきましたが、私のヒントは思いがけないものではありませんでした。

したがって、これらのフレームワークがNodeでレンダリングする速度は、決定とは関係ありません。

フレームワークがバックエンドでも機能し、サーバー側でレンダリングされたコンテンツを取得でき、NativeScriptとの互換性さえあるという事実は、今日は関係のないプラスかもしれませんが、オープンマインドなプロジェクトが検討するように、将来の互換性は機能を備えていると便利です。

@webreflection特にあなたを選ぶコメントを意味するものではありませんでした。 これは、Markoの「ストリーミングパラダイム」を強調する私の上のコメントに対応するものですが、BEレンダリングのパフォーマンスに関するすべてのコメントを網羅することを目的としていました。

見る

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

その投稿は公開されません。代わりに、グーテンベルクチームが一歩下がって、別のライブラリを使用してグーテンベルクを書き直すと言います。 グーテンベルクは少なくとも数週間遅れる可能性があり、リリースを来年に押し上げる可能性があります。

そしてもっと重要なこと：

Automatticは、グーテンベルクがカリプソを書き直すために選択したものもすべて使用します

Calypsoはすでにサーバー側のレンダリングを使用しています。 参照： https ：

したがって、私の理解では、SSRのパフォーマンスが関連しているということです。

私もAngularが大好きです！
AngularJS jsリアルフレームワーク！

Angularに投票します

@chriscinelliこれはAutomatticであり、WordPressではありません。 WordPress自体はノードを使用したサーバーレンダリングを行わないため、これらの条件下でのパフォーマンスはプロジェクトとは関係ありません。

明らかに、Angularが最良の選択です

Angularに投票します

Angularに投票します

Vue.jsに投票します。
特にビューレイヤーを処理する場合は、ほとんどの時間を節約できます。

Vueに投票する必要があります!!!

角の波を投げる

@trotylそのコメントは受け入れられません。 コメントを編集して削除しました。

ああ、AngularJSはしないでください
今はAngularです。

@mAAdhaTTahウィキペディアから：

WordPressは、2003年5月27日に、創設者のMattMullenwegとMikeLittleによってb2 / cafelogのフォークとしてリリースされました。

WordPressは、その周辺のコミュニティによって主に開発されましたが、 MattMullenwegによって設立された

これはCalypsoです： https ：

以前のコメントで書いたように、マットによるReactJSのサポートを削除したブログ投稿から、グーテンベルクとカリプソを同じテクノロジーに合わせたままにしておきたいことは明らかです。 Automatticは、SSRを使用してサーバーからCalypsoページを提供します。

これは、SSRのパフォーマンスをこの決定に関連させるのに十分だと思います。

ただし、遠い将来、Wordpress開発者がPreact（またはVue、Marko、または別のフレームワーク）に慣れると、新しいクレイジーなプロジェクトが登場し、ノードを介してWordpressのさらに多くの部分にサービスを提供することを決定する可能性があります。 それはSSRをさらに重要にするでしょう。 したがって、SSRのパフォーマンスはさらに重要になる可能性があります。

会話がSSRについて議論するようになったので、これはEmberにとって非常に優先度が高く、 Ember-Fastbootの出現で非常に広く考えられてきたことに言及するのが賢明だと思います。

私はいくつかのクライアントアプリケーションを使用高速ブート（大きな効果へ）を行うが、これは高レベルの技術の議論であるように私は彼が高速ブートの努力のためのチャンピオンになったとして@tomdaleに手を差し伸べる推薦します👍

@chriscinelliWordPressコミュニティプロジェクトとAutomattic社はまだ別のエンティティです。 AutomatticがSSRのためにどちらか一方に賛成することを主張したい場合、彼らはそうすることができますが、それでも私たちWordPressコミュニティがWordPressコアの選択フレームワークを検討する方法は変わりません。ノードを実行する必要があります。

とにかく、私はこのスレッドから退会しました。 このディスカッションをオフラインで続行したい場合は、私のメールアドレスが私のプロフィールにあります。

ノードの実行を必要とせず、実際にはできません。

SSR機能を差別化ポイントにしないでください。 ノードSSRが可能なフレームワークは、ノードSSRがまったくなくても機能します。これは単なる追加機能であり、要件でも依存関係でもありません。

Vue.jsに投票します

私はMITに行った上級アーチで、かなり頭がいいはずです。 私はこれを何年も行っており、あちこちで数人の開発者にインタビューしました。 Webは賢い人でいっぱいですが、VueのシンプルさがAngularの複雑さと同等であると考える人は誰でも、「複雑」を構成するものについての見方を失っています。 コンポーネントベースのJavascriptは、Googleが考案したように、完全に重要です。 それは途方もなく複雑です。 Vueはそうではありません。 VueはPHPと同じくらい簡単です。 「Vueは習得しやすい」というのは、VueがAngularよりもどれだけ簡単かを説明するのに近づいていないからです。 そして、ここに問題があります-Reactよりもはるかに簡単だと思います。

Reactは、平均的な人々にとって、簡単なものとGoogleレベルの間の境界線を歩いていました。 小さなお店の場合、Reactは小さなチームに挑戦するのに十分複雑だと思います。 Reactは、たとえばPHP / Wordpressよりも複雑です。 Reactを選択することで、Wordpress / Automatticは開発者がWordpress開発の世界に参入するための要件を引き上げました。 何百人もの人々が「反応は簡単だ」と「ウェブはよりスマートになっている」と叫ぶでしょうが、結局のところ、より複雑なものはさらに複雑です。

Vueに戻ることで、WPのルーツに近づき、WPコミュニティ全体の技術的負担が軽減されると謙虚に思います。 Webパラダイムはさておき、単純な方が良い場合もあります。

AngularとVueは2つの異なるものです

Vue、React、MarkoJS、Inferno、Preactなどは、ビューレイヤーのみをカバーするライブラリです。 Angularを含むそれらすべてには、宣言的な方法でHTMLを作成し、DOMを変更する方法があります。 Angularは、フロントエンド開発のための完全なフレームワークを提供したいと考えており、ビューレイヤー以外にも多くのものがあります。

Reactの構文は、このサンプルで最も古いものです。 Facebookは、非常に限られたプロトコルサーフェスで多くのこと（多分多すぎる）を実行する非常に複雑なライブラリをバインドするためにかなり良い仕事をしました。 Reactの使い方を知り、生産性を高めるために、React内のこの複雑さを知る必要はありません。 あなたは実際に基本を学び、半日で使い始めることができます。

このリストの他のすべてのライブラリはReactから学習しました。 彼らは構文を単純化し、Reactのパフォーマンスを改善し、同じことを行うために必要なJavascriptコードのサイズを減らし、その上にいくつかの機能を追加しようとしました。
Preactは、わずか3KbでReactと非常によく似たインターフェイスを維持するために素晴らしい仕事をしました。
InfernoとMarkoは、レンダリングパフォーマンスを大幅に最適化しました。
MarkoとVueは、定型コードを減らすために構文を大幅に簡素化しました。
Markoは、オプションのJade / Pugのような構文を追加して、コードをよりドライに保ち、非同期テンプレートを作成して、すべてをユーザーにとってシンプルで直感的に保つ機能を追加しました。

ただし、Angular以外のこれらすべてのライブラリでは、エンジニアがデータのフェッチやルーティングなどの戦略とメカニズムを考案する必要があります。Reduxとそのミドルウェアは、Gutembergがデータレイヤーを管理するために使用した一般的な方法の1つです。

Reactからの移行では、グーテンベルクは「変更するだけの別のもの」を必要としません。 Angularがユーザーに依存しないように努めたとしても、 https：//github.com/angular-redux/ng-reduxのようなライブラリが開発され、サポートされているにもかかわらず、ReduxおよびJavascript（vs Typescript）で使用することは自然な選択ではありません。 Javascript用が利用可能です。 さらにこれまでの投票を見ると、グーテンベルクのコミュニティはグーグルのフレームワークに強く反対しているようです。 したがって、おそらくAngularはオプションではありません。

PHPとこれらのJavascriptフレームワークは、まったく別の獣です。

PHPバックエンドとシングルページアプリフロントエンドを使用できますが、相乗効果はなく、類似点もほとんどありません。

Javascriptアプリはどれも、jQueryを散りばめたプレーンなPHPコードを書くことができるものよりも少なくとも1桁複雑です。 最新のJavascriptアプリはすべて、ステートフルネスと非同期フローという2つの大きな複雑さのモンスターに対処する必要がありasync / awaitによってのみ軽減されます。 アプリケーションが大きくなるにつれて、開発者のフローは遅くなります。 コードを変更した場合は、再コンパイルして再起動する必要があり、アプリは再度初期化を行う必要があります。 ホットリロードを実装するために大量のツールが構築されており、たとえ素晴らしいとしても、まだ完璧にはほど遠いです。
ビューレイヤーにどのライブラリを選択しても、余分な複雑さに対処する必要があります。

PHPでは、コードを変更し、ファイルを保存すると、ビルドやリロードなしでページをすぐにリロードできます。 すべてが機能します。 そして、より重要なPHPは完全にステートレスです。 ページをリロードするたびに、白紙の状態になります。 グローバル変数でさえ、リクエストごとにクリーンな状態になります（ただし、それらを= Pとして使用するのは良い言い訳にはなりません）。 私はここ数年PHPコードを書いていませんが、それでもそのシンプルさと開発者の経験が恋しいです。 CakePHP、Symphony、Laravelなどの最新のフレームワークを使用している場合、洗練されたエンジニアに歓迎されている他の言語やフレームワークと比較して、多くのことを見逃すことはありません。 例外は速度です。 PHPは、ランタイムパフォーマンスでそのシンプルさを実現しています。 ページをリロードするたびに、すべてのコードを再度実行する必要があります。 パフォーマンスはHHVMとPHP7で大幅に向上しましたが、一般的にはnode.jsで達成できるものからはほど遠いです。

結論

最近フロントエンドに使用したライブラリは関係ありません。 あなたがそれを愛していても、それはグーテンベルクにとって最良の選択であるという意味ではありません。
ただし、_グーテンベルクの主要な貢献者のほとんど_が1つの特定のライブラリを気に入っている可能性があるという事実は重要です。

最終的には：

彼の意志に反して確信している人はまだ同じ意見です

このスレッドには、さまざまな実行可能なライブラリの長所と短所に関するかなりの量の情報があると思います。

グーテンベルクとワードプレスの貢献者は、フロントエンドのファンから離れた「密室」で会うかもしれないので、放っておくべきです。
あなたの価値観、目標、制約を明確にし、結果を最大化するものに基づいてフレームワークを選択する時期かもしれません。

そして、あなたの決定でもう一度頑張ってください😃

私はVueに投票しました。 初心者にやさしく、頑丈です。 Vueを使い始めたとき、WordPressで開発を始めたときのような感覚がありました。 +💯

@ colorful-tonesは初心者向けだけでは十分ではありません！ すべてのプロジェクトにはライフサークルがあり、ほとんどの作業はメンテナンスの進行中です。

@ChrisCinelliいくつかの説明と意見：

Angularは、フロントエンド開発のための完全なフレームワークを提供したいと考えており、ビューレイヤー以外にも多くのものがあります。

Vueには、ルーティング、状態管理、テスト、リンティングなどの公式ライブラリに加えて、公式のCLIツールがあります。 これらはすべてvuejs組織の下にあり、コアメンバーによって維持され、Vue自体と同期されていますが、最良の部分は、それらを学習または使用する必要がないことです（したがって、「プログレッシブフレームワーク」哲学）。 Reactとは異なり、これは事実上、公式形式のフレームワークになります。 小さな駄洒落：これらすべては、Angularよりも習得が容易で、高速で軽量です。 ：スマイル：

Markoは、オプションのJade / Pugのような構文も追加しました

.vueファイルは、テンプレート、スクリプト、またはスタイルに任意のプリプロセッサを使用できます（たとえば、pug、typescript、coffescript、sass、stylus ...）。 プロジェクトに最適なものを使用してください！

エンジニアにデータをフェッチするための戦略とメカニズムを考え出すように要求する

これは単なる例ですが、データのフェッチを過剰に設計する必要はありません。

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

そこから、非常に単純なVueプラグインを作成して、コードをさらに簡潔にすることができます。

Vue自体は、常により優れた専用ライブラリが存在するため、このジョブに適したライブラリではありません（これが、たとえば、モーメントまたは別の優れたライブラリを代わりに使用することになるため、デフォルトで日付フィルターを提供しない理由でもあります） 。 また、いくつかのビジネスケースとユースケースの推奨パスとプラクティスを記載したクックブックを作成中です。

コードを変更した場合は、再コンパイルして再起動する必要があり、アプリは再度初期化を行う必要があります。

唯一の本当の違いはビルドステップです。これは、今日では公式のvue-cliやpoiなどのツールを使用して簡単にセットアップできます。 ファイルを保存すると、アプリはほぼ瞬時に更新できるようになります（ビルド時間は大規模なプロジェクトにも非常に適しています。また、Symfonyのようなフレームワークを使用して大規模なPHPアプリを開発した経験から、より苦痛になります）。 また、Hot Module Remplacement機能は、PHPの世界には存在しない大きなプラスであり（私の知る限り）、大規模なプロジェクトであっても、ブラウザーで新しいコードをほぼ瞬時にテストできるようにします（ Sassのコンパイルなどのコストのかかる操作ですが、PHPを使用する場合も同じ問題が発生します）。 ちなみに、VueはwebpackHMRを非常によくサポートして

余分な複雑さに対処する必要があります。

IMHO、いくつかの非常に人気のあるPHPフレームワークは、Vueのようないくつかのフロントエンドライブラリ/フレームワークよりも複雑で習得が難しいようです。 （反対も非常に真実です。）

グーテンベルクに似たブロックベースのエディターを構築した2年以上の経験に基づいて、適切なフレームワークを選択する際に対処すべき歯が生える懸念がいくつかあると思います。

• VueJS / Marko / Angularはドラッグアンドドロップとどのように統合されますか？ グーテンベルクのドラッグアンドドロップはどのように機能しますか？ ドラッグするとき、ゴースト要素のクローンを作成していますか、それとも既存の要素を使用していますか？ ドロップするとき、ブロックをドロップするためのプレースホルダーをどこに挿入できますか？

• VueJS / Marko / Angler（およびその仮想DOM）は、ContentEditablesおよびDOMRange＆Selection APIとどのように連携しますか？ この範囲と選択とのクロスブラウザの不一致は、ここで特定するのが非常に難しい場合があります。

• グーテンベルクエディタでコピー/カット/ペーストはどの程度機能しますか？ 複数のブロック間でテキストを選択して、切り取り/コピー/貼り付けを実行できますか？ 編集可能なコンテンツは個々のブロックに存在しますか、それともすべてマスターコンテンツ編集可能に含まれていますか？

• ブログ投稿にYouTubeプレーヤーやTwitterフィードを埋め込むなど、iframeの埋め込み可能要素を含むGutenbergブロックがある場合、このブロックを1つのDOM位置から別の位置に移動すると、iframeが再読み込みされます。 その他の注意点には、イベントをiframeからエディターに伝播して戻すことができないことが含まれます（エディター全体でブロック要素をドラッグしていて、カーソルがクロスサイトiframeにカーソルを合わせ、すべてが機能しなくなった場合を想像してください）。

すべてのフレームワークは仮想DOMの操作に優れていますが、WYSIWYGの多くの使用法は仮想DOMの外部にあります。 グーテンベルクの適切なフレームワークを評価する際に焦点を当てる領域は、フレームワークがDOMイベント処理をどれだけうまく処理できるか、そしてフレームワークで構築できない最先端の要件については、フレームワークの外で構築することがどれほど管理しやすいかということだと思います。に接続し直します。

見る

Wordpressは、新しい開発者が学ぶのに十分簡単であり、もう少し深く見ると非常に強力です。Vueについても同じことが言えます。
WPがこのフレームワークを使用してくれれば嬉しいです！

私の投票はVUEです！

今後非常に重要だと思うカスタムWebコンポーネントの構築に関して、このサイトでは、リストされている各フレームワークのスコアとテストパラメーターおよびスコアを提供しています。 それは有益なので、みんなにもう一度それを与えることをお勧めします：

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

VueJSへの私の投票。 素晴らしいフレームワーク、Laravelがそれを証明したと思います。

WP + Sage 9（roots.io）+ VueJS =>完璧なスタック

Preactにも問題がある可能性があります。

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

Preactを使用すると、reactを使用するよりも気分が悪くなる可能性があります。 Facebookは、あなたが訴訟を起こさなかったとしても、あなたがreactまたはpreactを使用することをブロックすることを許可されます。 この弁護士は、Preactが法廷で著作権を保持することはできず、反応を侵害していると見なされると考えているようです。

私が間違っているかどうか教えてください。 私は法律についてあまり知りませんが、助けになりたかったのです。

私はこれを読みました、そしてそれは私たちが決定した後に得た法的アドバイスに似ています
私たちのプロジェクトでReactを放棄します。 リスクが大きいというわけではありません。 むしろ私たち
ダウンストリームクライアントへのリスクを最小限に抑えたいと考えていました。 この弁護士はただ追加します
賛成意見。 代わりにPolymerとVueを使用していますが、どちらもうまく機能します
特定のユースケース向け。

2017年9月20日午後11時4分、「コーディングフレンド」 [email protected]は次のように書いています。

Preactにも問題がある可能性があります。

https://blog.cloudboost.io/3-points-to-consider-before-
migrating-away-from-react-because-of-facebooks-bsd-
特許ライセンス-b4a32562d268

Preactを使用すると、reactを使用するよりも気分が悪くなる可能性があります。 Facebookは
開始しなかった場合でも、reactまたはpreactの使用をブロックできます
訴訟。 この弁護士は、Preactは持ちこたえられないと思っているようです
それは法廷での著作権であり、反応を侵害していると見なされます。

私が間違っているかどうか教えてください。 私は法律についてあまり知りませんが、助けになりたかったのです。

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/WordPress/gutenberg/issues/2733#issuecomment-331045326 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AH2_iHc8Rg54IDHqe8GIyVTdSbcJbZ9Iks5skeBngaJpZM4PYie9
。

恐ろしいコードを見た後は二度とWPに触れないだろうと自分に誓いましたが、VueJSを使用している場合は、少しのValiumで再考するかもしれません。

免責事項：私は弁護士ではありません。 以下は厳密に私の意見です。

@ codingfriend1その記事には実用的なメリットがほとんどありません。

3つの仮定があります。

1. Facebookには、preactをカバーするのに十分な広さの特許があります。
2. 先例を使用している会社、たとえばABCが特許侵害でFBを訴える場合、FBは反応特許を使用してABCを訴えます。
3. Facebookの特許にはメリットがあります。

すべての仮定を詳しく見てみましょう。

1. Facebookには、preactをカバーするのに十分な広さの特許があります。

現在まで、これを証明するものはありません。 すべての特許は公開されていることに注意してください。 正確なソースコードは公の知識です。
さらに、Jason Miller（preactの作者）は、「Preactのいずれも特許を受けることができません。それはあまりにも明白です」と主張しています。

したがって、この仮定が当てはまる可能性は低いと言えます。 それは可能ですが、ありそうにありません。

1. プレアクトを使用している会社、たとえばABCが特許侵害でFBを訴える場合、FBは反応特許を使用してABCを訴えます。

これはFacebookの評判を破壊します。 FBは歯と爪と戦うことを期待していますが、reactの特許をそのように使用すると、FBは「パテントトロール」とラベル付けされます。

一方、FBには、法的手段を使用して戦うのに十分なリソースがあります。 したがって、この仮定もありそうもないと思います。

1. Facebookの特許にはメリットがあります。

はい、これは仮定であり、事実ではありません。

たまたま、「特許を持っている」と「有効な特許を持っている」というのは別物です。
私は、裁判所が特許を無効と判断したこの素晴らしい記事を読みました。

FBの特許が広すぎてメリットがない可能性は常にあります。
さて、Facebookに特許があれば、それは_いくらか_のメリットがあると思うでしょう。 それでも、論理的に言えば、それがpreactをカバーしている場合、それは広すぎてメリットがありません。 したがって、これは仮定が仮定1と直接矛盾しているということです。

Facebookが自分自身を守るために特許を使用していることを考えると、Facebookの特許は、強制力があるのではなく、広範でメリットがない可能性が高いです。

結論：

3つの仮定はすべてテストされていないことに注意してください。 それらすべてが真実であることが判明した場合、そしてこれは技術的には可能ですが、「ええ、preactを使用することは危険です」。

ただし、実際には、3つの仮定すべてが真になる可能性は低く、特に仮定1と3を合わせたものはそうです。

したがって、裁判所が別段の決定を下すまで、そしてそうでない限り、preact（および他のvdomライブラリ）を使用することは非常に安全だと思います。

ポイント1に関して、Facebookにはブラウザスクリプトでの効率的なイベント委任と呼ばれる特許があります。 これは基本的にjQueryのlive()関数です（後でjQuery APIのon()一部になります）。

ただし、仮定の妥当性に関係なく、WordPressがReactから離れる理由は、WordPressがFacebookに懸念を抱いているからではありいる発表の投稿から引用しハイライト）：

Facebookの条項は、実際には企業が採用できるよりも明確であり、Facebookはオープンソースの優れた貢献者の1つであると思います。 しかし、私たちには取り組むべき多くの問題があり、Facebookの特許条項が問題ないことを世界に納得させることは私たちが引き受けることではありません。

これに基づいて、WordPressを遠ざけたのは、特許がもたらす認識、混乱、および質問です。 以前のコメントで説明したように、同じ懸念がPreactにも当てはまると思います。

ポイント1に関して、Facebookには、ブラウザスクリプトでの効率的なイベント委任と呼ばれる特許があります。 これは基本的にjQueryのlive（）関数です（後でjQuery APIのon（）の一部になります）。

それは、彼らがイベント委任のアイデアを発明したということですか？！ 1995年にさかのぼる引用がいくつかありますが、それはどういう意味ですか？

@ChrisCinelliは、マルコの場合、「指数関数的成長の変曲点のように見える」とあなたが言ったことについて述べています。

これは単に規模の問題だと思います。 プロジェクトに5kまたは10kのGithubスターがある場合、たとえばHackernewsのトップページにあるリンクのように1回発生すると、1日に1,000個のスターが表示されます。これは、Markoの場合は最近の数の20％です。

Vueが持っている65kの星のスケールでは、それはそれほど目に見えません。 星の歴史のスクリプトがどのように機能するかによって、ある時点で変動がまったく表示されなくなり、最後まで直線になっていることがわかります。

このような状況はMarko自体に固有のものではなく、Infernoで発生したか、最近ではVueに触発されたマイクロフレームワークであるMoonJSで発生しました。 Reactの特許ドラマ全体のために最近星がいくつもあるので、Preactも同様の点にあるように思われるとさえ言えます。

あなたは私が話していることをあなたと同じ情報源からの次のグラフで観察することができます：

これらの人々が実際に開発でフレームワークを試し、本番環境で使用し、後で使用し続けるかどうかは、時が経てばわかります。 他のすべてのオープンソースライブラリと同様に、Markoがうまくいくことを願っています。

Vueに関しては、そうです、大きな変動のない安定した成長です。 現在の速度では、クリスマス前にReactを上回るはずです。 少なくともGithubでは。 :)

@aureliaはどうですか？
ウェブサイト： aurelia.io
@EisenbergEffectがこれを作成しました。

私にとって、それは素晴らしいフレームワークです！

1. 簡単な規則（カスタマイズ可能）
2. プレーンHTML
3. バニラJS
4. フレームワークの介入はありません！

使用したいライブラリ（jQuery、Vue.js、Preact、Ember、HyperHTMLなど）をプラグインして、Aureliaにその使用方法を教えることもできます。

それはとてもシンプルで標準に基づいているので、コミュニティのサポートも必要ありません。コミュニティのサポートが本当に重要だと思うなら、彼らもあなたをカバーしてくれます（1万以上の星で）。

@aureliaのリソース：

1. アウレリアのご紹介
2. Aureliaブログ
3. Aurelia Docs

ReactはMITの下で再ライセンスされているようです： https ：

決定は今逆転されるべきだと私は思う。

ホリーモリー！ Reactが復活しました。 WordPressはそれをしましたか？ わからない！ 午前3時です。とても興奮しています。 あなたはどうですか！

React、Jest、Flow、Immutable.jsの再ライセンス

来週は、オープンソースプロジェクトのReact、Jest、Flow、Immutable.jsをMITライセンスで再ライセンスする予定です。 ReactはWeb用のオープンソースソフトウェアの幅広いエコシステムの基盤であり、技術的でない理由で進歩を遅らせたくないため、これらのプロジェクトを再ライセンスしています。

この決定は、私たちのコミュニティに対する数週間の失望と不確実性の後に行われます。 BSD +特許ライセンスは、プロジェクトのユーザーにいくつかのメリットをもたらすと信じていますが、このコミュニティを断固として説得できなかったことを認めます。

ライセンスに関する不確実性をきっかけに、多くのチームがReactの代替ライブラリを選択するプロセスを経たことを知っています。 解約してすみません。 この変更を行ってこれらのチームを取り戻すことは期待していませんが、ドアを開いたままにしておきたいと思います。 この分野での友好的な協力と競争は私たち全員を前進させ、私たちは完全に参加したいと思っています。

この変化は当然、Facebookの他のオープンソースプロジェクトについて疑問を投げかけます。 私たちの人気のあるプロジェクトの多くは、今のところBSD +特許ライセンスを保持します。 これらのプロジェクトのライセンスも評価していますが、プロジェクトはそれぞれ異なり、代替のライセンスオプションはさまざまな要因によって異なります。

来週のReact16のリリースにライセンスアップデートが含まれます。 私たちはReact16に1年以上取り組んできましたが、大規模なユーザーインターフェイスを構築するすべての人に役立つ強力な機能のロックを解除するために、内部を完全に書き直しました。 Reactをどのように書き直したかについては、もうすぐ共有します。私たちの仕事が、Reactを使用しているかどうかに関係なく、あらゆる場所の開発者に刺激を与えることを願っています。 このライセンスに関する議論を後回しにして、私たちが最も気にかけていること、つまり優れた製品の出荷に戻ることを楽しみにしています。

私の意見では、MIT Licenseと、その背後にある最も活発で最大のオープンソースJSコミュニティでは、Reactが確実な選択です。

私の投票はReactで戻ってきました。 —人類への信仰が回復しました。

同様のコメントの代わりに👍で投票してください。

このReactlincencingの変更につながったものに参加してくれたWordpressに心から感謝します。

私はまだVueがより良い解決策になると思います。 Vueの長所の多くは今でも当てはまりますが、初心者の使いやすさとビルドステップを使用する必要がないことは、私の意見では、ワードプレス環境のキラー機能であることを指摘したいと思います。

質量用
確かに
vueJSの場合

また、最大のコミュニティ、強力な開発者チーム、安定した完全なエコシステムを備えたAngular2.0 +（AngularJSではない）を選択しました。

@CrazyBBer Angular 2/4である最大のコミュニティに関するデータはどこにありますか？ ブログ投稿に役立ちます。

とにかく、それは終わった、ReactはWordPressにとどまるためにここにいる、そしてVue愛好家としてさえ、Reactですでに書かれたコードの量を考えると、状況が変わる可能性のある最善の方法を見つける。

Redditの@ ahmadawais @ gustojsの人々は、MITが著作権のみをカバーしているため、Reactを使用するときに開発者が特許を取得できないという懸念を提起しましたが、これはまだ問題だと思います。

また、このステートメントは本当に私を悩ませます：

私たちは、このコミュニティを断固として説得できなかったことを認めます。

「私たちは間違っていませんでした。開発者は私たちを理解していませんでした」と効果的に言っています。

@ahmadawais ：Reactのライセンスがいかに気まぐれであるかという完璧な例を見てきましたが、最初はBSD + Patents license 、MITに切り替えたので、Vueを使用する方が良い選択だと思います。 近い将来、彼らがFBが所有するライセンス/特許に戻る可能性があることを誰が知っているか。そうすれば、誰もが干からびてしまうでしょう。 Vueは当初からMITであり、大企業主導のものよりもコミュニティ主導です。

さらに、@ atanas-angelov-devが言ったこと。

今は切り替える意味がありません。
Vueはより良い視点を提供していると思いますが、それはすべてを書き直すことを意味します

ああ！ 人々に来て、アウレリアにチャンスを与えてください！
これは、Angularjsチームのリード開発者の1人によって作成されました。
Vue.jsのように、小規模な採用から完全なフレームワークに移行できます

@azureポータルチームでさえ、もし彼らが今始めていたら、ノックアウトよりもAureliaを選んだだろうと言っていました！
そして、誰が知っていますか？！ 彼らは今少しずつアウレリアに移住しているのかもしれません。

少し始めてください、私はあなたがそれを好きになることを知っています！

Nirmal4G、
あなたの論文は非常に売れ行きが良く、ばかげているように聞こえます。
実際、フレームワーク全体には、投稿で直接リンクしているこの404ページと同じ欠陥があると思います。
http://aurelia.io/get-started.html

@ bovas85売れ行きはません。 彼らは私が彼らのフレームワークを使用していることさえ知りません。

@ cr101 / cc

表紙で本を判断しないでください

Aureliaについて知る前から、多くの一般的なフレームワークを使用していました。 そこにあるすべての基準のバランスをとることによってそれらを積み重ねる必要がある場合、私のアプリケーションでは（私はそれが大きなアプリケーションだと信じています）、Aureliaがリストの一番上にあり、次にVueが続きます。

フレームワーク全体には、投稿で直接リンクしているこの404ページと同じ欠陥があると思います。

私が投稿したすべてのリンクが404ページに移動することはありません。 httpをhttpsサイトにリダイレクトするのはgithubのせいです。 現在修正されています。 バグを参照してください。 バグのないフレームワークを教えてください、あえて。

他のフレームワークでは、冗長な（しかし有用な）抽象化がたくさんあるというだけです。 W3CコミュニティはAPIにパブリックフレームワークの設計を採用することは決してないので、そこにそれがあります。多くの抽象化があります。

すべてのフレームワークは下位互換性に重点を置いているため、上位互換性が失われますが、HTMLのW3CおよびECMAScript仕様に準拠している限り、Aureliaはそれを行いません。JSコードは正常に機能します。

_Aureliaがない場合は、Vueに固執してもかまいません。 それは次善の策です。_

_標準を再発明するための新しい方法を作成するのではなく、標準を受け入れるだけの問題です。_

@ Nirmal4Gはあなたの主張の証拠を提供するか、名前を避けてください。 特にLOCに関しては、VueがhyperHTMLよりも小さかったとは信じられません。 vueと比較してレイアウトとロジックをまとめてい

@WebReflectionあなたの馬を抱きしめてください、私はあなたがVueより悪いとは言いませんでした。 私があなたを怒らせたらごめんなさい。

私のアプリケーションは、あなたが投げることができるすべてのものを使用しています。 多くのフレームワークでプロトタイプを試しました。私が持っていた基準の1つはLOCでしたが、視覚的な観点からは、フレームワークのパフォーマンスを向上させることができると思う理由ではありませんが、名前に付いているのはデザインの選択です。

私はHyperHTMLを評価しました。パフォーマンスは素晴らしく、ポリフィルは素晴らしいものではありませんでしたが、残念ながら私の要件ではうまくいきませんでした。

すべてのフレームワークには1つの優れた点があります。私の願いは、すべてのフレームワークの中で最も優れたものを、神聖なデザインでつなぎ合わせることができれば、それは実現しないことです。 ですから、フレームワークが将来それ自体を改善できる場所とそうでない場所のバランスを見つける必要があります。

ReactがMITになると聞いて本当にうれしいです。
このプロジェクトにとても興奮しています。ReactとWPAPIが完全にサポートされるようになったら、久しぶりにWordPressを使い始めるのを楽しみにしています。 :)

待って、実際のReactライセンスがどうなるか見てみましょう。 MIT、またはMIT +特許..？ ;）

個人的にはReactが好きですが、Vueの方が生産性が高いと思います。 どちらにも満足しますが...

...コミュニティによるVueの強力なサポートを念頭に置いて、ライセンスに加えて、それを考慮に入れることをお勧めします。

VueはWordPressにとってより適切な選択のようです。

Facebookは、訴訟の罠のスイートから4つのアイテムを削除しました。 これらはすべてMITライセンスになっています：

• React
• 冗談
• フロー
• Immutable.js

一方、FacebookのカテゴリXライセンスは、引き続き以下に適用されます。

• リアクトネイティブ
• GraphQL
• 糸
• リレー
• Atom IDE
• そしておそらく彼らによって作られた「オープン」なものは何でも

私はまだVueで行くと言います。 長期的にはそれだけの価値があります。 とにかく、ReactはWordpressにとって意味がありませんでした。 これはPHPコミュニティに非常に深く組み込まれているため、Vueは常に最も賢明な選択のように見えました（さらに、Reactのように使用するのは苦痛ではありません）。

一方、FacebookのカテゴリXライセンスは、引き続き以下に適用されます。

リアクトネイティブ
GraphQL
糸
リレー
Atom IDE
そしておそらく彼らによって作られた「オープン」なものは何でも

@TheJaredWilcurt申し訳ありませんが、そのリストからヤーンを削除することをお勧めします。ヤーンにはそのような「FacebookカテゴリX」ライセンスがありません-> https://github.com/yarnpkg/yarn

@ atanas-angelov-dev

Redditの人々は、MITが著作権のみをカバーしているので、Reactを使用するときに開発者が特許を取得できないという懸念を提起しましたが、それでも問題があると思います。

MITは素晴らしいライセンスです。 jQueryもMITライセンスです。 私はあなたがそれを知っていることを望みます。

@vinayakkulkarni Reactライセンスがいかに気まぐれであるかという完璧な例を見てきましたが、最初はBSD +特許ライセンスを取得し、MITに切り替えたので、Vueを使用する方が良い選択だと思います。 近い将来、彼らがFBが所有するライセンス/特許に戻る可能性があることを誰が知っているか。そうすれば、誰もが干からびてしまうでしょう。 Vueは当初からMITであり、大企業主導のものよりもコミュニティ主導です。

それはそれがどのように機能するかではありません。 同様の質問に対するFacebookでのSamuelのコメントを読みました。 MITのライセンスを取得したら、フォークしてライセンスを変更することも、変更することもできません。 私は弁護士ではありません。

また、個人的には、Facebookはこれを誠実なジェスチャーとして行っており、人々をだますためではないと思います。 それは私にとって何かを意味します。

また、個人的には、Facebookはこれを誠実なジェスチャーとして行っており、人々をだますためではないと思います。 それは私にとって何かを意味します。

それはあまり論理的なステートメントではありません。 ネガティブなことをまったくしなかったグループに報酬を与えるのではなく、ネガティブなことをやめたので、あなたは1つのグループに報酬を与えています。 また、前述のように、他の同様のプロジェクトでも引き続きカテゴリXライセンスを使用していますが、これは私にとって誠実な兆候ではありません。

Vueには、より穏やかな学習と採用の曲線がたくさんあります。
そして、それが最初からWordPressの基本的な考え方でした。

@ahmadawais私は知っています-MITはライセンスを取得するのと同じくらい良いですが、これは大きな「しかし」です、Facebookは明らかにReactに関する特許を持っており、MITはコードをあらゆる目的に使用することを許可していますが、それでもFacebookを侵害する可能性があります特許（これらすべてを塩の岩で取る-IANAL）

そして、話題にとどまるために、私はWordPressをVueでも素晴らしいものにした多くのことを見ていると言わなければなりません-私の謙虚な意見では、Vueほど簡単に習得して使用できる適切なライブラリは他にありません。

Facebookは明らかにReactに関する特許を持っています

Reactのどの部分が特許を取得していると思いますか？ （Reactには特許がありません。最初に調査を行ってください）「明らかに」だけでなく、リンクを表示します。これはまったく役に立たない種類のコメントです。 お気に入りのライブラリを推奨したい場合は、FUDを広めるだけでなく、そのメリットを示して、正しい方法で実行してください。

Reactのいずれにも特許がないのに、なぜ元々がBSD +特許に移行したのですか？ Facebookは彼らが何であるか、または彼らが何でないかを言っていません。

なぜ2年間ライセンスをいじって、ポートフォリオの一部だけを変更するのか、一貫して変更しないと言って、「ただ対処するだけで、使用するかどうかは関係ありません」と言いました。

React Native、GraphQLなどを「新しい」ライセンスから除外するのはなぜですか？ Reactの将来のバージョンは何に切り替わりますか？ Facebookから2層ライセンスを取得している場合、誰が不満を言っているかによって、保証はありません...

ReactNativeコードの一部がReactに組み込まれた場合はどうなりますか。 GraphQLの実装がコードベースに組み込まれるとしたら、どこに立つのでしょうか。

Facebookによるこの行動は、答えるよりも多くの質問を提起しますが、それでもReactを使用するたびに真のオープンソースプロジェクトに対する潜在的なリスクがあることを意味します。

PHPの世界ですでに確立されている手荷物のないライブラリを採用するだけです-Vue。

@bjrmatos https://www.google.com/patents/US20170221242推測します！

Vueにさらに+1。 Facebookは、プロジェクト全体で2つのライセンスを使用しています。 それは良いことではありません。

@PericlesSouza Facebookのような会社が物事を改善し、Webを前進させるために行っている大きな努力を明らかに無視しているだけです

@Raymonfええと、基本的に、そこにある最新のフレームワークはすでにその特許に違反しているので（Vueを含む）、React、Vue、またはリンクで説明されている概念を実装する他のフレームワークを使用するかどうかに関係なく、誰もが同じ立場にあります（基本的にすべてのWebすでに他社が所有する2つか3つの特許に違反しているプロジェクトがあるので、現時点で企業がどのような特許を取得しているのかを知って驚かれることでしょう。 あなたが本当にそれについて心配しているなら、それはあなたがそのようにUIを更新するフレームワークを使うことができないことを意味します..したがって、この法的文脈では、より良いまたはより悪い代替手段はありません。

合意に達することができないので、この種の会話に再び参加したくないので、コメントをやめます。 Reactコミュニティは、MITへの変更に満足しています（元のライセンスのより大きな批判者でさえ）

決定におけるワードプレスチームへの幸運、React BSD +特許ライセンスに関する主要な問題は解決されました、それは今決定する彼らの仕事です。

そのため、Facebookは最近Reactのライセンスを変更しました。 それは、WordPressが引き続きReactを使用するか、それともデフォルトのフロントエンドフレームワークを変更することを意味しますか？

@bjrmatosこれはまったく真実ではありません

基本的に、そこにある現代のフレームワークは、すでにその特許に違反しています

たとえば、hyperHTMLは仮想DOMを使用せず、通常のコールバック呼び出し（非特許可能）と唯一の差分アルゴリズムを介してDOM API（非特許可能）を直接使用して、c hildNodes：beforeをc hildNodes：afterにモーフィングします。ノードのリストでは、レーベンシュタイン距離（特許取得不可）と最小量のスプライス操作（特許取得不可、私はそれを書きました、それはISCです）に基づいています。

この時点では、このスレッドは時代遅れで無意味だと思いますが、FUDを広め続ける必要性を理解していません。 あなたが選択をしてそれが好きなら、他のみんなに彼らが何か間違ったことをしている、またはあなたと同じ問題を抱えていると言う理由はありません。 私たちはこれに同意できればいいのにと思います。

@noncototientそれは百万ドルの質問ですね。 💯

議論が少し無意味になっているので、私はここで購読を解除しました。
多くの良い点が前進したと思います。この号を注意深く読んだすべての人にとって、それは学習体験でした。

私は同意します、これは今では無意味です。 このスレッドをロックすることをお勧めします（またはおそらくコントリビューターのみ）。 この問題については十分なフィードバックがあり、今では非建設的な議論につながるだけの段階に達しています。

この問題は解決されますか？
@WordPressは今新しいJavaScriptフレームワークに移行することに興味がないようです。 🤔

私にとって、私は個人的に@vuejsが好きです。 しかし、今は問題ではないようです。 😅

個人的には、Vueの方がずっと好きです。

私にとって、そして他の多くの人々にとって、それは決してライセンスについてではありませんでした。 これは、Reactから離れる言い訳にすぎませんでした。

マルコはめちゃくちゃパワフルで簡単です。 現在、50,000の製品を含む動的なWebストアの完全な書き直しを完了しており、非常に機能が豊富です。 このルートに行き、振り返らないでください。

Markoは優れていますが、 Plarkoがリリースされますが、ファイバーが追加されているため、_すべて_が冗長になります。

申し訳ありませんが、それがこのスレッドの残りの部分の方向です。

待って、実際のライセンスが発表されたとき、Facebookの2層ライセンスの意味を確認し、問題を徹底的に調査した後、WordPressチームがどのような決定を下すかを見てみましょう。

つまり、もともとはコミュニティが好むエンジンに関する入力を求めていました。 そして、それは人々が投稿しているもののようです、それでも何人かの人々は尋ねられたものと一致するコメントを送るために人々を飛び越えます。 ちょっと変だ。

ここで言及されているすべてのライブラリ/フレームワークは優れています。 一部のシナリオは、他のシナリオよりも適しています。 それぞれに支持者がいて、開発サイクルに応じて、パフォーマンス/機能の面でそれぞれが他を飛び越えています。

ほとんどのプロジェクトで行っているように、おそらく簡単な質問から始めます。

1. SPAフレームワークが必要ですか？

答えが「はい」の場合は、その理由を詳しく説明してください。 これにより、潜在的な候補者を評価するための一連の基準が得られます。 おそらくサーバー側のレンダリング、おそらくルーティングなどのために。

そうでない場合は、次の質問をします。

1. テンプレートエンジンが本当に必要なのは何ですか？

VanillaJSには地球上で最大のコミュニティがあり、ライセンスの問題はありません。 また、標準に準拠しています;）、ES6モジュールを使用すると、コア開発の適切な基盤が提供され、React、Vue、Preact、Aureliaなどの_template_エンジンを使用するためのプラグインサポートが提供される可能性があります。開発者の要求に応じて、今後数年間。

マットマレンウェッグは彼の応答を投稿しました...

Facebookが先週私が書いた特許条項を削除するというニュースを見て、私は驚き、興奮しています。 彼らは、React 16では、ライセンスは特許の追加なしで通常のMITになると発表しました。 Facebookがこの動きをしたことを称賛し、特許条項の使用がすべてのオープンソースプロジェクトで再検討されることを願っています。

以前のスタンスに基づいてReactから離れるという私たちの決定は、WordPressの世界で多くの興味深い議論を引き起こしました。 特にグーテンベルクでは、開発者がPreact、Polymer、Vueなどの選択したライブラリにグーテンベルクブロック（Gutenblocks）を記述できるアプローチがあり、Reactも公式にサポートされるオプションになる可能性があります。

これまでの議論に参加してくださった皆様、本当にありがとうございました。 ここのコメントやHackerNewsとRedditでの活発な議論と議論は、人々がもたらした情熱と、非常に多くの異なる視点について学ぶ機会にとって素晴らしいものでした。 Facebookが聞いていたのはさらに良かった。

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

@ahmadawais @m

以前のスタンスに基づいてReactから離れるという私たちの決定は、WordPressの世界で多くの興味深い議論を引き起こしました。 特にグーテンベルクでは、開発者がPreact、Polymer、Vueなどの選択したライブラリにグーテンベルクブロック（Gutenblocks）を記述できるアプローチがあり、Reactも公式にサポートされるオプションになる可能性があります。

その状況は誰にとっても勝利のように思えます。 待って、これが実際にどのように機能するかを見てみましょう。

今すぐこの問題を閉じてください..世界がどれほど気まぐれであるかを見るだけです..人々が彼らの言葉にとどまらないのを見るのは悲しいです。

[編集：不快な発言のため削除されました]

グーテンベルクとそれを使って反応することを学ぶという重い学習曲線を使わなければならないすべての人に幸運を祈ります。

平和。

👋私たちは皆、ここでたくさんの議論をしたと思います。 この問題について話したりコメントしたりするのに十分な配慮をしてくれたすべての人に感謝します。 私見では、現在私たちが持っているすべてのオプションは良いオプションのようです。

フレームワークにとらわれないAPIが得られれば、アプリで必要なJSフレームワークを使用できるようになります。 MITライセンスを使用すると、Reactは、優れた（読み取り互換性のある）オープンソースライセンスを持つ他のライブラリと同様に、コアで使用できる強力な立場にあります。

🎯特定のJavaScriptフレームワークを応援している場合、または1つ（コアチーム）を構築している場合は、WordPress開発者向けの実際の例を作成して、WordPressベースのアプリで好みのJavaScriptフレームワークを使用するというアイデアを試してみることをお勧めしますビルドします。

とりあえずこのチケットを閉じます。 そして、プラットフォームとしてもコミュニティとしても、WordPressの成功にもっと貢献したいと思っています。 ここのみんなから同じことを期待しています。 これは、WordPressソフトウェアを使用するすべての人にとってジェットコースターの冒険になると心から信じています。

数年前のように、ユーザー（インターネットサイトの約30％）が簡単に利用できるように、ソフトウェアを改善することになるかもしれません。 皆さんと同じように、ここでWordPressを応援しています！

乾杯！

Reactから離れるという決定が取り消されたかどうかは、Mattsのコメントからはあまり明確ではありません。

まず、Facebookが使用する実際のライセンスはまだ公開されていないため、それがすべて終わったふりをすることは、実際には賢明な動きではありません。

第二に、 Facebookがフォローしている2層ライセンスには対応していません。ReactはMITである可能性がありますが、React Nativeは+（非公開）特許になります。

では、両方で共有されているコンポーネントについてはどうでしょうか。

React内で使用されているReactNativeコードはどうですか？ ファイバーは2つの異なるライセンス間で共有されますか？ または、GraphQLコードがReactへの道を見つけますか？

WordPressがReactルートをたどり、関連するすべてのFacebookプロジェクトが異なるライセンスで公開された場合、Facebookは、Reactの一部の側面が実際にReact Native Patent GrantやFiberなどの対象であると判断した場合、どうなりますか？特許付与？

真剣に、これについて非常に慎重に考えてください。 大多数が使用することを好む、この問題がない代替案があるのに、なぜそれを危険にさらすのか-Vue。

適切に考え抜かれるのではなく、風によって変化するライセンス契約を信用しません。 Facebookの弁護士は気まぐれでこれを好転させることができた。

本物のオープンソースにこだわる。

@PericlesSouzaライセンスは、ここの人々がブログ投稿の説明から想像するものとまったく同じです。標準のMITライセンスであり、それ以上のものではありません。 ReactはReactNativeに依存しません。 両方で共有される部分は、React Nativeではなく、Reactプロジェクトに存在します。 ReactとそのFBが所有する依存関係は、チームが変更をコミットする時間があるとすぐにMITで利用できるようになります。 私たちは面白いビジネスを計画していません。

@sophiebits

あなたはFacebookで働いています。 Facebookに代わって話すことを許可された弁護士でない場合は、何を主張してもかまいません。 どんなコードを書いても構いません。 ごめんなさい。

「想像する」ライセンスは法廷で立ち上がらない。

たとえば、Facebookが特許付与を採用した理由、特許が何であったか（またはそうでなかったか）、または「IANAL」（私は弁護士ではない）と言わずに、なぜ今それを変更していると彼らが言うのかを明確に述べることができますか？

両方で共有されている部分は、React Nativeではなく、Reactプロジェクトに存在します

しかし、あなたはそれを法的保証で言うことができますか？ 番号？

ReactとそのFBが所有する依存関係は、チームが変更をコミットする時間があるとすぐにMITで利用できるようになります

ReactをMITで公開できるようにするためにどの部分が削除されていますか？ おそらくMITに準拠していないと思われる_非FB所有の依存関係_は、すでに使用していましたか？ Facebookの弁護士は、すべてが本当にMITに準拠していることを保証しますか？ Apache Software Foundationがこれを認定するのにどのくらい時間がかかりますか？
。

明らかに2層ライセンスを持つ2つのプロジェクト間でコードが共有されていることを強調するのは正しかったようです。

あなたは私の言葉をひねっています。 ReactとReactNativeの間で共有されるコードは、MITの下でライセンスされます。 あなたがファイバーと考えるものはすべてMITの下でライセンスされます。 Reactは、BSD +特許、またはあなたが軽蔑している他の特許付与の下でライセンスされているコードを含めたり、依存したりすることはありません。 Reactからパーツを削除するわけではありません。 私が知っているReactの唯一の非FB所有の依存関係は、同じくMITの下にあるobject-assignです。

私の言葉を法的な保証としてとらえることを提案しているのではありません。 ここでの私のコメント自体がReactのライセンスを変更するものではないことを私たちは知っています。 あなたは懐疑的になることを選ぶことができ、今私を信じる必要はありませんが、1日か2日で私がここで言っていることが真実であることがわかります。

@sophiebits

私はあなたの言葉をひねっていません-そして私はあなたがする仕事とここに従事するあなたの準備の両方を尊重します。

私が言っているのは、Facebookから、会社の権限のある役員によって、外部のオープンソース機関によって検証された法的コミットメントを取得しない限り、私たちはまだ私たちが始めたのと同じ立場にあるということです-実際の法的状況が何であるかは誰にもわかりませんあなたが述べることによって同意するように、です：

私の言葉を法的な保証としてとらえることを提案しているのではありません。 ここでの私のコメント自体がReactのライセンスを変更するものではないことを私たちは知っています。

そして：

あなたがファイバーと考えるものはすべてMITの下でライセンスされます。

私がファイバーと考えるかどうかは関係ありません。Facebookの弁護士と出願された特許がファイバーと定義するものに完全に依存します。

Reactとコードを共有しているのに、React Nativeが現在Reactとは異なるライセンスを取得することを意図しているのはなぜですか？ それはMITライセンスを無効にしませんか（駄洒落を許してください）？

また、GraphQLについて言及されていないことにも注意してください。 私が逃した他の何か？

Reactライセンスの大失敗の要点は、法的確実性の欠如です。

@sophiebits

私のポイントに応じてあなたの編集に注意します：

Reactは、BSD +特許、またはあなたが軽蔑している他の特許付与の下でライセンスされているコードを含めたり、依存したりすることはありません。 Reactからパーツを削除するわけではありません。 私が知っているReactの唯一の非FB所有の依存関係は、同じくMITの下にあるobject-assignです。

しかし、あなたはReactからパーツを削除し、「数日以内に」コードをチェックすると言いました。

ReactとそのFBが所有する依存関係は、チームが変更をコミットする時間があるとすぐにMITで利用できるようになります

そして、あなたはIANALを忘れました... :-)

ああ、実際にあなたはそれを長い形式で言った：

私の言葉を法的な保証としてとらえることを提案しているのではありません。 ここでの私のコメント自体がReactのライセンスを変更するものではないことを私たちは知っています。

もう一度：

Reactライセンスの大失敗の要点は、法的確実性の欠如です。

私はまだ法的な確実性がないという点に同意します。 しかし、私は個人的に、このスレッドがそのコースを実行したと信じています。 寄稿者としてのみマークを付け、実際のライセンスが公開されるまで待ってください。そうすれば、チームは評価を行うことができます。

今すぐ購読を解除します。

Reactをダンプしないでください。Facebookが決定を下しましたhttps://thenextweb.com/dd/2017/09/25/facebook-re-licenses-react-mit-license-developer-backlash/

@vinayakkulkarni何かに情熱を注いでいることは理解していますが、あなたのようにコメントする理由はありません。 パブリックスペース（GitHubのコメント）は、誰にとっても安全な場所である必要があります。 あなたのアナロジーは不快だったので、編集されました。 将来的には、すべての性別、すべてのタイプの人々がこのスペースを使用し、あなたの言うことが彼らを怒らせる可能性があると考えてください。

@sophiebitsは、このスレッドに参加していただきありがとうございます。ありがとうございます。

これは新しいスレッドのトピックかもしれませんが、残念ながらMITライセンス（標準のライセンスでさえ）は特許の「不確実性」の問題をクリアしておらず、WordPressの決定につながりました。

MITライセンスはあなたに特許取得済みのIPを使用する権利を与えますか？ 弁護士がそれについて言わなければならないことを読んでください： MITライセンス、行ごと

— Frans Bouma（@FransBouma） 2017年9月23日

MITは明らかにあなたに特許ライセンスを与えていません。 FacebookはReactに特許を持っており、現在のライセンスであなたに付与すると言っています。 現在のライセンスでは、少なくとも、ライセンスが何であれ付与され、どのような条件でそれらが取り消されるかを知っています。 MITを使用すると、ライセンスの付与も受けられません。

特許付与とは、関連する特許があることを意味します（またはそれは何を付与しますか？）。 誰も特許が何であるかさえ知らないことを除いて。 Facebookは、彼らに許可を与えたときでも、許可の削除を発表したときでも、教えてくれませんでした。

私が個人的に、またはWordPressチームがこれが何を意味すると思うかに関係なく、まだ存在しているように見えるのは、Reactに関する（まだリストされていない）Facebook特許の法的状況に関する混乱です。または-]]今日Facebookを訴えるとき、または新しいライセンスの後にReactを使用するだけで、違反について心配する必要はありません。

繰り返しになりますが、問題は不確実性であり、それが解決されていないことを私が示唆していることです。

念のため、このスレッドについて意見を述べた大多数は、Vueベースのソリューションを望んでいます。

これにはいくつかの理由がありますが、Vueにライセンスの混乱がないという事実に限定されません（これはFacebookの2層ライセンスポリシーのままです）。

1. Vueは、機能の島を使用して段階的に追加されるようにゼロから設計されており、コードベースを段階的に拡張できます。

2. さらに、オプションで、公式にサポートされている状態管理およびルーティングソリューションを提供します。

3. HTML用の複数のプロセッサをサポートし、開発者がテンプレート言語（HTML、JSX、Pugなど）またはレンダリング関数を選択できるようにします。

4. 単一ファイルコンポーネントとスコープ付きCSS（Stylus、SASS、SCSS、PostCSS、CSSコンポーネント）-可能な限り最も簡単な方法で。 文字通り、スコープ属性をコンポーネントのスタイル宣言に追加するだけで完了です。

5. 組み込みの計算プロパティ（メモ化あり）のサポート（つまり、MobXなどの依存関係なし）。

   6歳以上。 Reactよりも優れたパフォーマンス、はるかに低い学習曲線、PHPコミュニティでの高い採用、たとえばLaravelMixをチェックしてください-Laravel自体を使用せずにそれを使用できます。 または、 https： //unpkg.com/vueからVueを含めて、コーディングを開始し

Vueは単にWordPressに適しています。

反応：

76,364 Github Stars
571未解決の問題（！）
4325クローズドイシュー
178オープンプルリクエスト（！）
5,644件のクローズドプルリクエスト

Vue ：

68、246 Githubスター（軌道はクリスマスまでにReactを追い抜くことです）
62未解決の問題（バグ修正への応答性が大幅に向上し、要求された機能が追加されます）
5,629クローズされた問題
17オープンプルリクエスト
863クローズドプルリクエスト

@メリジー

MITは明らかにあなたに特許ライセンスを与えていません。 FacebookはReactに特許を持っており、現在のライセンスであなたに付与すると言っています。 現在のライセンスでは、少なくとも、ライセンスが何であれ付与され、どのような条件でそれらが取り消されるかを知っています。 MITを使用すると、ライセンスの付与も受けられません。

特許付与とは、関連する特許があることを意味します（またはそれは何を付与しますか？）。 Facebookは、彼らに許可を与えたときでも、許可の削除を発表したときでも、教えてくれませんでした。

そこには、大企業のオープンソースではないという問題があります。 最終的に、彼らの弁護士は、現在または将来のいずれかで、開発チームの善意が何であれ、それを却下します。

Facebookは+特許ライセンスを「何かまたは何か」の積極的な防御として組み立てました。今では、Reactにはまったく同じ「何かまたは何か」は実際には存在しないと信じるよう求められていますが、ReactNativeやGraphQLなどにはまだ存在します。

Automatticは、FacebookがReactに関するライセンスと意見を再び変更したときに、自分たちに負担をかけ、Reactを実行し、フォークし、独自に開発することを約束できますか？

私には、FacebookがWordPressの罠を仕掛けているように見えます。 世界のすべてのウェブサイトの25％が大漁です。

このスレッドをできるだけ早く_投稿者のみ_としてマークしてください。完全に登録を解除することなく、FUDや推測だけでなく、投稿者の結果を読むことをお勧めします。 ありがとうございました。

@WebReflection Wordpressの利害関係者は、コア開発者だけでなく、拡張コミュニティでもあります。

@PericlesSouzaがGithubのスターを引用しても、何の意味もありません。 そして、この問題がばかげた主張を投げかける人々によって急いでいるということは、事実を無視する必要があるという意味ではありません： https ：//npmcharts.com/compare/react、angular、@ angular / core 、ember-cli、vue

Vueは、レーダーのほんの一瞬に過ぎません。 驚異的な大多数はReactを使用しており、あなたの箇条書きにも同意しないでしょう。

@PericlesSouzaがGithubのスターを引用しても、何の意味もありません。 そして、この問題がばかげた主張を投げかける人々によって急いでいるということは、事実を無視する必要があるという意味ではありません： https ：//npmcharts.com/compare/react、angular、@ angular / core 、ember-cli、vue

Vueは、レーダーのほんの一瞬に過ぎません。 驚異的な大多数はReactを使用しており、あなたの箇条書きにも同意しないでしょう。

NPM統計？ 彼らが認めているのとまったく同じ統計が、ダウンロードのリクエストとして、最新バージョンを使用しているかどうか、またはすべての依存関係を介してチェックするためのすべてのリクエストをカウントすることを意味しますか？ （彼らは、人々が彼らの「月に数十億のパッケージ」の主張を笑ったとき、彼らのブログでこれを認めました）。

そのルートに行きたいのなら、誰もがjQueryを使用しています。

おそらく、その依存性歪みフィールドを持たないパッケージの図を試してみてください。

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

あなたが提示することを選んだものとは完全に異なる絵。

または、Webサイトの使用についてはどうですか。

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

これはBuiltWith統計によって裏付けられています：

ああ、そして私はこの写真をここに残しておきます-チームがコミュニティ自身に尋ねたときから。 軽蔑するのではなく、耳を傾けるべきです。

@PericlesSouza Next.jsやGatsbyJSのようなReact用の他の非常に人気のあるビルドツールがあるので、vue-cliをcreate-react-appと比較することは意味がありません。
多くのReact開発者は、CLIを使用せず、代わりにGutenbergやCalypsoと同じように独自のカスタムWebpackビルドスクリプトを使用しています。

現実には、ReactエコシステムはVueのものよりはるかに大きいです。 たとえば、Vue.jsのマテリアルUIには4,339の星があり、ReactのマテリアルUIには29,078の星があります。

jQueryののオーバーヘッドなしSelectセレクトと同様の機能を提供ネイティブの選択ボックスコンポーネント：ヴューを選択しながら、1348星を持っているの選択が反応8493星を持っています。

@ PericlesSouza 、 @ drcmda 、このすべてのデータはさまざまな方法で争うことができます

ソース： https ：//npmcharts.com/compare/vue-cli、create-react-app、@ angular / cli 、ember-cli

ソース： https ：//w3techs.com/technologies/comparison/js-angularjs、js-react、js-vuejs

出典： https ：//insights.stackoverflow.com/survey/2017#technology -frameworks-libraries-and-other-technologies

しかし、この会話は、どのフレームワークが最も使用されているかについてではなく、Wordpress環境全体にとってより良いものになるでしょう。

@ PericlesSouza @ willgmルールは両方に適用されます。 どちらもまったく同じ方法でカウントされ、公平ではないと主張するのはかなり不誠実です。 「いいね」や「スター」を数えるオプションのCLIや示唆に富むウェブサイトにしがみつくのは無駄です。 スタックオーバーフローでさえ非常に主観的であり、今日まで「builtwith ...」サイトについて聞いたことがありません。CLIの統計は、CLIを使用している人の数を反映しています（大多数は使用していません）。

同じ正確な状況下での実際の本番環境を反映した、最も明白で重要なソースからのデータは、私がそれを取得したくない1つの統計であり、現状を変えることはありません。

しかし、この会話は、どのフレームワークが最も使用されているかについてではなく、Wordpress環境全体にとってより良いものになるでしょう。

そして、私はあなたがどちらがより適しているかを知っていると思います。 Reactをnpmからオフにする1日あたり400.000人はすべて間違っていると思います。 Vueはそれ自体で競争することができ、問題追跡システムに突入する暴徒を実際に必要としません。

@ PericlesSouza @ willgmルールは両方に適用されます。 どちらもまったく同じ方法でカウントされ、公平ではないと主張するのはかなり不誠実です。 「いいね」や「スター」を数えるオプションのCLIや示唆に富むウェブサイトにしがみつくのは無駄です。

いいえ。 Reactには16,800の依存パッケージがあり、数字を歪めています。 NPMは、依存関係のチェック、ボット、ミラーなどの結果として、URLを呼び出すときにダウンロードとしてカウントされるのは200の結果コードだけであることを認めています。 ちなみに、Vueが非常に人気のある中国でのダウンロードのほとんどはミラーからのものであり、カウントされていないとも言われています。

言語の使用から判断すると、「しがみつく」、「示唆に富むWebサイト」、「無駄」など、このテーマについて実際の議論はありませんが、チームの要求に応じて、Vueを使用することの良い点を投稿しました（を参照）。上記）。

カウンティングスターズ-他の人はReactの成功を指摘するときにそれを行いますが、Vueの人気を示すために使用されるときにそれらの価値を非難しますか？ また、未解決の問題の数がはるかに多いこと（ 571 ）、およびReactで保留中の未解決のプルリクエストの数が非常に多いこと（ 178 ）についても言及していません。これは、バグ修正におけるVueコミュニティの応答性の高さと比較した場合です。機能の追加は、Reactの使用を提案する際の懸念の有効な原因です。

それは私をもたらします：

いいねを数える-まあ、それがこのスレッドの要点でした。チームが始めてコミュニティに尋ねたのですが-あなたは単に結果が気に入らないと思います。 ここに再びあり、非常に決定的なものです：

いいえ。 Reactには16,800の依存パッケージがあり、数字を歪めています。

@PericlesSouzaどのようにしてその結論に到達しますか。 これは、16.800パッケージがpackage.jsonの依存関係としてReactを宣言していることを意味します。 ボットではなく、中国ではなく、...パッケージ。 Vueのエコシステムとユーザーベースははるかに小さいということです。 なぜ私たちはこれを主張するのですか？ これは、使用統計に直接反映されます。 アップデート、実在の人物またはボット、両方のパッケージに適用されます。 ボットが何らかの理由で意図的にVueをスキップしていると想定しない限り。

各パッケージを同じように扱うトラッカーで1つのパッケージを選び出すことは、ほとんど意味がありません。 一方、いいねを数えるということは、XYがどこに投票するかを知っているコミュニティにすぎないということです。

@dcrmda

彼が意味するのは、Reactに依存するパッケージをインストールし、バージョンと依存関係をチェックするためにNPMにヒットするたびに、NPMはそれをパッケージのdownloadとしてカウントするということだと思います。ダウンロードしました。

それが彼の意味するところなら、彼はかなり正しいです。 NPMは、これを行うと明示的に述べています。 彼らは「方法論」を「意図的にナイーブ」と表現しています（ボットやミラーは、リクエストの目的を決定するメカニズムがないため、数字を歪める可能性があることにも言及しています。彼らはそれを数えるだけです）。 また、Reactには依存パッケージが多いため、この効果はより顕著になります。

多くの依存パッケージに関しては-はいReactは古いフレームワークであり、より多くの機能を備えており、それらを必要としています。 私はReactとVueの両方で開発していますが、コアがかなり完成していて、公式のルーターとVuexも依存性が低いという哲学に従っているため、Vueを使用すると追加のパッケージが少なくて済みます。 Vue自体はどのパッケージにも依存していません。Reactはいくつかのパッケージに依存しています。 彼らはこの点で異なるアプローチを持っています。

もう1つの例は、BootstrapとReactの統合パッケージを使用したり、styled-components、classnamesなどのライブラリを使用したりする傾向があることです。Vueでは、このようなプロジェクトも存在しますが、通常は必要ありません。 追加のライブラリや構成なしでコンポーネントスコープのCSSをすぐに使用できるため、Vueの操作がはるかに簡単であり、統合ライブラリ全体をインポートしてツリーを試すのではなく、必要に応じてCSSフレームワークとの独自の単純な統合を作成できます。 -私が必要としない75％を振り払う。

@PericlesSouzaは、「

名前付きスロット。標準のフォーム、入力、レイアウトなどの再利用可能なテンプレートコンポーネントを許可します。これは、Reactsでの子の使用よりも柔軟性があります。

非アクティブなコンポーネントを破棄せずにローカル状態を維持するオプション機能を備えた条件付きコンポーネント。

HTML要素 'は'文字列テンプレートのVueコンポーネント構文であり、無効なHTMLになるレンダリングされたHTML要素の巻き上げを防ぎます。

小道具を使用した一方向のデータフローですが、兄弟または親に通知または更新するための非常に単純化された「emit」および「eventbus」フローが追加されています。 これは、以下の間の相互通信に役立ちます。

特定のリージョンを制御する、ページ上の複数のVueインスタンス。 この手法は、動的ダッシュボードまたはプラグ可能なウィジェット、およびメモリ管理に役立ちます。

グローバルおよびローカルコンポーネントとカスタムディレクティブの登録。

計算されたプロパティに加えて、連鎖可能なフィルター。

上記はすべてコアVueライブラリの一部です。

Reactは素晴らしいフレームワークであり、私はそれを使用することを楽しんでいますが、個人的にはVueがこの提案されたユースケースにより適していると思います。

@mcquiggd

ええ、私は急いで、Vueの利点の完全なリストを作成する時間がありませんでした。

Reactがfbjsに依存していることに気付いたので、依存関係があるとすべては、あなたがそれに依存するプロジェクトのリストを見ると、特に心配することはなく、別のライセンスを持っています。

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

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

目的

Facebookが独自のJavaScriptを簡単に共有および使用できるようにするため。

注：_ここでコードを使用していて、Facebookプロジェクトでもない場合は、悪い時期に備えてください_。 _このライブラリは、ユースケースを念頭に置いて公開されており、必ずしも一般の人々が利用することを意図したものではありません。 機能のリクエストは、ニーズに合わない限り、おそらく受け付けません。

571未解決の問題（！）

今は338です。 （私はそれらをきれいにするのに数日を費やしました。）

過去数か月の間、Reactチームは、主に下位互換性のある新しいReact16リリースの準備に忙しかった。 これはこれまでで最大のリリースだったので、課題追跡システムへの応答としてではなかったので、申し訳ありません。 結局のところ、React16もこれらの問題の多くを解決しました。 :-)

残っている338の問題のほとんどは、機能のリクエストとディスカッションであることを指摘したいと思います。 検索バグラベルは、60件の問題についての私に与えます。 また、現時点でReactエコシステムがVueよりも大きいことを考えると、人々がより多くのエッジケースや不整合にぶつかり、より多くの議論を開始するのは当然のことです。 彼らはまた、Reactがより多くのブラウザーの不整合をポリフィルすることを期待しているため、バグの多くはそれらのカバレッジの欠如に関連しています。 さらに、ドキュメントは同じリポジトリに保存されているため、これらの問題の多くはドキュメントに関するものです。

これにより、Vueよりも発行数が多くなる傾向がある理由についての洞察が得られることを願っています。

Reactがfbjsに依存していることに気付いたので、依存関係があるとおっしゃっていたのは興味深いことです。 異なるライセンスのプロジェクト間でコードを共有しながら、Facebookの2層ライセンス戦略で、人々がReactを検討している場合に警鐘を鳴らすべき部分にいくつかの重点を追加しました。 特に、それに依存しているがライセンスが異なるプロジェクトのリストを見ると、心配です。

残念ながら、これは根拠のないFUDであり、終止符です。 それを広める動機はわかりませんが、

コメントの5日前に、 https：//github.com/facebook/fbjs/commit/c69904a511b900266935168223063dd8772dfc40でfbjsライセンスもMITに変更されていることがわかります。 数日前にリリースされたReact16リリースには、MIT以外のバイトが1つ含まれていません。

他のプロジェクトがfbjs依存しているが、ライセンスが異なるという事実は、アプリケーションコードがおそらくMITではなくVueに依存していることとは無関係であるのと同様に、まったく無関係です。

PS Vueは素晴らしいと思います、そして私はReactを誰にも押し付けたくありません。 しかし、私たちはこの議論が事実に基づいていることを確認したいと思います。 :-)私たちは常に批判を受け入れており、VueとReactの両方がお互いから学ぶことがあると確信しています。

これはすべてエキサイティングな話です。

私は尋ねなければなりません-なぜフレームワーク/ライブラリなのですか？ 前述のように、Webコンポーネント標準は、ReactJS、Vue、およびその他が提供するために構築されたものを提供しているようです（標準が存在しなかったため）。

Reduxのような状態ライブラリをWebコンポーネントで問題なく使用できます。 ルーティングライブラリと同様です。 SSRはWebコンポーネントで開発されたものほどではありませんが、そこで働く人々もいます。 Reactの最大の価値の一部は、その周りのさまざまなサポートライブラリです。これらは、プラットフォームを使用しても必ずしも失われるわけではありません。

XXXフレームワークはプラットフォームWebコンポーネントに対して何を提供しますか？

確かにエキサイティングな話...

これまでのところ、Reactの4番目のライセンス。

1. もともとApache2.0。 大丈夫だったはずですよね？ なにが問題だったの？
2. 次に、BSD +特許。 特許が何をするか、何をしないかを開示せずに存在します。
3. その後、グーグルを喜ばせるために、わずかな修正。 理由についての詳細なし。
4. 現在MITは、Reactの不特定のリファクタリングを備えていますが、React Native、GraphQLなどの直接関連するプロジェクトには対応してい

どうやらそれはすべて、まったく心配する必要はありません。

[Tammie Listerによって編集が削除されました：このような個人的なコールアウトは受け入れられません]

@PericlesSouza以前はライセンスが混乱していたので、信頼されるべきではないと主張することができます。 それがあなたの議論であるならば、それは有効です。 しかし、ライセンスは今混乱するべきではありません。

ReactはMITです。
その依存関係fbjsはMITです。
ReactとReactNativeが共有するコード（Reactリポジトリに存在し続けている）はMITです。
すべての依存関係を含むReactはMITです。
Reactを使用するためにReactアプリを作成する必要はありませんが、MITも必要です。
Reactを使用するためにRelayとgraphql-jsは必要ありませんが、それらもMITです。

新しいライセンスでReact16.0をリリースしました。 これを確認するのは簡単です。
また、MITライセンスが15.6.2のReact15.xの新しいバージョンもリリースしました。
Reactの将来のバージョンもすべてMITライセンスでリリースする予定です。

それに加えて、このスレッドの別のFacebook従業員は、React（MIT for 16？what for <16？17+？そのpackage.jsonを注意深く監視する）とReact Native共有コードを認めました。これにはリファクタリングが必要でした（その後、彼女/彼のコメントを編集します）私がそれを引用した後、そのステートメントを削除します）。

私はそのエンジニアです。 （彼女）

あなたはコメントhttps://github.com/WordPress/gutenberg/issues/2733#issuecommentその後、私は答えた、-331737418 https://github.com/WordPress/gutenberg/issues/2733#issuecomment -331738521を。

私の電子メールクライアントに記録された、2つのコメントの元の内容は次のとおりです。

現時点でのコンテンツは次のとおりです。

私がコメントした後、あなたはコメントを編集して、追加の質問を含めてはるかに長くしました。

ReactをMITで公開できるようにするためにどの部分が削除されていますか？

これはあなたの元のコメントにはありませんでした。 それで、あなたの編集に応えて、私はコメントを編集して追加しました：

Reactからパーツを削除するわけではありません。 私が知っているReactの唯一の非FB所有の依存関係は、同じくMITの下にあるobject-assignです。

次のコメントで私を呼び出すのが適切だとあなたは考えました。 編集で追加した質問に対処するために、コメントをあえて編集します。 ReactおよびReactNative共有コードに関する申し立てを削除または編集しませんでした。

-

私にガス灯を当てるのはやめてください。 疲れます。

@youknowriadこのスレッドをロックして

ここにいる他の誰かがまだライセンスについて合法的に懸念している場合は、遠慮なく私にDMを送ってください。明確にするために、最善を尽くします。

次のコメントで私を呼び出すのが適切だとあなたは考えました。 編集で追加した質問に対処するために、コメントをあえて編集します。 ReactおよびReactNative共有コードに関する申し立てを削除または編集しませんでした。

明らかに私はあなたの編集に答えました、それはあなたの問題ですか？

Facebook、React開発チーム、およびライセンスからのオープン性と一貫性だけで、ガスライティングは必要ありません。Reactsの4つのライセンスモデルが示すように、比較的短い寿命であり、あなたの（現在の）投稿は残念ながら不足しています。

ライセンスを簡単に脇に置いておく：繰り返しになりますが、Reactは、Webコンポーネントを超えて得られるものを今日提供していますか？ 両方でサポートライブラリの選択を引き続き使用すると仮定します（つまり、Redux）。

WordPressは、Webコンポーネントを使用して、さまざまなフロントエンドフレームワーク/ライブラリで使用できる要素よりも多くの要素を作成できます。 これにより、React、Vue、Angular、または使用しているフロントエンドを使用するエンドユーザーがWordPressコンポーネントを「ドロップイン」できるようになります。

@sophiebitsあなたの投稿のどのバージョンに今応答するかわからないので、私は待って、それが最終的にどうなるかを見ます。 これは、Reactの状況と非常によく似ています。

@ブライアン-マクブライド

あなたは良い点を述べています、そして私はそれがスレッドの早い段階で提起されたと信じています-「バニラジャバスクリプトを使用しないのはなぜですか」、標準ベース、完全準拠。

うーん。

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

私が言ったように、Reactを使用している場合は、バージョン管理に十分注意してください。

はい、ライセンス変更前から開いていたプルリクエストから、誤って間違ったヘッダーを持つ3つのファイルをコミットしました。 リリースされたバージョンにはありませんでした（1つは単体テストで、2つはWebサイトの一部でした）。

間違いが起こります。 見つかったときに修正し、CIにスクリプトを追加して、将来、偶発的な参照が追加されないことを確認しました。 あなたはそのコミットでそれを見ることができます。

無料のソフトウェアプロジェクトで考慮すべきもう1つのことは、FacebookがReactを使用することで恩恵を受けることです。

しかし、Facebookの価値観は、一般にフリーソフトウェア運動の価値観と一致していません。ユーザーの非倫理的な操作からネット中立性への攻撃（「無料の基本」）、データを削除できない、データ収集をブロックできない、検閲、壁に囲まれた庭など、あらゆるものが

[Facebook]は、兄が私に自分を殴らせて、「なぜ自分を殴るの？」と尋ねたときのようなものです。 それから彼は私の母にそれは彼のせいではなかったと言うでしょう。

私は長年Facebookを見てきたので、その会社をサポートしたくないという結論にますます近づいてきました。そのため、代替手段が存在する場合は常にFBソフトウェアを使用しません。

私はReactに関する本を読みましたが、プログラミングの観点からは見栄えがしますが、代替案も素晴らしく、Facebookをサポートする手荷物が付属していません。

フリーソフトウェアプロジェクトは、利用可能な場合は常に独立したフリーソフトウェアライブラリを好むべきだと思います。 Vue、Webコンポーネント、Ember、Mithrilなど、WordPressの優れた代替手段はたくさんあります。 VueはPHPコミュニティで大規模なサポートを提供しており、倫理的な問題は発生していないため、適切に機能するようです。 ダッシュボードだけの場合は、JavaScriptよりもさらに興味深いものであるElmを確認する価値があるかもしれません。

現時点で流行しているものやクールなものではなく、直接的または間接的に次世代に最もテクノロジーの自由を提供するものである必要があります。

考慮すべきちょうど別の考え...

敬意を表して会話をしながら意見を述べてくださった皆様、ありがとうございました。 私は@gaearon、@ブレイク・ニューマン、@sophiebitsにありがとう、と誰もが親切に質問に答える自分の時間を費やしたプロジェクトを表す特殊を追加したいとも思います。 あなたの知識は大歓迎です、そしていつでも歓迎します。

その後、会話は＃core-js SlackチャネルのJavaScriptミーティングに移りました。

そしてそれで、このスレッドはそのコースを実行しました。 問題をロックしていますが、上記の会場で会話を続けることをお勧めします。

このスレッドはいくつかの良い議論をもたらしましたが、そのいくつかは容認できない振る舞いを示し、編集されました。 https://wordpress.org/about/etiquette/はすべてのWordPressプロジェクトに適用され、違反や違反を犯したものは容認しないことを覚えておくことが重要です。 思いやりと敬意を持って会話に貢献してくださった皆様、ありがとうございました。