Qu'est-ce qu'une « application Web haute performance » ou un « frontend » exactement ?
Depuis le déclin de l'ère Internet Explorer, l'écosystème JavaScript est devenu de plus en plus puissant et le terme « frontend » est devenu synonyme de clients Web modernes et performants. Au cœur de ce monde « frontend » se trouve React. En fait, ne pas utiliser React dans le développement frontend donne souvent l'impression d'être une valeur aberrante.
Mais tout comme tous les jeux ne sont pas AAA, nous devons soigneusement réfléchir à ce que nous entendons par « hautes performances » lorsque nous parlons d'applications Web. Cette distinction est cruciale pour le sujet abordé aujourd’hui.
1. La portée des applications Web hautes performances
Dans la plupart des cas, le terme « application Web haute performance » fait référence à un client Web interactif et dynamique construit à l'aide de frameworks basés sur JavaScript comme React, Vue ou Angular. Ces applications offrent généralement des temps de chargement rapides et un routage côté client, et le DOM virtuel de React joue un rôle majeur dans l'amélioration de la vitesse de rendu.
Cependant, certaines applications Web utilisent les 4 Go de la limite de mémoire du module WASM, sont conçues dans un souci de gestion systématique de la mémoire et visent des performances comparables à celles des programmes natifs comme Blender ou 3Ds Max. Ces applications s'alignent davantage sur le concept de « programmes » qui exploitent toutes les ressources d'un onglet de navigateur, plutôt que sur les « pages Web » traditionnelles optimisées pour le référencement.
Bien que les environnements de navigateur actuels puissent encore avoir du mal à offrir des performances natives en raison des limites de mémoire et de la surcharge, les objectifs de ces applications sont fondamentalement différents. Ils gèrent de grands ensembles de données et visent à utiliser la totalité des 2 à 4 Go de mémoire, tout en recherchant les vitesses de rendu les plus élevées.
Étant donné que les problèmes rencontrés par ces types d'applications Web diffèrent de ceux rencontrés par les applications « hautes performances » typiques, les directions qu'elles poursuivent divergent également.
La « web app haute performance » évoquée au début et celle que je décris ici sont fondamentalement différentes dans leurs parcours. Les regrouper sous un seul terme serait problématique. Nous avons besoin d'une terminologie différente pour refléter ces différences.
C'est pourquoi je propose que nous arrêtions de parler de cette dernière comme d'une « application web haute performance » ou d'un « frontend » et que nous utilisions plutôt les termes suivants :
Je pense que ces termes définissent clairement la différence d'exigences entre le frontend et HPSE. Tous les clients basés sur un navigateur ne sont pas des interfaces ; certains sont des HPSE. Considérez l'exemple suivant pour comprendre pourquoi cette distinction est importante :
[Conversation 1]
A : "Je développe une application frontale mais je n'utilise pas React."
B : "Une application frontend sans React ? React détient plus de 60 % de part de marché dans le frontend ! Pourquoi ne l'utiliseriez-vous pas ?"
[Conversation 2]
A : "Je développe une application HPSE mais je n'utilise pas React."
B : "Cela a du sens pour HPSE. Les sociétés de jeux personnalisent souvent leurs moteurs de manière approfondie, mais les fonctions internes et le pipeline de rendu de React ne peuvent pas être modifiés. Il n'a jamais été conçu à cet effet."
Parlons maintenant des composants essentiels qu'un HPSE doit avoir.
2-1. Gestion de la mémoire
Vous ne pouvez pas parler de programmes hautes performances sans aborder la mémoire. Qu'il s'agisse d'utiliser un garbage collector ou de libérer manuellement la mémoire allouée dynamiquement, la mémoire inutilisée doit toujours être libérée.
Considérons un jeu par navigateur dans lequel le joueur se déplace vers une nouvelle carte. Le jeu devra récupérer de nouvelles données cartographiques du serveur de manière asynchrone, créer de nouveaux maillages et supprimer les anciens. Les données utilisées pour générer l'ancien maillage doivent également être libérées.
Si les références aux anciennes données ne sont pas correctement publiées, l'utilisation de la mémoire continuera d'augmenter à chaque transition de carte. Une fois qu'il atteint environ 2 Go, vous pouvez rencontrer une erreur « Mémoire insuffisante » et le navigateur plantera.
Il est vrai que JavaScript n’a pas été conçu pour le contrôle de la mémoire de bas niveau : ni le langage ni la philosophie de ses développeurs ne lui donnent la priorité. Je ne dis pas que la gestion de la mémoire est toujours cruciale, mais comme on dit, « il n’y a rien de gratuit ». Si la gestion de la mémoire est nécessaire, il faut le faire.
2-2. Flexibilité pour répondre aux exigences
J'ai entendu un jour quelqu'un dire : "Au moment où vous passerez du statut de développeur junior à celui de développeur intermédiaire, vous devriez être capable de créer tout ce qui vous est demandé."
JavaScript est déjà un langage impressionnant avec peu de limitations inhérentes (en dehors des limites de mémoire). Si vous voulez construire quelque chose, cela peut probablement être fait.
真正的問題是你目前的專案是否能夠真正滿足各種各樣的需求。
就像工廠裡的機器在連續運轉後就會出現故障一樣，追求高效能、客製化功能必然會遇到意想不到的挑戰。當這種情況發生時，靈活性和滿足獨特要求的能力至關重要。
例如，您聽過《失落的方舟》是基於虛幻引擎 3 建構的嗎？虛幻引擎 5 現已發布，但他們仍然使用 2004 年創建的虛幻引擎 3。為了使該項目維持到現在，他們必須對引擎進行大量修改——實際上是徹底檢修。由於遊戲的特點，他們必須不斷地透過延遲渲染、實例化、剔除、螢幕空間反射等技術來客製化渲染管線和循環，以滿足效能和美觀的要求。
修改引擎原始碼的能力至關重要。如果引擎關閉或耦合得太緊而無法進行修改，失落的方舟可能永遠不會被開發出來。
HPSE 是一樣的。雖然環境已經變成了基於瀏覽器的環境，但對自訂功能和靈活修改的需求仍然沒有改變。因此，HPSE 中使用的庫和外部模組必須是可修改的，如果瀏覽器的渲染管道或內部模組耦合過於嚴格而不允許這些更改，則會成為一個嚴重的問題。
2-3。不可避免的物件導向方法
在處理大型程式時，有一件事是不可避免的：物件導向程式設計（OOP）。
JavaScript是一種多範式語言，函數式程式設計（FP）被廣泛使用。然而，FP 雖然適合 Web 用戶端，但很少用於多個物件以複雜方式互動的大型程序，因為 FP 中的實例缺乏內部狀態。
React 透過全域狀態管理和 useEffect 來彌補這一點，但它不如讓每個實例維護自己的狀態並透過公共方法控制方法呼叫那麼直觀。
雖然 OOP 並不總是最佳選擇，但在考慮 HPSE 的高度客製化開發需求時，很難想到更好的選擇。許多大型程序，包括作業系統和遊戲，都是使用 OOP 原理建構的。即使是最受歡迎的引擎來源也是面向對象的，在方法上略有不同。
參與過大型專案的開發者可能對OOP很熟悉。這使得基於 OOP 的開發有利於協作。
也就是說，沒有必要放棄 JavaScript 的優點。由於 JavaScript 支援函數和 const 聲明，因此不需要實例的簡單模組函數可以使用 const 或函數定義為物件文字。這可以提高生產力並利用 JavaScript 的多功能性。
總之，我相信結合物件導向原則的多範式方法對於 HPSE 來說是理想的選擇。
以上是（高效能 Web 應用程式的要求的詳細內容。更多資訊請關注PHP中文網其他相關文章！
