GitHubはここ数年、jQueryから離れて、そのインターフェイスを特にWeb Componentsで完全なWeb標準で実行するように取り組んできた。InfoQは、GitHubアプリケーションエンジニアのKristján Oddsson氏と詳細を話し合った。
コードベースがすでにコンポーネントのような動作に構造化されているため、Web Componentsを使用することを選択しました。それでも、GitHubモノリスのサイズが大きくなるにつれて、フロントエンドが管理できなくなる前に、より適切なカプセル化を実装する必要があることがわかりました。Web Componentsはその条件を満たします。
Oddsson氏が最近の記事で述べているように、GitHubの取り組みは、大規模な汎用コンポーネントと単一目的コンポーネントの両方のオープンソースのライブラリを構築するだけでなく、エンジニアがWeb Componentsを従うべきベストプラクティスとともにより簡単に作成するのに役立つ多数のツールの作成にもつながった。
GitHubで新しいWeb Componentを作成するための出発点はCatalystだ。これは、定型文を減らすためにTypeScriptとデコレータに依存し、状態の変化とユーザの操作を処理するために監視、リッスン、クエリのアプローチを採用するフレームワークだ。GitHubは、汎用のJavaScriptのリンターとともに使用されるWeb Componentsのリンターも作成した。
全体として、GitHubのエンジニアはこの変更によってもたらされた結果に満足しているとOddssonは言っている:
開発者はUIのテストを容易にし、開発者の信頼を高めるViewComponentのカプセル化を楽しんでいます。開発者は、Catalystを他のフレームワークやパラダイムへの大きな飛躍なしに「古いスタイル」のJavaScriptからの変更を歓迎することと感じています。
InfoQは、GitHubフロントエンドのパフォーマンスを向上させ、アクセスしやすく、操作しやすくすることに取り組んできたOddsson氏と話した。
InfoQ: Web Componentsへの移行を開始してから約3年です、それは価値のある決定だったと思いますか? Web Componentsはどのような利点をもたらしましたか?
Kristján Oddsson氏: はい。Webプラットフォームへの投資は、GitHubのチームにとって非常に価値があり、Web Componentsはその投資の中心的な部分でした。オープンソースである再利用可能な標準コンポーネントと、オープンソースでは使用されていない非常にアプリケーション固有のコンポーネントを構築できます。私たちがオープンソースにしているすべてのコンポーネントは、最低限の提供か、まったくスタイリングを提供しないという点で、ホワイトラベルのコンポーネントです。コンポーネントにスタイルを適用しないことで、コンテキストに基づいて、使用するアプリケーションでスタイルを設定できます。
Web Componentsは、Webプラットフォームの一部としてすべての主要な最新ブラウザーにも含まれています。これにより、ユーザに提供するJavaScriptが少なくなり、バンドルにフレームワークを含める場合よりもパフォーマンスが向上します。フロントエンドからjQueryフレームワークを削除することについては以前に書いたことがありますが、ここでも同じ概念が当てはまります。ユーザエクスペリエンスが損なわれないように、できるだけ少ないコードをブラウザに提供して実用的にしたいと考えています。
InfoQ: この移行を開始したとき、Web Componentsはかなり新しいテクノロジーでした。現在、Safariを除いて、ほとんどのブラウザで完全にサポートされています。克服しなければならなかった最大のつまずき (stumbling blocks) は何でしたか?
Oddsson氏: Web Componentsはテクノロジーのコレクションを指すため、「Web Componentsのサポート」がブラウザで何を含んでいるかは必ずしも明確ではありませんが、すべての目的と用途で、SafariはWeb Componentsをサポートしています。しばらく前から今も、Web ComponentsをSafariユーザに出荷しています。
Web Componentsで多くのつまずきが発生したことはないと思います。私たちは安定したペースで動き、時間をかけてテクノロジーを試す傾向があります。Web Componentsで発生したマイナーな問題については、エンジニアが一般的な落とし穴を回避できるようにESLintプラグインを組み立てました。さらに、Catalystと呼ばれるライブラリにいくつかのパターンと手法をエンコードしました。Catalystがいくつかの定型文を抽象化し、Web Componentsでいくつかの好ましい相互作用を提供することを意図しています。
InfoQ: Web ComponentsとReactをどのように比較しますか? ReactではなくWeb Componentsを選択した理由は何でしょうか?
Oddsson氏: 必ずしも比較したわけではありません。どちらも、発生する可能性のあるさまざまなエンジニアリングの問題を解決するのに理想的な優れたテクノロジであり、使用する基準に基づいて両方を評価する必要があります。
GitHubフロントエンドからjQueryを削除した方法に関するブログ投稿と、Web Componentsに関する最近のブログ投稿はどちらも、10年以内に移行する可能性のあるフレームワークに「いやいや受け入れる (buying into)」よりも、Webプラットフォームに依存したいと考えていることを示唆しています。
GitHubのエンジニアは、Web Componentsの提供を容易にすることを目的とした2つの新しい提案であるTemplate PartsとDeclarative Shadow DOMに特に熱心だ。