世界には、Unreal Engine、Unity Engine、Godot Engine、Cry Engine など、多くのゲーム エンジンがあります。

これらのゲーム エンジンの共通点は何ですか?カスタマイズ性。ゲームごとに要件は異なり、目的を達成するには特定の機能が必要です。考えられるすべての機能を 1 つのプログラムで提供することは難しいため、多くのエンジンでは開発者がソース コードを変更して独自のカスタム機能を構築できます。カスタマイズはこれらのエンジンの重要な部分です。

さて、フロントエンド開発に戻りましょう。 React は、この分野で最も人気のあるフレームワークの 1 つです。しかし、ゲーム開発でエンジンを変更するのが一般的であるのと同じように、フロントエンド開発でも React の内部ソース コードを変更するのは一般的なのでしょうか?この単純な質問は、私たちが実際に追求していることについて多くのことを明らかにし、最新のフロントエンド開発と他の分野の方向性の違いを浮き彫りにします。

React は変更がほぼ不可能なフレームワークです。 React はそのまま使用することをお勧めします。開発者が内部アーキテクチャやレンダリング パイプラインをカスタマイズすることを目的としたものではありません。したがって、React を使用するということは、React の構造の範囲内ですべての要件を解決する必要があることを意味します。しかし、世界には多様な要件が溢れており、そのすべてを React のフレームワーク内で解決できるわけではありません。

「無料のランチなどというものはありません。」
「すべてを実行できるツールはありません。」

React は単なる開発ツールの 1 つであり、限界があります。

開発者が React を使用する主な理由は生産性です。 React は、「Web 開発において DOM コンポーネントをより効率的に開発するにはどうすればよいか?」という疑問から作成されました。 React のアプローチの中心となるのは DOM です。自動化された機能が一般にカスタマイズの欠如を意味するのと同じように、彼らが語る「生産性」とは、「仮想 DOM を介してブラウザーと緊密に結合されたレンダリング ループを変更できない」ことを意味することがよくあります。

React の最初の大きな問題は DOM です。すべてが DOM を中心に展開するわけではありませんし、すべてのプログラムが DOM だけを中心に動作するわけでもありません。しかし、React は DOM をその哲学の中核に据えています。各コンポーネントが「HTML 要素のようなもの」を返す JSX 構文は、この考え方を明確に反映しています。

2 番目の問題は仮想 DOM です。仮想 DOM の仕組みは次のとおりです:

• DOM は本質的に遅いです。
• これを軽減するために、React ではより高速な内部ロジックが導入されています。
• このロジックは、仮想 DOM として知られる実際の DOM ツリーの形状をコピーするオブジェクトを作成します。レンダリングが発生するたびに、React はこの仮想 DOM を使用して変更を検出し、それらの部分のみを更新します。
• このシステムを実装するには、DOM 更新は常にルート DOM 要素を経由する必要があります。
• 仮想 DOM は React の内部操作とシームレスに連携します。

問題は、そもそもなぜ HPSE がそのようなシステムを採用したのかということです。このレンダリング手法がさまざまな HPSE 要件に対応できないという懸念に加えて、より大きな懸念は、このコンテキストでの実際の実用性が欠如していることです。

HPSE では、DOM コンポーネントをクラス レベルで管理できます。インスタンスが作成されると、その最上位の div DOM 参照がメンバー変数として保存されます。インスタンスのプライベート メソッドは、DOM 参照を直接操作することも、querySelector() を使用してアクセスすることもできます。ほとんどの場合、これは DOM ツリー全体を比較するよりも高速です。

仮想 DOM の使用は変更を識別するための単なる方法ですが、変更がすでにインスタンス内の内部に保存されている場合、それらを再度検索するのは冗長です。 DOM 要素が更新されると、ブラウザは引き続き ReFlow と RePaint をトリガーするため、その後のパフォーマンスに違いはありません。

究極の問題は、React の「内部運用」にあります。これらの内部操作は正確には何ですか?詳細なドキュメントや情報が不足しており、ほとんどのフロントエンド開発者もそれらを完全に理解していません。ブラウザ クライアントはすでにブラウザ自体の抽象化層内で動作しているため、さまざまな課題に対して脆弱になっています。 React の不透明で変更不可能な内部プロセスは、この脆弱性を悪化させるだけです。

React のコンポーネントへの変更は仮想 DOM を経由する必要があり、仮想 DOM は特定の優先順位ルールに従うファイバー アーキテクチャによって管理されます。ただし、HPSE のリアルタイム パフォーマンスや正確なタイミング要求を満たすために React の内部関数をカスタマイズする方法に関するドキュメントはほとんどありません。カスタマイズできないエンジンを使って AAA ゲームを開発しているような気分です。

「なぜわざわざ？」

それは常に出てくる質問です。

React は内部的に非常に密接に結合しているため、変更したくても変更できません。決してそのような目的を念頭に置いて設計されたものではありません。さらに、レンダリングと状態更新の強力な結合により、React はデータや 3D 要素などの非ビジュアル コンポーネントを DOM 要素と一緒に管理する必要がある HPSE プロジェクトには適していません。

HPSE では、イベント呼び出しとメモリのアンマウントのタイミングが個々のコンポーネントに関連付けられていない可能性がありますが、React はこのコンポーネントベースの構造を強制するため、そのような要件を処理することが困難になります。コンポーネントの状態変化がレンダリング ツリー全体に影響を与える可能性がある React の設計は、そのような影響を最小限に抑えたり制御したりする HPSE のニーズとも矛盾します。

React Three Fiber (R3F) のようなライブラリを使用すると、「HTML 要素のような」構文を使用して Mesh や Scene などのインスタンスを作成できますが、それは React の構造に適合した Three.js にすぎません。 React 内の高度な結合は、内部が変更できないという問題を悪化させるだけです。

React のイベント処理アプローチにも問題があります。 React は合成イベント システムを使用して、ブラウザーの互換性とイベント処理の一貫性を確保します。ただし、このシステムはイベント処理に抽象化レイヤーを追加することにより、HPSE で必要なイベント ループとタイミングのきめ細かい制御を制限し、本質的な最適化の実装を困難にしています。

これらの問題は、React の設計哲学が HPSE の目標と根本的に異なるために発生します。 React は HPSE を念頭に置いて構築されていません。標準 Web クライアントの開発を最適化するように設計されました。 React が HPSE と同じような方向性を追求していたら、その機能は大きく異なっていたはずであり、HPSE の開発に採用されるケースもあったでしょう。しかし、彼らの目標は大きく異なるため、必然的に別れることになります。

これは、ルーティングや useEffect など、React に関するすべてが悪いと言っているわけではありません。実際、これらの機能のほとんどは、スタンドアロンの JavaScript モジュールまたはコードを使用して実装できます。 React とは異なり、一般的な JavaScript モジュールはプロジェクトに特定のパイプラインやルールを強制しません。さらに、オープンソースの場合は、ニーズに合わせて内部を変更できます。