(Les exigences pour les applications Web hautes performances

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 :

• Ingénierie de framework haute performance basée sur un navigateur (BBHPFE)
• (Basé sur un navigateur) Ingénierie système haute performance (HPSE)

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.

La vraie question est de savoir si votre projet actuel peut réellement répondre à une grande variété d'exigences.

Tout comme les machines d'une usine tombent en panne après un fonctionnement continu, la recherche de fonctionnalités personnalisées et performantes conduit inévitablement à rencontrer des défis inattendus. Lorsque cela se produit, la flexibilité et la capacité de répondre à des exigences uniques sont essentielles.

Par exemple, avez-vous déjà entendu dire que Lost Ark a été construit sur Unreal Engine 3 ? Unreal Engine 5 est maintenant disponible, mais ils utilisent toujours Unreal Engine 3, créé en 2004. Pour maintenir le projet jusqu'à présent, ils ont dû apporter des modifications importantes au moteur, pratiquement une refonte complète. En raison des caractéristiques du jeu, ils ont dû constamment personnaliser le pipeline et la boucle de rendu avec des techniques telles que le rendu différé, l'instanciation, l'élimination et la réflexion de l'espace d'écran pour répondre aux exigences de performances et d'esthétique.

La possibilité de modifier le code source du moteur était essentielle. Si le moteur avait été fermé ou trop étroitement couplé pour permettre des modifications, Lost Ark n'aurait peut-être jamais été développé.

HPSE, c'est pareil. Même si l'environnement est désormais basé sur un navigateur, le besoin de fonctions personnalisées et de modifications flexibles reste le même. Par conséquent, les bibliothèques et les modules externes utilisés dans HPSE doivent être modifiables, et si le pipeline de rendu du navigateur ou le couplage de modules internes est trop rigide pour permettre ces modifications, cela devient un problème important.

2-3. L'inévitable approche orientée objet
Lorsqu'il s'agit de programmes à grande échelle, une chose devient inévitable : la programmation orientée objet (POO).

JavaScript est un langage multi-paradigmes et la programmation fonctionnelle (FP) est largement utilisée. Cependant, FP, bien que adapté aux clients Web, est rarement utilisé dans les programmes à grande échelle où plusieurs objets interagissent de manière complexe, car les instances de FP manquent d'états internes.

React compense cela avec la gestion globale de l'état et useEffect, mais ce n'est pas aussi intuitif que de laisser chaque instance maintenir son propre état et contrôler les appels de méthode via des méthodes publiques.

Bien que la POO ne soit pas toujours le meilleur choix, il est difficile de penser à une meilleure alternative si l’on considère les besoins de développement hautement personnalisés de HPSE. De nombreux programmes à grande échelle, notamment les systèmes d'exploitation et les jeux, sont construits selon les principes de la POO. Même les sources de moteur les plus populaires sont orientées objet, avec des variations mineures dans la méthodologie.

Les développeurs qui ont participé à des projets à grande échelle connaissent probablement la POO. Cela rend le développement basé sur la POO propice à la collaboration.

Cela dit, il n’est pas nécessaire de négliger les atouts de JavaScript. Étant donné que JavaScript prend en charge les fonctions et les déclarations const, les fonctions de module simples qui ne nécessitent pas d'instances peuvent être définies comme des littéraux d'objet à l'aide de const ou de fonctions. Cela peut améliorer la productivité et tirer parti de la polyvalence de JavaScript.

En conclusion, je pense qu'une approche multi-paradigmes, intégrant des principes orientés objet, serait idéale pour HPSE.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!