Comparaison de frameworks

**sekaijin** · 02/08/2015, 18h00

Bonjour,

Je viens de lire une série d'articles sur le NET qui présente un (ou compare des) framework JavaScript.

À chaque fois, il y a une section performance. Et là, j'avoue que je suis surpris.
Dans la plupart des articles de présentation et dans tous les articles de comparaison, le test de performance est fait sur la recherche d'un élément dans la page.

Pourtant si je regarde mes développements perso c'est probablement la fonction la moins utilisée.
Je sais pertinemment que certains paradigmes impliquent une utilisation intensive de cette fonction, mais ce n'est pas le cas de tous.

En regardant de plus près le paradigme de divers frameworks, il existe une façon (ce n'est pas la seule) de les partager.
ceux qui partent d'un HTML existant et qui recherchent des éléments pour leur appliquer une fonction
Ceux qui construisent un HTML prêt à l'emploi.

Ce qui peut se résumer à ces deux façons de faire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
<html>
<head>
<script>document.getElementById('myButton').onclick = function() {
  document.getElementById('display').value=8;
};</script>
</head>
<body>
  <button id="myButton">click</button>
  <input id="display" type="text" value="0" />
</body>
<html>

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
<html>
<head>
<script>document.body.addEventListener("load",function () {
  var button = document.createElement('BUTTON');
  button.innerHTML = 'click';
  var input = document.createElement('INPUT');
  input.setAttribute('type','text');
  input.value=0;
  button.onclick = function() {
    input.value=8;
  };
  document.body.appendChild(button);
  document.body.appendChild(input);
});</script>
</head>
<body>
</body>
<html>

(ce code illustre le principe rien de plus)

Dans le premier cas, on a un HTML existant et pour assurer la fonction il faut chercher les éléments pour les manipuler.
Dans le second, on n'a pas de HTML et on ajoute dynamiquement les éléments. On ne cherche jamais d’élément.

Si je dois comparer deux frameworks qui adoptent l'un et l'autre de ces principes
Avoir une fonction de recherche dans le second cas qui n'est pas performante n'implique en rien que le framework est moins performant. Au contraire une implémentation naïve comme celle que je donne, ferait que même si le second avait une fonction de recherche 100 fois lente il resterait le plus rapide à l'exécution. Vu qu'il n'y a pas de recherche, le temps de recherche du premier le pénaliserait systématiquement.

Par contre si je m'intéresse au temps pour que la page soit disponible le second devant construire des éléments dynamiquement le temps de construction le pénaliserait. Dans le cas de la deuxième approche, une fonction de construction performante est bien plus importante que la fonction de recherche.

Mais dans la réalité, quelle que soit l'approche choisie on ajoute toujours dynamiquement des éléments et il arrive même dans la deuxième approche qu’on fasse des recherches.

Et c'est ce qui m'étonne dans tous ces articles (ou presque). La performance est mesurée au travers d'une seule fonctionnalité qui pour certains frameworks est marginale.

Il existe bien des sujets de comparaison des frameworks et le découpage que j'ai fait n'est qu'un parmi de nombreux autres.

A+JYT

**Golgotha** · 03/08/2015, 11h07

Bonjour,

J'ai compris ton message, mais je n'ai pas compris la question.

Il me parais évident que pour comparer deux choses (voitures, ordinateurs, fours, téléphones... etc) il faut comparer plusieurs points, ça n'aurait aucun sens de faire un comparaison de voiture sur un seul critère. Donc, oui, la comparaison de frameworks doit être fait sur les points qui caractérises les frameworks (courbe d'apprentissage, facilité d'utilisation, communauté, documentation, rapidité d’exécution, taille, plugin... etc)

Edit : j'ai vu que tu parles de la section performance en particulier.

En gros, c'est pareil, les performances se mesure sur plusieurs critères, ça n'a pas de sens de n'en prendre que un ou deux.

**sekaijin** · 03/08/2015, 12h00

Je n'ai pas de question juste un étonnement.

mon propos n'est pas de dire qu'on compare les frameworks sur un seul critère heureusement ce n'est pas le cas.
Ce n'est pas nom plus de dire qu'on mesure la performance que sur un seul critère car heureusement ce n'est non plus pas le cas.

Ce qui m’étonne c'est qu'on mesure la performance sur un critère qui n'est pas toujours pertinent.

Pour reprendre des analogies c'est comme comparer des véhicules de transport en mesurant systématiquement leur durée de vol maximale.
sur un Robin 400 ou un Cessna cela à du sens mais une une Renault Megane, ou un TGV

Je constate que dans tous les articles que j'ai lus un point d'évaluation des perfs et la mesure des perf de la fonction de recherche. Or certain framework ne l'utilise JAMAIS.
Je suis étonné de ne pas trouver de méthode de comparaison des perfs plus pertinente.

dans la liste des choses étrange que j'ai constaté dans ces comparatifs c'est qu'on va comparer la vitesse d'exécution d'une fonction recherchant des élément HTML dans un framework à une autre dans un autre qui elle ne cherche pas des éléments HTML mais des objet js du framework lui-même ou encore dans un troisième une fonction qui recherche indifféremment des Elements HTML ou des objet JS.

Bref tout cela n'a aucun sens. Pas plus que la consommation de carburant en litre au cent kilomètre pour une voiture électrique rechargeable.

A+JYT

**SylvainPV** · 03/08/2015, 15h28

Pour un framework JS, j'aurais tendance à croire que la performance en elle-même est un critère non pertinent, sauf en cas de pitfalls majeurs. La raison est simple: je n'ai jamais rencontré un seul cas où un traitement côté client pouvait impacter significativement les performances sans qu'il n'existe une optimisation évidente à mettre en place. Le problème de performance numéro 1 a toujours été la latence réseau et non l'exécution JavaScript.

Pour cette raison, je préfère RiotJS (< 10Ko) à React (127Ko) malgré que React soit devant dans les benchmarks. Les utilisateurs se fichent de gagner 10 millisecondes à chaque changement de vue, par contre ils apprécieront de gagner une demi-seconde au chargement initial du site.

En revanche, pour l'usage du jeu vidéo / de la 3D / des sites mobiles riches, la performance redevient un critère important. Mais il s'agit d'une toute autre catégorie que celles des frameworks JS classiques.

Comparaison de frameworks

JavaScript

Vue hybride

Discussions similaires

Partager

Partager