「高パフォーマンス Web アプリ」または「フロントエンド」とは正確には何ですか?

Internet Explorer の時代が衰退して以来、JavaScript エコシステムはますます強力になり、「フロントエンド」という用語は高性能な最新の Web クライアントの同義語になりました。この「フロントエンド」の世界の中核には React があります。実際、フロントエンド開発で React を使用しないと、外れ値のように思われることがよくあります。

しかし、すべてのゲームが AAA であるわけではないのと同じように、Web アプリについて議論する際には、「高性能」とは何を意味するのかを慎重に考慮する必要があります。この区別は、今日の主題にとって非常に重要です。

1.ハイパフォーマンス Web アプリの範囲

ほとんどの場合、「高性能 Web アプリ」という用語は、React、Vue、Angular などの JavaScript ベースのフレームワークを使用して構築されたインタラクティブで動的な Web クライアントを指します。これらのアプリは通常、高速な読み込み時間とクライアント側ルーティングを備えており、React の仮想 DOM はレンダリング速度の向上に大きな役割を果たしています。

ただし、WASM モジュールのメモリ制限の 4 GB をすべて利用し、体系的なメモリ管理を念頭に置いて構築され、Blender や 3Ds Max などのネイティブ プログラムと同等のパフォーマンスを目指す Web アプリもあります。これらのアプリは、SEO に最適化された従来の「Web ページ」ではなく、ブラウザー タブのあらゆるリソースを利用する「プログラム」の概念に沿っています。

現在のブラウザ環境では、メモリ制限とオーバーヘッドのせいでネイティブのようなパフォーマンスを実現するのがまだ難しいかもしれませんが、そのようなアプリの目標は根本的に異なります。これらは大規模なデータセットを処理し、最高のレンダリング速度を追求しながら、2 ～ 4 GB のメモリをすべて使用することを目指しています。

この種の Web アプリが直面する問題は、一般的な「高パフォーマンス」アプリが直面する問題とは異なるため、追求する方向性も異なります。

冒頭で述べた「高パフォーマンス Web アプリ」と、ここで説明する「高パフォーマンス Web アプリ」は、その道筋が根本的に異なります。それらを単一の用語で一括りにするのは問題があります。これらの違いを反映するには、別の用語が必要です。

そのため、後者を「高パフォーマンス Web アプリ」または「フロントエンド」と呼ぶのをやめ、代わりに次の用語を使用することを提案します。

• ブラウザベースのハイパフォーマンス フレームワーク エンジニアリング (BBHPFE)
• (ブラウザベース) ハイパフォーマンス システム エンジニアリング (HPSE)

これらの用語はフロントエンドと HPSE の要件の違いを明確に定義していると思います。すべてのブラウザベースのクライアントがフロントエンドであるわけではありません。一部は HPSE です。この区別がなぜ重要なのかを理解するために、次の例を考えてみましょう:

[会話 1]

A: 「フロントエンド アプリを開発していますが、React は使用していません。」
B: 「React のないフロントエンド アプリですか? React はフロントエンドで 60% 以上の市場シェアを持っています。なぜそれを使用しないのですか?」

[会話 2]

A: 「HPSE アプリを開発していますが、React は使用していません。」
B: 「それは HPSE にとって当然のことです。ゲーム会社はエンジンを広範囲にカスタマイズすることがよくありますが、React の内部機能とレンダリング パイプラインは変更できません。そのような目的で設計されたわけではありません。」

次に、HPSE に必要な必須コンポーネントについて説明します。

2-1.メモリ管理
メモリを取り上げずに高性能プログラムについて語ることはできません。ガベージ コレクターを使用する場合でも、動的に割り当てられたメモリを手動で解放する場合でも、未使用のメモリは常に解放する必要があります。

プレイヤーが新しいマップに移動するブラウザベースのゲームを考えてみましょう。ゲームはサーバーから新しいマップ データを非同期で取得し、新しいメッシュを作成し、古いメッシュを削除する必要があります。古いメッシュの生成に使用されたデータも解放する必要があります。

古いデータへの参照が適切に解放されていない場合、マップが遷移するたびにメモリ使用量が増加し続けます。 2GB 程度に達すると、「メモリ不足」エラーが発生し、ブラウザがクラッシュする可能性があります。

確かに、JavaScript は低レベルのメモリ制御を目的として設計されていません。言語も開発者の哲学もそれを優先していません。メモリ管理が常に重要だと言っているわけではありませんが、よく言われるように、「無料のランチなどというものはない」のです。メモリ管理が必要な場合は、必ず実行する必要があります。

2-2.要件を満たす柔軟性
「ジュニア開発者から中級者に移行する頃には、要求されたものはすべて構築できるはずです。」

JavaScript は、(メモリ制限を除けば) 固有の制限がほとんどない、すでに優れた言語です。何かを構築したい場合は、おそらく実現できるでしょう。

本当の問題は、現在のプロジェクトが本当にさまざまな要件に対応できるかどうかです。

工場の機械が稼働し続けると故障するように、カスタマイズされた機能の高性能を追求すると、予期せぬ課題に遭遇することは避けられません。このような場合、柔軟性と固有の要件を満たす能力が不可欠です。

たとえば、Lost Ark が Unreal Engine 3 で構築されたことを聞いたことがありますか?アンリアル エンジン 5 はすでにリリースされていますが、彼らは 2004 年に作成されたアンリアル エンジン 3 をまだ使用しています。これまでプロジェクトを維持するには、エンジンに大規模な変更を加えたに違いありません。実質的には完全なオーバーホールです。ゲームの特性により、パフォーマンスと美的要件を満たすために、遅延レンダリング、インスタンス化、カリング、画面空間の反射などの技術を使用して、レンダリング パイプラインとループを常にカスタマイズする必要がありました。

エンジンのソース コードを変更できる機能は重要でした。もしエンジンが閉鎖されていたり、改造ができないほど緊密に結合されていたなら、ロストアークは決して開発されなかったかもしれません。

HPSEも同様です。ブラウザベースの環境に変わっても、カスタム機能や柔軟な変更が必要な点は変わりません。したがって、HPSE で使用されるライブラリと外部モジュールは変更可能である必要があり、ブラウザのレンダリング パイプラインや内部モジュールの結合が厳格すぎてこれらの変更ができない場合、重大な問題になります。

2-3.必然のオブジェクト指向アプローチ
大規模なプログラムを扱う場合、避けられないことが 1 つあります。それはオブジェクト指向プログラミング (OOP) です。

JavaScript はマルチパラダイム言語であり、関数型プログラミング (FP) が広く使用されています。ただし、FP は Web クライアントには適していますが、FP のインスタンスには内部状態がないため、複数のオブジェクトが複雑な方法で相互作用する大規模なプログラムではほとんど使用されません。

React はグローバルな状態管理と useEffect でこれを補いますが、各インスタンスが独自の状態を維持し、パブリック メソッドを通じてメソッド呼び出しを制御するほど直感的ではありません。

OOP が常に最良の選択であるとは限りませんが、HPSE の高度にカスタマイズされた開発ニーズを考慮すると、これより良い代替手段を考えるのは困難です。オペレーティング システムやゲームなどの大規模プログラムの多くは、OOP 原則を使用して構築されています。最も一般的なエンジン ソースでさえオブジェクト指向ですが、方法論には多少の違いがあります。

大規模プロジェクトに参加したことのある開発者は、OOP に精通している可能性があります。これにより、OOP ベースの開発がコラボレーションを促進します。

とはいえ、JavaScript の強みを捨てる必要はありません。 JavaScript は関数と const 宣言をサポートしているため、インスタンスを必要としない単純なモジュール関数は、const または関数を使用してオブジェクト リテラルとして定義できます。これにより、生産性が向上し、JavaScript の多用途性を活用できます。

結論として、オブジェクト指向の原則を組み込んだマルチパラダイム アプローチが HPSE にとって理想的であると考えています。