分離されたアーキテクチャを検討しているDrupalコミュニティ
公開: 2015-12-12
今週初め、Drupalの作成者兼プロジェクトリーダーであるDries Buytaertは、 Drupalをクライアント側のフレームワークと切り離す必要があるというタイトルの投稿で、Drupalアーキテクチャの将来についてのディスカッションをブログで開始しました。
Buytaertは、Facebookのニュースフィード、Gmailの受信トレイ、Twitterのライブストリームとのやり取りを考えると、ユーザーはWebサイトからアプリケーションのようなエクスペリエンスを期待するようになったと主張しています。
「Drupalの管理インターフェースとDrupalサイトの多くは、同様にシームレスで瞬時のユーザーエクスペリエンスの恩恵を受けることができます」とBuytaert氏は述べています。 「Drupalのプロジェクトリーダーとして、私は自分自身に問いかけます。私たちのコミュニティは、どのようにして、豊かなユーザーエクスペリエンスの構築を開始できるようになり、奨励されていると感じることができるでしょうか？」
Drupalをクライアント側のフレームワークと切り離すための議論は興味深い時期に来ています。MattMullenwegのStateof the Wordは、JavaScriptをWordPressとWebの未来として予告しているからです。 彼の閉会の辞は、開発者がJavaScriptを学び、将来に向けてWordPressを利用したアプリの構築を開始することを奨励しました。
Buytaertの投稿へのコメント投稿者は、AutomatticによるCalypsoのリリースとの関連を示しています。
この投稿は、少なくとも部分的にはWordPressによるCalypsoの発表に対する反応のようです。 特にWordPressがDrupalの真の競争相手ではないことを何度も何度も話し合った場合は、他のCMSが行っていることに急いで対応するのではなく、Drupalの将来に適した決定を下すことに集中できることを願っています。
Buytaertは、Drupalに対する彼の考察は独立して動機付けられたと主張しており、バックエンドとフロントエンドの分離について書いたのはこれが初めてではありません。
「WordPressによるカリプソの発表については、カリプソが発表される前に実際にこのブログ投稿を書き始めました」と彼は言いました。 「私の立場がカリプソの影響を受けたとは思わない。」
Buytaertは、ユーザーがWebサイトでの対話のベースラインとして、アプリケーションのようなエクスペリエンスを当然のことと見なすようになったという事実をこの議論の前に置きました。 Web全体がこの方向に進んでおり、DrupalやWordPressなどのCMSは、関連性を維持したい場合、この山に登ることを余儀なくされています。 どちらのプロジェクトも、ユーザーの期待に応えようとして、背後から取り組んでいます。
フレームワークの標準化への挑戦
多くの点で、Buytaertの投稿に関する議論は、WordPressの方向性、特に特定のフレームワークで標準化するための考慮事項に関連しています。
Buytaertは、Drupalの管理者とエンドユーザーエクスペリエンスの段階的な分離を提唱すると同時に、完全に分離されたエクスペリエンスをプラットフォーム上に構築できるようにします。 彼は、これを行うための最良の方法は、「フル機能のMV *フレームワーク（Angular、Ember、Backbone、Knockoutなど）またはコンポーネントベースのビューライブラリ（React、Vue、Riotなど）で正式に標準化することです。 」
彼はフロントエンド開発者ではないため、Buytaertは、プログレッシブデカップリングに最適なフレームワークについてDrupalコミュニティからの意見を求めています。 彼はまた、特定のフレームワークを標準化することが長期的にはお勧めできない理由を認めています。
潜在的なメリットはありますが、単一のクライアント側フレームワークを採用しない理由もあります。 新しいフロントエンドフレームワークは、持続不可能なペースのように感じられるペースで作成されています。 9か月ごとに、ブロックに新しい子供がいます。 Drupalのような大規模なプロジェクトでは、その寿命が保証されていない場合、単一のテクノロジーを採用することは困難です。
それにもかかわらず、Buytaertは、フレームワークの慎重な選択と定期的な再評価により、これらの欠点を克服できると考えています。
WordPress開発者にJavaScriptを学ぶように勧めたとき、Matt Mullenwegは単一のフレームワークを識別せず、開いたままにしました。 AutomatticのCalypsoはReactに基づいて構築されているため、初期のお気に入りのようです。
WordPressコアがCalypso（またはCalypsoのような代替）の背後にあるテクノロジーを採用してより良いパブリッシングエクスペリエンスを提供することになった場合、コアはフレームワーク/ライブラリを標準化するのでしょうか、それとも拡張機能開発者が任意のフレームワークを使用できるようにし、奨励し続けるのでしょうか？
あるコメント提供者は、Drupalがフレームワークを選択する際の潜在的な問題を指摘しています。
分離されたDrupalアプローチを使用するエンタープライズプロジェクトはすでにたくさんあり、当然、それらは多くの異なるフレームワークを使用しますが、私が最も使用しているのはReactです。 実際、私が現在取り組んでいるプロジェクトでは、組織はReactに全面的に取り組んでいます。 たとえば、DrupalがAngularに落ち着いた場合、他のフレームワークに多額の投資を行っている組織にどのような影響がありますか？ それがどのように機能するかを完全には理解していないかもしれませんが、単一のフレームワークの選択は、SVの方法ではなく、悪い方法で破壊的で破壊的である可能性があるようです。
分離されたアーキテクチャをより簡単にすることは素晴らしいことであり、Drupalが行うことであるはずですが、使用されるFEフレームワークにとらわれない方法でそうする必要があります。
Buytaertは、Drupalコアを使用してクライアント側フレームワークを出荷する代わりに、フレームワークを推奨するが同梱しない、またはコアに含めるが開発者が選択した別のフレームワークに簡単に置き換えるなど、いくつかの代替案を特定します。
彼の投稿とそれに続くコメントは、Drupal開発の未来を形作るのに役立つ活発で思慮深い議論の始まりです。 今日、Buytaertは、プログレッシブデカップリングの実用バージョンのプロトタイプの概要を説明する提案を求めています。
プログレッシブデカップリングの実用バージョンのプロトタイプを作成する方法に関する提案を読むことに興味があります：https：//t.co/tJxT66cKoy #drupal
— Dries Buytaert（@Dries）2015年12月11日
WordPressとDrupalは現在、ユーザーにより多くのアプリケーションのようなエクスペリエンスを提供するための技術的飛躍を遂げるための闘いに取り組んでいます。 Drupalのアーキテクチャの分離を取り巻く会話は、WordPress開発者がフォローして学ぶための重要な会話です。