js-framework-benchmark - variations de la solution idéale au problème mathématique de la vitesse ou pourquoi elle est standard

Salut tout le monde ! J'ai passé 2,5 ans à résoudre le problème de vitesse dans le référentiel js-framework-benchmark, et je ne le regrette pas, car il y a une observation super intéressante que j'ai récemment remarquée.

Fondamentalement, tous les développeurs de frameworks et de bibliothèques ont été confrontés au problème de la vitesse dès les premiers stades du développement Web. C’est l’essentiel, car plus les gens voient rapidement les modifications des données sur l’interface utilisateur, moins ils y passent de temps. Imaginez que si les sites fonctionnaient 10 % plus rapidement, des milliards de personnes pourraient sauver de nombreuses années de vie.

Il fallait faire quelque chose, donc, et peut-être pour d'autres raisons, de nombreux référentiels avec des benchmarks de frameworks et de bibliothèques modernes ont été créés. L'un de ces référentiels est js-framework-benchmark. Il contient presque tous les frameworks et bibliothèques populaires pour créer une interface utilisateur.

La tâche principale est de dessiner un tableau qui dépend des données. Cela semble être une tâche simple, mais en fait, c'est très, très indicatif, car il attire l'attention sur l'essentiel : l'application peut ressembler à n'importe quoi, mais les composants, leur séquence dans le DOM, fonctionnent avec le navigateur et d'autres choses - imiter le comportement d'un site normal. Parce qu'une ligne dans un tableau, un en-tête sur une page - tout cela est en général, juste un élément du général.

Puisque l'application fonctionne normalement avec le code et l'heure comme dépendance (on ne prend pas en compte l'affichage, les couleurs, car on peut dire 0 et 1 sur le fil, donc il n'y a que 2 de telles dépendances), puis au moins 1 composant, au moins un million de composants différemment entrelacés - il n'y a pas de signification particulière, car tout repose sur un seul moteur. Par conséquent, la simplicité ici convient même, car c'est la clarté.

Donc, nous avons une tâche, mais nous devons la résoudre d'une manière ou d'une autre. La programmation est une bonne chose car nous pouvons résoudre un problème mathématique de millions de manières différentes, mais revenons à l’essentiel : l’algorithme idéal de base est le même pour tout le monde. Il s'agit d'un théorème, et quoi et comment est mis en œuvre est une question de goût et de commodité.

Prenons l'interface maintenant, à quoi ressemble-t-elle :

Test de l'application :

Quelques résultats :
https://krausest.github.io/js-framework-benchmark/2024/table_chrome_130.0.6723.58.html

Nous avons des résultats pour différentes actions clés avec le tableau qui peuvent se produire lorsque l'état change. Nous pouvons mesurer la vitesse de travail et comparer quel code fonctionne le plus rapidement et lequel le plus lentement. C’est très pratique, car cela crée des règles du jeu équitables pour tous les frameworks et bibliothèques. Mais ce serait bien si seule la vitesse était le problème, mais la norme de la structure elle-même est également fixée, car elle doit être correcte. L'approche des composants, la mise en œuvre clé, l'état et d'autres termes sont inclus dans tout cela. Sans une telle norme, ce n'est tout simplement pas un sujet de travail.

Ainsi, la norme a longtemps été fixée par les créateurs de frameworks et de bibliothèques - elle est évidente et compréhensible pour ceux qui le font. La question est que nous devons maintenant adapter tout cela d'une manière ou d'une autre pour un travail rapide, afin que l'interface utilisateur soit rapidement rendue.

Alors, une bonne idée de rassembler tous les créateurs de frameworks et de bibliothèques "grands" et moins grands, et juste des passionnés qui veulent aussi s'essayer. Tout cela est important car, comme dans le sport, nous avons une communauté et un comité de « dirigeants » où sont publiées différentes solutions aux problèmes. Ce n'est pas une très bonne comparaison en termes de programmation, car ce ne sont que des mathématiques, mais l'idée en elle-même est intéressante, car elle pousse les gens à faire beau et vite et, surtout, c'est correct.

Eh bien, une telle communauté a généré de nombreuses solutions intéressantes ces dernières années qui peuvent être utilisées aujourd'hui par tous les créateurs actuels et futurs. Vous n'avez pas besoin de réinventer la roue, car l'algorithme de base est déjà écrit. Cette compréhension peut faire gagner de nombreuses années.

De nombreux développeurs ont déjà écrit des exemples d'implémentation de code idéal, il est assez facile de se baser sur cela, donc le mieux est que cela ne s'est pas produit avant et c'est arrivé, entre autres, à cause de ce référentiel. Peu importe ce que disent les autres, c'est cool.

Si nous considérons l'algorithme idéal par composants, nous pouvons mettre en évidence - l'algorithme de l'implémentation clé (en utilisant la sous-séquence croissante la plus longue ou une autre variante de celle-ci), le clonage de modèle, la réactivité directement (textContent, addEventListener, classList.add), ou en utilisant le VDOM inutile aujourd'hui, bien qu'en termes de modèles, cela soit nécessaire, ainsi que le travail avec l'état et l'importation entre les composants, les 2 derniers sont discutables. Mais c'est la base, rien d'autre ne peut être inventé ici.

Cet article ne contiendra aucun code en tant que tel, car il y en a beaucoup dans les référentiels de benchmark.

Quoi qu'il en soit, j'espère que les gens comprendront bientôt qu'aujourd'hui nous avons déjà le code idéal pour afficher les données, cela vaut juste la peine d'en tenir compte et de faire quelque chose de nouveau à partir de celui-ci, sans réinventer la roue. De nombreuses bibliothèques et frameworks peuvent aujourd'hui fonctionner beaucoup plus rapidement et beaucoup plus efficacement, c'est juste que le code existant ne le permet pas, car il peut y avoir beaucoup de travail et ce n'est pas un fait que cela soit généralement possible sans tout refaire.

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!