Comment les nouveaux concepts de JSSugar et JSre peuvent ralentir les sites Web

Bonjour à tous ! Aujourd'hui, j'aimerais partager mes réflexions sur le sujet de JS0 et JSSugar, dont on parle beaucoup. À mon avis, il y a là un certain danger, potentiellement caché pour des milliards d’utilisateurs de sites Web. Maintenant, je vais essayer d'expliquer ce que je veux dire.

Vous n'aimerez peut-être pas mon point de vue, s'il vous plaît, il y a des commentaires sur dev.to, je vais essayer de répondre à tout.

Description du concept JS0 et de JSSugar d'après ma compréhension

Peut-être que j'ai mal compris quelque chose ou fait une erreur quelque part, mais je vais vous expliquer du mieux que je peux.

En bref, aujourd'hui en javascript, au lieu d'étendre la fonctionnalité avec de plus en plus de fonctions, nous devons nous concentrer sur la rendre plus acceptable pour l'utilisateur. Par exemple, aujourd'hui, tous les développeurs écrivent du code qui passe par TypeScript, Webpack et un tas d'autres couches, alors pourquoi ne pas appliquer cette logique de simplification, lorsque le développeur écrit moins de code, dans les futures versions d'ecmascript. Par exemple, définir une telle vision comme standard, selon laquelle nous devons créer des fonctions (forEach par exemple) tout comme lodash ou jQuery, et ne pas étendre, car c'est déjà compliqué.

Par exemple, il y a JS0, ce sera pour cet environnement où tout est compilé, et laissera les développeurs ordinaires utiliser forEach au lieu de for, sous condition.

C’est donc ici que se pose le sérieux problème de cette approche. Il semble qu'il soit écrit que "pas pour des raisons de vitesse", mais en fait, tous ceux qui ont déjà comparé la vitesse du code JavaScript dans des benchmarks comprennent à quoi je veux en venir.

Implémentation lente pour la micro-optimisation de la quantité de code

Oui, il est maintenant temps de passer à la pratique :

Code #1

const a = [1,2,3,4,5]
a.forEach((e)=>{
  if(e === 4){
    console.log(e)
  }
})

Code #2

const a = [1,2,3,4,5]
for (let index = 0; index < a.length; index++) {
  const e = a[index];
  if(e === 4){
    console.log(e)
  }
}

Résultat :

Prenons maintenant un autre exemple :

Code #1

const a = [1,2,3,4,5];
const b =  a.map((e)=>{
  return e + 1;
})

Code #2

const a = [1,2,3,4,5]
const b = [];
for (let index = 0; index < a.length; index++) {
  const e = a[index];
  b.push(e + 1)
}

Résultat :

Les résultats sont basés sur les données du site https://jsbenchmark.com.

Donc, ce que je veux dire, c'est que si l'on imagine que du TC39 (Comité Technique) et de la communauté des développeurs en général, le principal vecteur de suggestion d'idées ira dans une telle direction, lorsque nous créerons des fonctions lodash et jQuery , et cela deviendra un standard dans ECMAScript, alors il y aura des fonctions comme forEach, qui ne changent pas la vitesse, mais ralentissent en fait l'application. Bien sûr, cela mérite réflexion.

Ici, même dans la diapositive officielle (l'oiseau s'est envolé), il est indiqué où le vecteur doit se déplacer et c'est vrai, pour la commodité des utilisateurs.

Et il est pratique pour les utilisateurs d'utiliser un site rapide, et non en retard, mais pour les développeurs "plus expressifs".

J'aimerais donc que, lorsque cela devient soudainement un standard, de telles fonctions ne soient pas au premier plan. SOLID, DRY et d'autres principes ralentissent déjà les applications modernes, et maintenant ils en font une norme.

Impact de js-framework-benchmark

Cet article a bien sûr été inspiré par mon expérience de travail avec le référentiel js-framework-benchmark, qui, à mon avis, montre très clairement pourquoi la vitesse est importante aujourd'hui. En fait, les gens veulent que les sites Web se chargent plus rapidement – ​​c’est un fait. Aujourd’hui, la plupart des frameworks et bibliothèques populaires modernes sont en fait lents. Il peut même sembler à quelqu'un que la vitesse est de la merde, mais ce n'est pas le cas. Si vous mettez tout ensemble, alors avec de telles "optimisations", les applications Web fonctionneront plusieurs fois moins bien. Par conséquent, je pense que quelque chose comme ça.

Conclusion

C'est cool que des idées comme celles-ci sortent aujourd'hui. Ils font avancer JavaScript et toute la programmation Web, mais il y a des choses objectives comme la vitesse qui ne devraient pas non plus être ignorées.

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!