Le langage JavaScript est-il responsable de la lenteur des sites Web de nos jours ? Oui Selon un expert 820PARTAGES 16 0 JavaScript a fortement contribué à développer le Web 2.0 que ça soit à travers les technologies Ajax, Angular et bien dautres. Il se développe très rapidement et a permis de mettre sur pied des applications avec des performances remarquables. Il a également induit le développement très accéléré de rich Internet application (RIA). Une RIA ou application Internet riche, est une application Web qui offre des caractéristiques similaires aux logiciels traditionnels installés sur un ordinateur. La dimension interactive et la vitesse d'exécution sont particulièrement soignées dans ces applications web. Elles comportent la plupart du temps des annonces publicitaires et des trackers par exemple, la majorité basée sur des scripts JavaScript de tierce partie.



Le code de première partie est ce que vous écrivez vous-même. Celui de tiers est un code menant vers une ressource extérieure écrit et hébergé par le fournisseur de cette ressource. Un bouton LIKE de Facebook sur votre site par exemple. En octobre 2000, le poids moyen dune page web était de 89 Ko (images et scripts compris). En 2015, le poids moyen arrivait déjà à 2,6 Mo, soit une multiplication par trente en quinze ans. Le nombre de requêtes a quant à lui été multiplié par 10. La course aux KPI (un acronyme pour Key Performance Indicator traduit en français par indicateur clé de performance) nous a amené à installer toute sorte de traqueurs et widgets, ce qui dégrade fortement les performances. Les Indicateurs clés de performance sont des indicateurs mesurables daide décisionnelle. Ils sinscrivent dans une démarche de progrès et permettent le pilotage et le suivi de lactivité. Ils sont reportés et analysés sur une base hebdomadaire, mensuelle ou trimestrielle.



Notre usage du web quant à lui, est de plus en plus mobile. Les connexions sont donc moins stables (elles sont soumises à la qualité du réseau et de notre situation géographique). Les exigences des internautes sont-elles de plus en plus élevées ? Après 3 secondes dattente, 57 % des internautes quittent un site et 80 % dentre eux ny reviendront jamais. Depuis 2011, la vitesse de croissance de requête JavaScript de première et tierce partie a connu une forte augmentation. Bien que les spécialistes du web imputent la lenteur des sites web au code JavaScript et principalement à celui de tierce partie, lusage du JavaScript a quand-même augmenté denviron 50 % pour la première partie et presque 140 % pour la tierce partie.



Steve Souders, qui travaille chez SpeedCurve sur linteraction entre la performance et le design, sest basé sur la requête du nombre de médian de demande JS par les 1ère et tierce parties depuis 2010 pour tirer certaines conclusions. Sur limage ci-dessous, on peut constater qu'en termes de nombre de requêtes JavaScript, la première partie a augmenté de 50 %, passant de 4 à 6 requêtes, tandis que la tierce partie a augmenté de 140 %, passant de 5 à 12 requêtes. La croissance de codes JS de terce partie en termes de taille de JavaScript est plus alarmante. Le code JavaScript de la première partie a doublé, passant de 53 ko à 106 ko. Le code JavaScript de tierce partie est octuplé de 32 Ko à 258 Ko.

En regardant la quantité de code JavaScript utilisée aujourd'hui, les codes JS de tierces parties sont responsables de deux fois plus de demandes (12 contre 6) et environ deux fois et demie plus de kilo-octets (258 Ko contre 106 Ko).





Le code JavaScript de tierce partie apporte plus dinteractions avec le client et lui permet davoir une expérience enrichie. Il permet de charger des ressources externes et passe donc par un nom de domaine différent à celui de votre site, ce qui entraînera souvent une résolution DNS, suivie de létablissement dune nouvelle connexion TCP. On peut se poser la question de la localisation du serveur fournissant la ressource : si ce dernier ne s'appuie pas sur un CDN (Content Delivery Network), vos internautes peuvent être confrontés à une latence importante (délai minimum pour la transmission des données entre linternaute et le serveur, due à la distance les séparant). Quand vous avez un public national sur un site web ce problème ne se pose pas pour vos propres ressources. Il est cependant fréquent dutiliser de code JS de fournisseurs étrangers, et donc de faire face à cette contrainte.



Si la requête utilise du HTTPS, alors vous allez encore rajouter un délai supplémentaire, puisque ce protocole implique des échanges additionnels pour établir la connexion sécurisée. Enfin, vous serez dépendant du temps de réponse du serveur du parti tiers, ainsi que de son débit sortant. Sur la base des statistiques précédentes, Steve Souders estime queffectivement le JavaScript de tierce partie est une partie importante des sites web actuels. Il propose cependant, pour surveiller lutilisation de code code JS de tierce partie sur votre site, quil vous faut impérativement configurer ce quon appelle des budgets de performance. Un budget de performance consiste à définir le seuil de performance que lon ne souhaite pas dépasser. Il sexprime en métrique poids des pages ou encore nombre de fichiers. Ce budget de performance va ainsi permettre de maintenir un site rapide et de détecter toutes régressions. Ainsi, un constructeur de site web sassure de ne jamais oublier ce critère de performance et den faire un point de vigilance majeur.



Certains internautes ne comprennent pas pourquoi on accuse le langage dêtre à lorigine de la lenteur des pages web. Ils estiment que ce nest en rien la faute du langage et quil y a longtemps nous même avons décidé que les documents et les liens simples ne suffisaient plus. Nous voulions des applications web riches avec dénormes images ainsi quun nombre de milliards dannonces. Pourquoi est-ce maintenant la faute à JS ? Sinterrogent-ils. Ils recommandent doptimiser les sites web pour la mise en cache lors de première visite pour rendre le site rapide les prochaines fois. Un autre, toujours pour défendre JS, rejette la faute sur les entreprises de marketing et les médias et leurs logiciels qui sont souvent insérés dans les pages web pour faire de la publicité.



Source : Billet de blog



Et vous ?



Qu'en pensez-vous ?

Selon vous, le langage JS devrait-il être tenu responsable de la lenteur des sites Web ? Pourquoi ?



Voir aussi



The State Of JavaScript 2018 : l'enquête révèle que JavaScript est en pleine évolution, voici une vue macro des technologies JS utilisées



Les tendances dans les métiers de la technologie en France en 2017, une enquête réalisée par CodinGame



The State Of JavaScript : participez à l'édition 2018 de l'enquête qui permet d'avoir une vue macro des technologies utilisées dans le monde JS



Mithril : un framework JavaScript moderne, simple, rapide et léger comparé à React ou Angular pour ceux qui privilégient la facilité d'intégration JavaScript a fortement contribué à développer le Web 2.0 que ça soit à travers les technologies Ajax, Angular et bien dautres. Il se développe très rapidement et a permis de mettre sur pied des applications avec des performances remarquables. Il a également induit le développement très accéléré de rich Internet application (RIA). Une RIA ou application Internet riche, est une application Web qui offre des caractéristiques similaires aux logiciels traditionnels installés sur un ordinateur. La dimension interactive et la vitesse d'exécution sont particulièrement soignées dans ces applications web. Elles comportent la plupart du temps des annonces publicitaires et des trackers par exemple, la majorité basée sur des scripts JavaScript de tierce partie.Le code de première partie est ce que vous écrivez vous-même. Celui de tiers est un code menant vers une ressource extérieure écrit et hébergé par le fournisseur de cette ressource. Un bouton LIKE de Facebook sur votre site par exemple. En octobre 2000, le poids moyen dune page web était de 89 Ko (images et scripts compris). En 2015, le poids moyen arrivait déjà à 2,6 Mo, soit une multiplication par trente en quinze ans. Le nombre de requêtes a quant à lui été multiplié par 10. La course aux KPI (un acronyme pour Key Performance Indicator traduit en français par indicateur clé de performance) nous a amené à installer toute sorte de traqueurs et widgets, ce qui dégrade fortement les performances. Les Indicateurs clés de performance sont des indicateurs mesurables daide décisionnelle. Ils sinscrivent dans une démarche de progrès et permettent le pilotage et le suivi de lactivité. Ils sont reportés et analysés sur une base hebdomadaire, mensuelle ou trimestrielle.Notre usage du web quant à lui, est de plus en plus mobile. Les connexions sont donc moins stables (elles sont soumises à la qualité du réseau et de notre situation géographique). Les exigences des internautes sont-elles de plus en plus élevées ? Après 3 secondes dattente, 57 % des internautes quittent un site et 80 % dentre eux ny reviendront jamais. Depuis 2011, la vitesse de croissance de requête JavaScript de première et tierce partie a connu une forte augmentation. Bien que les spécialistes du web imputent la lenteur des sites web au code JavaScript et principalement à celui de tierce partie, lusage du JavaScript a quand-même augmenté denviron 50 % pour la première partie et presque 140 % pour la tierce partie.Steve Souders, qui travaille chez SpeedCurve sur linteraction entre la performance et le design, sest basé sur la requête du nombre de médian de demande JS par les 1ère et tierce parties depuis 2010 pour tirer certaines conclusions. Sur limage ci-dessous, on peut constater qu'en termes de nombre de requêtes JavaScript, la première partie a augmenté de 50 %, passant de 4 à 6 requêtes, tandis que la tierce partie a augmenté de 140 %, passant de 5 à 12 requêtes. La croissance de codes JS de terce partie en termes de taille de JavaScript est plus alarmante. Le code JavaScript de la première partie a doublé, passant de 53 ko à 106 ko. Le code JavaScript de tierce partie est octuplé de 32 Ko à 258 Ko.En regardant la quantité de code JavaScript utilisée aujourd'hui, les codes JS de tierces parties sont responsables de deux fois plus de demandes (12 contre 6) et environ deux fois et demie plus de kilo-octets (258 Ko contre 106 Ko).Le code JavaScript de tierce partie apporte plus dinteractions avec le client et lui permet davoir une expérience enrichie. Il permet de charger des ressources externes et passe donc par un nom de domaine différent à celui de votre site, ce qui entraînera souvent une résolution DNS, suivie de létablissement dune nouvelle connexion TCP. On peut se poser la question de la localisation du serveur fournissant la ressource : si ce dernier ne s'appuie pas sur un CDN (Content Delivery Network), vos internautes peuvent être confrontés à une latence importante (délai minimum pour la transmission des données entre linternaute et le serveur, due à la distance les séparant). Quand vous avez un public national sur un site web ce problème ne se pose pas pour vos propres ressources. Il est cependant fréquent dutiliser de code JS de fournisseurs étrangers, et donc de faire face à cette contrainte.Si la requête utilise du HTTPS, alors vous allez encore rajouter un délai supplémentaire, puisque ce protocole implique des échanges additionnels pour établir la connexion sécurisée. Enfin, vous serez dépendant du temps de réponse du serveur du parti tiers, ainsi que de son débit sortant. Sur la base des statistiques précédentes, Steve Souders estime queffectivement le JavaScript de tierce partie est une partie importante des sites web actuels. Il propose cependant, pour surveiller lutilisation de code code JS de tierce partie sur votre site, quil vous faut impérativement configurer ce quon appelle des budgets de performance. Un budget de performance consiste à définir le seuil de performance que lon ne souhaite pas dépasser. Il sexprime en métrique poids des pages ou encore nombre de fichiers. Ce budget de performance va ainsi permettre de maintenir un site rapide et de détecter toutes régressions. Ainsi, un constructeur de site web sassure de ne jamais oublier ce critère de performance et den faire un point de vigilance majeur.Certains internautes ne comprennent pas pourquoi on accuse le langage dêtre à lorigine de la lenteur des pages web. Ils estiment que ce nest en rien la faute du langage et quil y a longtemps nous même avons décidé que les documents et les liens simples ne suffisaient plus. Nous voulions des applications web riches avec dénormes images ainsi quun nombre de milliards dannonces. Pourquoi est-ce maintenant la faute à JS ? Sinterrogent-ils. Ils recommandent doptimiser les sites web pour la mise en cache lors de première visite pour rendre le site rapide les prochaines fois. Un autre, toujours pour défendre JS, rejette la faute sur les entreprises de marketing et les médias et leurs logiciels qui sont souvent insérés dans les pages web pour faire de la publicité.Qu'en pensez-vous ?Selon vous, le langage JS devrait-il être tenu responsable de la lenteur des sites Web ? Pourquoi ? Une erreur dans cette actualité ? Signalez-le nous ! Votre nom : Votre e-mail : Décrivez l'erreur que vous souhaitez porter à notre connaissance : 224 commentaires Poster une réponse Signaler un problème Les mieux notés Les plus récents Ordre chronologique Rédacteur/Modérateur https://www.developpez.com

De plus en plus les développeurs empilent des frameworks et des plugins par méconnaissances ou sois-disant gains de temps de développement.

Il en résulte des appels grossissant et redondants à des scripts externes ou a de grosses librairies dont les fonctions sont dans la majorité des cas à peine utilisées à 5% dans le site.

Certains travaillent désormais sur des bibliothèques javascript présentant la possibilité de n'embarquer que le strict nécessaire... 17 1 Cela démontre juste que les mauvaise pratiques de développement web prennent le dessus avec l'abus de frameworks et autre fioritures.De plus en plus les développeurs empilent des frameworks et des plugins par méconnaissances ou sois-disant gains de temps de développement.Il en résulte des appels grossissant et redondants à des scripts externes ou a de grosses librairies dont les fonctions sont dans la majorité des cas à peine utilisées à 5% dans le site.Certains travaillent désormais sur des bibliothèques javascript présentant la possibilité de n'embarquer que le strict nécessaire... Membre régulier https://www.developpez.com Envoyé par Sodium Envoyé par



Donc cela fait quoi, environ 36.970 de scraping par des bots comptabilisées dans ce fameux compteur ?



C'est mathématique, s'il y avait un vrai public pour tes repositories, il y aurait de l'activité dessus, des questions, des issues, des propositions d'améliorations...

Je suis donc désolé de t'annoncer que tu maintiens tes repositories pour toi seul. Ah oui, effectivement, désolé j'ai cherché un compteur de le header, dans les insights mais je n'avais pas pensé à chercher dans le détail du fichier, d'autant qu'après vérification il est plutôt rare de trouver ce fameux compteur sur les githubs (peut-être que les autres développeurs n'essayent pas de jouer à qui a la plus grosse ?).Donc cela fait quoi, environ 36.970 de scraping par des bots comptabilisées dans ce fameux compteur ?C'est mathématique, s'il y avait un vrai public pour tes repositories, il y aurait de l'activité dessus, des questions, des issues, des propositions d'améliorations...Je suis donc désolé de t'annoncer que tu maintiens tes repositories pour toi seul.

C'est dommage, parce que tu as des choses intéressantes à partager, mais tu es tellement arrogant et refuses tellement d'échanger que ça gâche tout. Moi qui me convertis aujourd'hui exclusivement à l'Info, c'est le genre de discussion qui m'intéresse beaucoup. Mais tu fermes tout débat parce que tu penses avoir raison et que toute personne s'opposant à toi est demeurée.



Conforte-toi en te disant que le fait d'être à contre-courant te rend intéressant et prouve que tu as raison. Mais sans critiquer ton point de vue (puisque ça ne sert à rien) permets-moi de te dire que c'est une très mauvaise façon de discuter et de progresser avec une discussion. 9 0 Sérieusement, tu postes depuis le début de la semaine à toutes les heures de la journée, sans avoir proposé d'autres lignes de code qu'un ou deux prototypes, et tu te permets de te moquer? Venant d'un gars qui, en plus, affirme que ce que devient son code après interprétation ne l'intéresse pas, c'est un peu limite.C'est dommage, parce que tu as des choses intéressantes à partager, mais tu es tellement arrogant et refuses tellement d'échanger que ça gâche tout. Moi qui me convertis aujourd'hui exclusivement à l'Info, c'est le genre de discussion qui m'intéresse beaucoup. Mais tu fermes tout débat parce que tu penses avoir raison et que toute personne s'opposant à toi est demeurée.Conforte-toi en te disant que le fait d'être à contre-courant te rend intéressant et prouve que tu as raison. Mais sans critiquer ton point de vue (puisque ça ne sert à rien) permets-moi de te dire que c'est une très mauvaise façon de discuter et de progresser avec une discussion. Membre à l'essai https://www.developpez.com



Ne ré-inventez plus la roue! ou plustot la tarte au citron, laissez faire des industriels qui savent mieux que vous comment faire!

En plus cela permet d'uniformiser le gout et d'éviter des les disparités entre vos enseignes, cela permet de servir le client plus vite et moins cher, et soyez certains qu'il se fiche de ce qu'il y a dedans.

Les pâtissiers qui ne l'utilisent pas en ce siècle où nous sommes sont tout simplement des INCOMPÉTENTS! J'en connais qui a essayé lui même et il s'est mis du jus de citron dans l'oeuil et il en est mort!

En plus il y a pleins de crèmes et de sauces possibles, tu peux ajouter de la harissa ou de la sauce béarnaise pour couvrir tous les besoins!



Moi je bosse avec des vrais pros, on travaille sur des macs qu'on ne peux ni ouvrir ni réparer, et a midi on mange des repas tout fait dans des boites. Ca c'est des vrais pros! 9 1 J'ai enfin trouvé le bon endroit pour trouver ce que je cherche ! Je dois en effet trouver quelqu'un capable de vendre la crème citron toute-faite de chez Metro pour tartes au citron à des restaurants gastronomiques.Ne ré-inventez plus la roue! ou plustot la tarte au citron, laissez faire des industriels qui savent mieux que vous comment faire!En plus cela permet d'uniformiser le gout et d'éviter des les disparités entre vos enseignes, cela permet de servir le client plus vite et moins cher, et soyez certains qu'il se fiche de ce qu'il y a dedans.Les pâtissiers qui ne l'utilisent pas en ce siècle où nous sommes sont tout simplement des INCOMPÉTENTS! J'en connais qui a essayé lui même et il s'est mis du jus de citron dans l'oeuil et il en est mort!En plus il y a pleins de crèmes et de sauces possibles, tu peux ajouter de la harissa ou de la sauce béarnaise pour couvrir tous les besoins!Moi je bosse avec des vrais pros, on travaille sur des macs qu'on ne peux ni ouvrir ni réparer, et a midi on mange des repas tout fait dans des boites. Ca c'est des vrais pros! Membre éclairé https://www.developpez.com Envoyé par Sodium Envoyé par Alors de un c'est parfaitement faux et encore un signe supplémentaire de ton ignorance, de deux je ne permets pas de préjuger de la qualité de mon code, merci bien. ET sémantique et s'il est bien minifié, à peine plus lourd que le JSON.



Envoyé par Sodium Envoyé par Non, c'est avant tout pour améliorer l'expérience utilisateur



Envoyé par Sodium Envoyé par

L'avantage majeur d'Angular est d'être pensé pour TypeScript. Au delà de ses fonctionnalités, on a donc un code de bien meilleure qualité et beaucoup plus maintenable. Je ne crache pas sur les technos concurrentes d'Angular, je crache sur JavaScriptL'avantage majeur d'Angular est d'être pensé pour TypeScript. Au delà de ses fonctionnalités, on a donc un code de bien meilleure qualité et beaucoup plus maintenable.



Envoyé par Sodium Envoyé par Pareil que ton collègue neuneu plus haut, tu n'as pas la moindre idée de comment je code, tu ferais donc mieux de t'abstenir de faire des jugements hâtifs.



Je crois que si tu veux vraiment pouvoir progresser, dans ce métier, il va falloir que tu apprennes à accepter la critique, accepter que tes certitudes ne sont peut-être pas fondées... et, surtout, à apprendre les bases du langage, avant d'utiliser des frameworks. 8 0 Quand tu fais de l'HTML propre, si, il est super légeret s'il est bien minifié, à peine plus lourd que le JSON.Améliorer l'expérience utilisateur ? hormis le mode hors-ligne, pouvant aisément être réalisé à partir d'éléments DOM aussi.Mais même en pur JS, tu peux faire des choses très propres et facilement maintenables... suffit d'apprendre... mais évidemment, saisir toutes les subtilités du langage, ça prend des années.Il n'y a pas besoin de voir la qualité de ton code, tes propos, ton attitude, tes arguments, y a même pas 3 années d'expérience, là-derrière... dans le cas contraire, il y a un sérieux problème.Je crois que si tu veux vraiment pouvoir progresser, dans ce métier, il va falloir que tu apprennes à accepter la critique, accepter que tes certitudes ne sont peut-être pas fondées... et, surtout, à apprendre les bases du langage, avant d'utiliser des frameworks. Expert éminent sénior https://www.developpez.com



Envoyé par Sodium Envoyé par Tes messages sont de plus en plus des attaques ad hominem et de moins en moins du débat de fond Mais tout va bien hein



Envoyé par Sodium Envoyé par Encore une fois je n'ai rien à prouver. Je sais que je suis un bon dev



Envoyé par Sodium Envoyé par je ne vais donc pas perdre du temps à répondre à cela. 8 0 Lcf.vs a complètement raison, si vous pouviez cesser de raconter absolument n'importe quoi avec autant d'aggressivité ça serait pas mal ça commence à devenir vraiment pénible à lire.Tu pollues chaque page de chaque débat sur JavaScript depuis des mois en traitant tous tes contradicteurs de débutants et d'incompétentsMais tout va bien heinTu as le niveau standard d'un développeur lambda avec quelques années d'expériences qui commence à se sentir à l'aise avec la POO et qui se sent plus pisser parce qu'il a compris deux ou trois concepts. Pas de quoi péter une braguette. En revanche tu as un gros gros problème d'égo.Oui tu ferais bien. Rédacteur/Modérateur https://www.developpez.com

Je connais de nombreux professionnels qui se sont montés leur propre framework modulaire qui n'embarque que le strict minimum nécessaire en fonction du site.



C'est en effet la solution de facilité pour de nombreux développeurs à l'heure actuelle que de s'en remettre aux frameworks disponibles afin de répondre aux exigences immédiates imposées par la hiérarchie ou la compétitivité.

Chaque framewok ayant sa propre orientation, on en arrive même parfois à des utilisations combinées de plusieurs frameworks afin de couvrir tous les besoins...



Je suis souvent attristé de voir les annonces des offres d'emploi qui exigent des connaissances sur tel ou tel framework parfois exotique... 8 1 @Sodium: Un jugement à l'emporte-pièces.Je connais de nombreux professionnels qui se sont montés leur propre framework modulaire qui n'embarque que le strict minimum nécessaire en fonction du site.C'est en effet la solution de facilité pour de nombreux développeurs à l'heure actuelle que de s'en remettre aux frameworks disponibles afin de répondre aux exigences immédiates imposées par la hiérarchie ou la compétitivité.Chaque framewok ayant sa propre orientation, on en arrive même parfois à des utilisations combinées de plusieurs frameworks afin de couvrir tous les besoins...Je suis souvent attristé de voir les annonces des offres d'emploi qui exigent des connaissances sur tel ou tel framework parfois exotique... Membre éclairé https://www.developpez.com Envoyé par Mograine Envoyé par Sinon concernant l'article : "multiplication (du poid de JS) par trente en quinze ans", sachant qu'on est passé du 56k au 20mo (et je ne prend même pas en compte la fibre pas assez généralisée), c'est une multiplication par 350 des débits moyens, et je vous épargne le % de progression concernant les performances des processeurs, il faut donc relativiser les chiffres qui sont ici présentés ce n'est pas une raison valable pour ne pas optimiser ses sites et applications !



La raison ? la consommation électrique engendrée par tout cela, d'autant plus à notre époque, avec la multiplication des utilisateurs, des services tournant en continu et en temps réel, ... c'est juste criminel, de ne s'en soucier. 7 0 Je voulais tout de même réagir sur ce point : on s'en contrefiche, de l'augmentation de bande passante, de l'augmentation de puissance de calcul de nos appareils...La raison ? la consommation électrique engendrée par tout cela, d'autant plus à notre époque, avec la multiplication des utilisateurs, des services tournant en continu et en temps réel, ... c'est juste criminel, de ne s'en soucier. Membre expérimenté https://www.developpez.com

- Peut on faire une webapp performante en utilisant JavaScript : oui

- Peut on faire la même webapp non performante en utilisant JavaScript : oui

- A optimisation égale, est-ce qu'une webapp avec framework sera plus lourde que la même webapp sans framework : oui

- Est-ce que les quelques kB gagnés valent les dizaines (centaines?) d'heures nécessaires à tout recoder : probablement pas dans 99% des cas



Si tout le monde suit quelques notions très simples comme éviter les opérations du DOM inutiles (re-rendering, refreshing), ne pas faire d'appels réseau inutiles (throttling, caching), et utiliser gzip pour l'envoi initial des fichiers, ça va aller beaucoup mieux peu importe quel framework ou non vous utilisez.



Le seul vrai problème de mon point de vue c'est node_modules. C'est aujourd'hui impossible pour n'importe quelle petite/moyenne équipe de s'assurer qu'il n'y a pas une pile de daube là dedans tellement il y a de dépendances. J'ose espérer que quand le code JS pré ES6 sera mort et enterré on pourra revoir tout ça et se passer des dépendances qui ne font rien que ne peux pas faire le JS moderne. Je viens d'ouvrir mon node_modules d'un projet en court par curiosité et entre les modules qui font la même chose et ceux qui font des opérations sur une ligne. Par exemple j'en ai une qui prend une valeur en entrée, si c'est un array ça retourne la valeur et si non ca retourne un array contenant la valeur ( 6 0 Ce débat est interminable et le pire c'est que tout à déjà été dit :- Peut on faire une webapp performante en utilisant JavaScript : oui- Peut on faire la même webapp non performante en utilisant JavaScript : oui- A optimisation égale, est-ce qu'une webapp avec framework sera plus lourde que la même webapp sans framework : oui- Est-ce que les quelques kB gagnés valent les dizaines (centaines?) d'heures nécessaires à tout recoder : probablement pas dans 99% des casSi tout le monde suit quelques notions très simples comme éviter les opérations du DOM inutiles (re-rendering, refreshing), ne pas faire d'appels réseau inutiles (throttling, caching), et utiliser gzip pour l'envoi initial des fichiers, ça va aller beaucoup mieux peu importe quel framework ou non vous utilisez.Le seul vrai problème de mon point de vue c'est node_modules. C'est aujourd'hui impossible pour n'importe quelle petite/moyenne équipe de s'assurer qu'il n'y a pas une pile de daube là dedans tellement il y a de dépendances. J'ose espérer que quand le code JS pré ES6 sera mort et enterré on pourra revoir tout ça et se passer des dépendances qui ne font rien que ne peux pas faire le JS moderne. Je viens d'ouvrir mon node_modules d'un projet en court par curiosité et entre les modules qui font la même chose et ceux qui font des opérations sur une ligne. Par exemple j'en ai une qui prend une valeur en entrée, si c'est un array ça retourne la valeur et si non ca retourne un array contenant la valeur https://www.npmjs.com/package/arrify ). Membre éclairé https://www.developpez.com Envoyé par SimonDecoline Envoyé par Je suis d'accord avec Sodium. Les quelques ko des pages web sont complètement insignifiants à côté de la moindre pub, image de fond, vidéo youtube, VM/conteneur pour le moindre micro-service, etc, etc... pour absolument tout ce qu'on fait.



Ce n'est pas parce qu'il y a de plus gros pollueurs que tu ne pollues pas. Ce n'est donc pas une excuse pour faire sa part, réduire son empreinte.



Dès lors que tu crées quelque chose, il te faut veiller à ce tout soit optimal. Si chacun faisait cela, on aurait même pas besoin d'avoir ce débat. 6 0 L'écologie c'est un effort et une prise de conscience...Ce n'est pas parce qu'il y a de plus gros pollueurs que tu ne pollues pas. Ce n'est donc pas une excuse pour faire sa part, réduire son empreinte.Dès lors que tu crées quelque chose, il te faut veiller à ce tout soit optimal. Si chacun faisait cela, on aurait même pas besoin d'avoir ce débat. Membre éclairé https://www.developpez.com Envoyé par SimonDecoline Envoyé par Ca c'est le discours à deux balles des "gros" qui veulent reporter leur faute sur les "petits", genre les cyclistes polluent avec leurs roues en plastique, il faut leur imposer des roues en bois, et pendant ce temps là on ne fait rien contre les avions, paquebots, camions, etc.



C'est justement là que l'informatique se distingue de la plupart des vecteurs de pollution, c'est son interconnexion.



Envoyé par Sodium Envoyé par Une application React ou Angular permet justement de limiter au stricte minimum les échanges de données une fois que la page est chargée. Bref, tu es complètement à côté de la plaque.

Et vu que ces technologies sont utilisées principalement pour des web-apps type Facebook, cacher tout le contenu côté serveur n'a tout simplement aucun sens.



Là où réside la différence, c'est dans la quantité de code que tu exécutes côté client, le coût du calcul de génération des éléments, le coût du redraw/reflow, dans tout ce que ça prend en mémoire, dans le délai de réactivité de tes pages, car TOUT est généré à chaque affichage.



Crois-moi, à mes tout débuts (tu peux même aller consulter mes plus anciens topics pour vérifier, si tu veux), j'expérimentais justement à fond la génération, côté client. Je trouvais cela tellement plus simple... mais j'en suis revenu, après avoir mesuré combien la batterie de mon PC de l'époque en était impacté.



Pourtant, je ne puis te donner entièrement tort, il y a bien, avec ce genre de stratégie, une différence de coût énergétique... côté serveur, mais c'est parce que ce coût est reporté et multiplié, côté client, par le nombre d'affichages.



C'est justement pour ça que les "gros" l'utilisent... ce n'est que pour réduire LEURS COÛTS !!! 6 0 Je n'ai strictement rien d'un "gros", comme tu dis... néanmoins, je suis un concepteur d'outils de dev (bibliothèques/frameworks)... sachant que mes outils sont, au minimum, utilisés par des dizaines de milliers de développeurs, qui eux mêmes font d'autres outils ou sites avec, qui seront utilisés, au final, par un nombre incalculable de clients finaux... ben, même un tout petit changement peut avoir un énorme impact.C'est justement là que l'informatique se distingue de la plupart des vecteurs de pollution, c'est son interconnexion.Si tu apprenais à faire de l'HTML propre et sémantique... il serait presque aussi léger que le JSON que tu transfères avec ta crasse qu'est Angular.Là où réside la différence, c'est dans la quantité de code que tu exécutes côté client, le coût du calcul de génération des éléments, le coût du redraw/reflow, dans tout ce que ça prend en mémoire, dans le délai de réactivité de tes pages, car TOUT est généré à chaque affichage.Crois-moi, à mes tout débuts (tu peux même aller consulter mes plus anciens topics pour vérifier, si tu veux), j'expérimentais justement à fond la génération, côté client. Je trouvais cela tellement plus simple... mais j'en suis revenu, après avoir mesuré combien la batterie de mon PC de l'époque en était impacté.Pourtant, je ne puis te donner entièrement tort,C'est justement pour ça que les "gros" l'utilisent... ce n'est que pour réduire Poster une réponse Signaler un problème

