WordPressコアJavaScriptフレームワークの選択に関する議論は、オープンソースのコミュニティリーダーからの意見に続きます

公開: 2017-09-27

WordPressの＃core-js Slackチャンネルは、Andrew Duthieが率いる、活発で生産的な会議を今朝開催しました。議論は、特定のフレームワークの比較ではなく、WordPress用のJavaScriptを利用したインターフェースを構築する際にフレームワークが果たす役割に焦点を当てました。貢献者には、ReactおよびVueコミュニティのコア開発者とリーダー、Chromeエンジニア、およびWordPressコミュニティ外のその他の関係者が参加しました。

「このチャットでは、コア機能を構築する際の要件の特定、プラグインやテーマの作成者との重複、フレームワークのロックインを減らすためのパターンに主に焦点を当てます」とDuthie氏は述べています。「理想的には、これは単に特定のフレームワークのメリットを真空で議論するよりも高いレベルであり、プロジェクト間で協力して、将来の解約に柔軟性と回復力を提供するWordPressの道を切り開く機会と見なされるべきです。」

Duthieは、WordPress開発者のワークフローでフレームワークが果たすべき役割を尋ねることから始め、フレームワークの貢献者に、拡張可能なインターフェイスの推奨事項についての見解を示すように求めました。この質問は、Webコンポーネントのサポート、Gutenbergのフレームワークに依存しないブロックの相互運用性、およびこれがWordPressのプラグインエコシステムにどのように影響するかなどのトピックについて検討する機会を出席者に提供しました。

「ステートフルアプリの構築の複雑さの一部を強化するためにコア（この場合はグーテンベルク）が使用するものはすべて、プラグイン開発のデファクトスタンダードになるという考えには少し同意しません」とグーテンベルクのエンジニアであるマティアスベンチュラ氏は述べています。「ここでの実際のフレームワークは、一般的に、WordPressが公開するものとAPIになります。」

Gutenblockを構築するためのフレームワークにとらわれないアプローチにより、コアが構築することを決定したライブラリは、プラグイン開発者の事実上の標準になる必要はありませんが、Gutenbergチーム外の多くは、実際には必然的にそのようになると信じています。この決定を待っているエンジニアのチーム全体が、WordPressが賭けているフレームワークを採用することを約束しています。

「フレームワークに関するWPの決定が下流の開発者にどのように影響するかについての見通しを提供するために、私はボストン大学の開発者です。グーテンベルクが完全に不可知論的なAPIを持っている場合でも、WPが決定するフレームワークに焦点を当てる計画です」とAdamPieniazek氏は述べています。。「私たちは主にWPショップであり（約1,000サイトのWPインストールがほとんど/多くのパブリックWebプレゼンスを強化します）、WPの上に巨大なカスタマイズを作成することになり、バックグラウンドで実際に何が起こっているかを確認するためにコアに飛び込む必要があります。私は個人的にReactよりもVueが好きですが、WPがReactを決定した場合、BUは、APIを超えてピーク/デバッグする必要がある場合に備えてReactの専門知識を構築することに焦点を当てます。 Vueも使用しないという意味ではありませんが、それが私たちの主な焦点になることはありません。」

Pieniazekのフィードバックは、GravityFormsの共同創設者であるCarlHancockのフィードバックと同じです。彼のチームは、WordPressが選択したライブラリを採用する準備ができていると述べています。

「人々は、虹や蝶にもかかわらず、プラグイン/テーマ開発者が好きなものを使用できるように抽象化レイヤーを作成することに関連していると主張しているにもかかわらず、ほとんどの場合コアが使用するものを採用することになります」とハンコックは＃core-で述べました今週初めのjsチャンネル。

WordPressコミュニティの外部からの多くの参加者は、フレームワークにとらわれないアプローチに同意しているようであり、WordPressを使用するすべての開発者に単一のフレームワークを強制することを熱望している人はいませんでした。残りの懸念は、これが実際にどのように機能するか、そしてそれが開発者をフレームワークの上にフレームワークを使用するという混乱した立場に置くかどうかです。

「グーテンベルク自体が構築するプラットフォームになるため、フレームワークを使用してコアを構築する場合が最適な分離レベルになりますが、ブロックビルダーにAPIとして公開されません」とAMPエンジニアのPaulBakaus氏は述べています。「これにより、必要に応じて基盤となる基盤を交換することができます。」

グーテンベルクのエンジニアであるリアドベンゲラは、チームが話し合っているアプローチを要約しました。

私たちが伝えようとしていることは、次のようなものだと思います。
– WordPressCoreはこのXフレームワークを内部で使用します
–使いたいなら、いいと思います
–他のものを使用したい場合は、Coreが選択したフレームワークを使用するのと同じくらい簡単に使用できます

ベンゲラ氏はまた、グーテンベルクの目標の1つは、「将来的にWordPressのUIを拡張する方法の基礎を築くこと」だとも述べています。出荷されると、チームはwp-adminの他の部分に目を向け、同じ方法でそれらを構築する可能性があります。

「WPのUIのすべての部分が、単純なデータダウン、イベントアップAPI、またはWCの期待など、標準のインターフェイスを介して拡張できる場合、これにより、コアに使用するフレームワークの問題が明確に分離されると思います。「vs.」拡張機能の開発に使用するフレームワーク」とVue.jsの作成者であるEvanYou氏は述べています。

ReactがWordPressの主要なフレームワークになることについての考えを尋ねられたとき、ReactのメンテナーであるDan Aブロモvは、WordPressがライブラリを採用することを躊躇していました。彼の回答は、グーテンベルクと将来のWPインターフェースのオーバーホールを拡張するためのフレームワークにとらわれないアプローチの必要性を強調しました。

「私はWordPressをよく知らないので、それがユースケースに最適かどうかを判断するのは難しいです」とAbramov氏は述べています。「一般的に、高度にインタラクティブなUIにはReactを使用しており、アプリのサイズに合わせて適切に拡張できることがわかりました。また、技術的な質問にも喜んでお答えします。しかし、一般的には、テンプレートと表現力などについて強い意見があると思います。すべての人にReactを強制するのが最善の方法だとは思いません。」

「私も同じように感じます」とエヴァン・ユーは言いました。「どのフレームワークに関係なく、すべての人に単一のフレームワークを強制することは、そのフレームワークに参加していない開発者のグループを疎外し、より大きな長期的な安定性のリスクを課すため、IMOは良い考えではありません。」

アブラモフ氏はまた、フレームワークの選択というテーマについて、人々はすでに「非常に苦くて分裂的」であると述べました。彼はまた、会議の前に同様の感情をツイートしました。

ディスカッションスレッド（WordPressなど）を読むと、すべてのチームが他のチームに対して敵対的であると人々が認識しているという感覚があります。それは誤りです。
—ダン（@dan_abramov）2017年9月26日

庭の手入れのように考えてください。どういたしまして。他の庭園も素晴らしいです
—ダン（@dan_abramov）2017年9月26日

「コアに使用するフレームワークと拡張機能にコミュニティ開発者が使用するフレームワークを分離することが重要（そして技術的に実現可能）だと思います」とEvanYou氏は述べています。

「はい、プラグインの作成者に公開するものについては、私たちが公開するAPI /インターフェースが、実装に必要なUIとインタラクションを構築するのに十分な柔軟性（かつ簡単）である限り、ここでの目標はありません。アンドリュー・デュシーは言った。

GutenblocksのWebコンポーネントの相互運用性をサポートするというトピックも、会議中の議論の一部でした。

「現時点では、実際のフレームワークのほとんどよりも強力ではありませんが、W3C標準になる可能性が高く、確実に定着して進化するでしょう」とFelixArntz氏は述べています。「さらに、ブラウザのサポートが完全に利用できるようになると、その上に構築された実際のフレームワークによって実装する機能が少なくなります。」

Polymer.jsの代表であるJustinFagnaniは、「それほど強力ではない」ことに同意せず、WebコンポーネントはすでにW3C標準であると述べました。

「WPはまた、あらゆる場所でネイティブにWebコンポーネントのサポートを推進するのに役立つ独自の立場にあると思います」とEventEspressoのコア開発者であるDarrenEthier氏は述べています。「現在、ほとんどすべてのフレームワークがWebコンポーネント仕様と連携する機能を備えています。それは適切な実装の問題です。」

何人かの参加者は、相互運用性を促進する方法でカスタム要素の通信に関する一般的なJSフレームワークの進捗状況を表示するサイトであるcustom-elements-everywhere.comを参照しました。 Matias Venturaは、ReactとVueのコア開発者に、現時点でWebコンポーネント（およびその将来）が各フレームワークにどのように適合するかを尋ねました。

「Reactでは、いくつかのWebコンポーネントのサポートがありますが、過去にユースケースがスリムに見えたため、特にWebコンポーネントの追加が、スタック全体を制御しますが、それでもある程度のサポートはあります。現在または将来、さらに追加することを楽しみにしています」とSophieAlpert氏は述べています。

「大まかに言えば、React / Vueのようなフレームワークは、Webコンポーネントでは実際には対処されていないものを提供すると思います。つまり、状態の変化に反応する効率的で宣言型のDOM更新です」とEvanYou氏は述べています。「これが、ポリマーがトイレの上に存在する理由でもあります。私は常に、相互運用インターフェイスとしてのWCの価値を認めてきました。」

全体として、会議の参加者は、WordPressの貢献者がフレームワークの選択プロセスで最善の方法を見つけるのを支援するために、敬意を持って協力し、専門知識を提供することに熱心でした。議論は来週の会議で継続され、おそらく会議を要約する次のMake / Core投稿のコメントで行われます。