• Quels sont les coûts liés à l’utilisation de frameworks JavaScript pour le développement Web ? Une analyse des sites utilisant React, Vue.js ou Angular
    https://javascript.developpez.com/actu/303519/Quels-sont-les-couts-lies-a-l-utilisation-de-frameworks-JavaS

    S’invitant dans le débat, Tim Kadlec, un développeur qui aide les organisations à améliorer les performances de leurs sites, estime pour sa part qu’il n’y a « pas de moyen plus rapide de ralentir un site que d’utiliser un tas de JavaScript », et c’est justement ce que font les frameworks JavaScript : utilisez beaucoup plus de JavaScript. Mais « le truc avec JavaScript », poursuit-il, « c’est que vous finissez par payer une taxe sur les performances pas moins de quatre fois », dit-il. Les quatre taxes auxquelles il fait allusion sont :
    – le coût de téléchargement du fichier sur le réseau ;
    – le coût de l’analyse et de la compilation du fichier non compressé une fois téléchargé ;
    – le coût d’exécution du JavaScript ; et
    – le coût de la mémoire.

    Avec des graphes comparatifs de divers paramètres tels que « Quantité de JavaScript servi », « Temps de traitement CPU »

    Pour illustration de cette lenteur et du peu d’importance donnée à l’UX par les développeurs, voir par exemple le backoffice de #Mailjet ou #Gandi_v5 qui sont des modèles de lenteur totalement désespérant et rebutant pour l’utilisateur... (en plus d’un manque d’ergonomie flagrant sur toutes les fonctionnalités un peu avancées)

    Et conséquence non évoquée ici, le coût écologique lié à l’utilisation de ces framework doit être non négligeable...

    L’article original (En) : https://timkadlec.com/remembers/2020-04-21-the-cost-of-javascript-frameworks

    #lenteur #framework_javascript #web_dev #fail

    • Un commentaire précise qu’il faut quand même pas juste prendre en compte le premier chargement, ça n’a pas de sens, car pour là où c’est utilisé, c’est généralement pour des choses qu’on utilise plusieurs fois, où on a un compte, etc. Donc une fois le premier chargement, une grosse partie est déjà en mémoire du navigateur, que ce soit le JS et la plupart des éléments d’interface.

    • Pour le premier chargement, ça dépend à quel utilisateur on s’adresse mais si la première impression qu’on a en arrivant sur un site c’est sa lenteur, ça fait mauvais genre. De plus le cache ne dure pas indéfiniment, en plus du fait que le fichier JS peut inclure autre chose que la librairie du framework et donc demander à être téléchargé de nouveau à chaque màj du code.
      C’est amusant de voir les commentaires sur le site developpez, certains semblent penser qu’on ne peut pas faire de site/app sans ces frameworks... Cela explique sûrement que tant de sites ou d’applications Web soient si lourds.
      Pour moi le pire que j’ai vu (en tant qu’utilisateur) c’est le site d’Arrêts sur image, qui utilise Angular. Une aberration. Ils ont optimisé un poil depuis le lancement donc c’est moins pire aujourd’hui mais ça reste une erreur technique majeure à mon sens.

    • Ah bah pour un site de média éditorial, essentiellement fait de texte avec quelques images et vidéos, ça n’a aucun putain de sens… Normalement c’est pour de l’applicatif, des trucs où ça doit mettre jour des données en direct, etc. C’est ce que je disais plus haut, normalement quand on l’utilise c’est pour de l’appli, où t’as un compte, où ya du fonctionnel (pour l’interface d’admin d’un média éditorial à la limite, mais pas sa partie publique). Pour juste du texte et des commentaires dessous… hu

    • C’est tout le problème, les développeurs connaissent tel ou tel framework et se mettent à l’utiliser partout, sans discernement. Dans les commentaires sur Développez, il y en a même un qui explique que sans framework Javascript son appli ne serait pas jolie ! Et même pour les applis, sauf besoins très spécifiques, j’ai quelques doutes sur l’utilité de ces machineries, l’auteur du texte initial a raison, le Javascript de base (ou jQuery) peut faire beaucoup de choses. Bien sûr ça suppose de passer un peu plus de temps à coder (et de se confronter à des choses peut-être plus complexes au premier abord), encore que la maintenance sera probablement beaucoup plus légère ensuite.
      Je précise par ailleurs que j’ai déjà utilisé Angular de manière assez intensive, je suis loin d’être un anti-framework primaire.

  • Microsoft : GitHub annonce l’acquisition du gestionnaire de packages Javascript npm, les développeurs qui se servent du registre public de npm pourront continuer à l’utiliser gratuitement
    https://javascript.developpez.com/actu/297284/Microsoft-GitHub-annonce-l-acquisition-du-gestionnaire-de-pac

    Microsoft poursuit son recentrage sur l’open-source...
    ...tout en poursuivant sa tactique habituelle : mettre la main sur les briques « clés » des systèmes.
    Avec npm il verrouille un écosystème énorme !

    #npm #microsoft #github #open-source