Discussion :

[Bill Fassinou]

Les frameworks Web détruisent-ils vraiment les performances du Web ou l’expérience utilisateur ?
Ils placeraient la satisfaction des développeurs au-dessus des utilisateurs

Êtes-vous d’avis que les frameworks, en particulier les frameworks JavaScript, aient peu à peu détruit les performances Web ou l’expérience utilisateur ? C’est là la thèse que défend un billet de blogue d'un gamer et journaliste portant le pseudo « cheatmaster30 » travaillant sur Gaming Reinvented, une plateforme pour les nouvelles et les éditoriaux sur le jeu. Il estime que ces dernières années, les performances du Web ont baissé à cause de l’avènement des frameworks Web, comme React et Vue.js, et les applications web monopage (single-page application (SPA)) qui privilégient les développeurs à l’expérience utilisateur.

C’est peut-être un sujet qui revient plus souvent, faut-il utiliser les frameworks JS ou pas ? L’écosystème JavaScript a évolué ces dernières années plus que jamais et il existe désormais des dizaines de frameworks JS front-end comme back-end. Cependant, des voix s’élèvent pour dire que JavaScript est responsable de la lenteur des sites Web, notamment le JavaScript de tiers. Selon cheatmaster30, les frameworks JS ont rendu la page Web moyenne désormais plus grande que jamais, les pages de 2 à 3 Mo étant plus courantes que jamais.

« C'est un fléau sur Internet, et beaucoup de personnes blâment les frameworks dans leur ensemble. Après tout, beaucoup de ces sites sont construits avec des frameworks JavaScript même quand ce n'est pas vraiment nécessaire (comme avec beaucoup de sites de news). Et un bon nombre d'entre eux utilisent aussi Bootstrap pour le CSS », a-t-il dit. Toutefois, selon lui, il ne s’agit pas là du vrai problème. « Je pense plutôt que le problème est l'état d'esprit des développeurs et des concepteurs dans de nombreuses entreprises », a-t-il déclaré.

Les frameworks auraient rendu les développeurs et les ingénieurs moins soucieux de leurs utilisateurs ou de leurs clients que par le passé, plaçant leur satisfaction au-dessus des usagers de leurs applications. « Je crois fermement que beaucoup de développeurs et d'ingénieurs logiciels placent leur satisfaction professionnelle au-dessus de leurs utilisateurs ou de leurs clients », a-t-il déclaré, ajoutant que c’est ce qui a conduit les développeurs vers toutes ces pratiques douteuses, ainsi qu'à un manque d'intérêt pour ce qui compte.

Par exemple, il estime que les systèmes de construction lourds comme Webpack et des dizaines de composants NPM sont utilisés pour faire gagner du temps et de l'effort aux développeurs, sans tenir compte des kilo-octets (ou même des méga-octets) de JavaScript qui s'ajoutent au produit fini. Des composants tiers sont apportés avec des quantités importantes de CSS et de JavaScript, simplement pour éviter d'avoir à construire ces composants à partir de zéro, la taille de la page étant damnée (fonctionnalités inutiles, chargement lent, etc.).

Dans d’autres cas, cheatmaster30 allègue que les développeurs choisissent d’utiliser un langage ou une technologie pour effectuer un travail simplement parce qu’elle est “cool”, et non parce qu’elle est la mieux adaptée pour faire le travail. « Regardez tous ces sites de nouvelles reconstruits comme des SPA avec des frameworks JS très résistants. Ils n'ont pas besoin d'être faits comme ça, et ils ne devraient probablement pas l'être », a-t-il déclaré. Par ailleurs, il ajoute que ces choix ne s’observent pas uniquement chez les développeurs.

Selon lui, il n'y a pas que les développeurs qui sont ainsi. Il estime que tout le monde est comme ça dans la chaîne de commandement. Les gestionnaires, les PDG, les investisseurs, l'équipe de marketing, les ventes, etc. Tout le monde veut avoir l'air bien devant ses pairs ou devant les hauts dirigeants, et tout se termine par une surcharge de travail et une lourdeur qui en résulte, ce qu'il faut changer. Le client ou l'utilisateur doit être en priorité, et non les personnes qui travaillent sur le produit ou encore l'entreprise elle-même.

De plus, dans une certaine mesure, les utilisateurs comprennent cela. Il estime qu’on le voit bien par le nombre de produits et de services “merdiques” qui finissent par l'emporter sur des rivaux plus exigeants. Toutefois, cela n'est pas le cas de tous les services. « Regardez Craig's List. C'est apparemment moche, mais la technologie utilisée n'est probablement pas un sujet de conversation très important », a-t-il déclaré.

«  Il en va de même pour Hacker News et pour l'ancienne version de Reddit ou pour de nombreux jeux populaires en général comme Minecraft ou Wii Sports ou Tetris », a-t-il ajouté. Il estime qu’aucun de ces jeux n'est particulièrement fantaisiste dans tous les sens du terme, mais ils se sont tous vendus à des millions d'exemplaires néanmoins.

« Alors, créateurs, arrêtez de vous focaliser sur votre CV ou votre convenance personnelle. Cessez de faire passer vos propres intérêts avant ceux de vos utilisateurs et de gaspiller des centaines de kilo-octets pour des choses dont personne ne se soucie. Vous n'êtes probablement pas Facebook ou Google, et vous ne devriez pas concevoir ou construire des choses comme si c'était le cas. Faites plutôt ce qui est nécessaire pour le travail et offrez une expérience que l'utilisateur aimera utiliser, avec aussi peu de ressources que nécessaire. Faites cela, et vos utilisateurs et clients vous en remercieront », a-t-il conclu.

Source : cheatmaster30

Et vous ?

Quel est votre avis sur le sujet ?
Les frameworks Web détruisent-ils vraiment les performances du Web ?
Quelles sont votre position et votre stratégie sur les frameworks ?

Voir aussi

Le langage JavaScript est-il responsable de la lenteur des sites Web de nos jours ? Oui, selon un expert

État de JavaScript en 2019 : les développeurs aiment un peu plus React, Angular est en déclin, un groupe de développeurs pensent que JS est « trop complexe »

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

[Invité]

Quel est votre avis sur le sujet ?

Que cheatmaster30 n'a pas dû connaitre l'époque de Flash et des applets Java...

[Edrixal]

Quel est votre avis sur le sujet ?
Les frameworks Web détruisent-ils vraiment les performances du Web ?
Quel est votre position et votre stratégie sur les frameworks ?

Je vois dans la boite informatique ou je suis, ils ont décider que le site internet devait être gérer par... Le pôle commercial !
Aucune des personnes en question n'a jamais taper une ligne de code. Ils ont donc choisie de passer par un CMS... WordPress.

Bien sur ils voulais faire original. Donc ils ont choisie un thème spécial, ajouter plein de truc à droite à gauche, en ont virer la majorité, ect...
Au final, ils ont sortie un jolie bébé, beau à voir visuellement, mais qui permet de commencer à naviguer au bout de 3/4s et qui s'affiche au complet en 10/12s.

La faute aux nombreux script.
Mais bon la gestion commercial sont content, maintenant ils peuvent ajouter une page ou modifier les informations sur nos produits directement ! Au prix d'un site difficilement navigable...

Tout ça pour dire que c'est parfois plus compliquer que le choix d'un dev. Les CMS permettent à n'importe qui de créer un site, des personnes complétement amateur qui n'y connaissent pas grand chose et font ce qu'ils peuvent pour avoir un jolie visuel.
Et j'ai beau eu leur expliquer qu'il vaut mieux avoir un site avec un visuel moyen (mais propre !) qui est rapide, plutôt qu'un jolie site qui rame, mes arguments sont tomber dans le néants. Je ne suis donc pas étonner. Aux utilisateurs de faire savoir qu'ils préfère les sites rapide. Après tout, nous avons enregistrer une augmentation des visites sur notre site internet depuis (Ainsi qu'une durée de visite plus longue ), donc finalement mon avis de dev qui préfère un site rapide, c'est peut être pas vraiment ce que recherche le client

[23JFK]

Je vois dans la boite informatique ou je suis, ils ont décider que le site internet devait être gérer par... Le pôle commercial !
Aucune des personnes en question n'a jamais taper une ligne de code. Ils ont donc choisie de passer par un CMS... WordPress.

Bien sur ils voulais faire original. Donc ils ont choisie un thème spécial, ajouter plein de truc à droite à gauche, en ont virer la majorité, ect...
Au final, ils ont sortie un jolie bébé, beau à voir visuellement, mais qui permet de commencer à naviguer au bout de 3/4s et qui s'affiche au complet en 10/12s.

La faute aux nombreux script.
Mais bon la gestion commercial sont content, maintenant ils peuvent ajouter une page ou modifier les informations sur nos produits directement ! Au prix d'un site difficilement navigable...

Tout ça pour dire que c'est parfois plus compliquer que le choix d'un dev. Les CMS permettent à n'importe qui de créer un site, des personnes complétement amateur qui n'y connaissent pas grand chose et font ce qu'ils peuvent pour avoir un jolie visuel.
Et j'ai beau eu leur expliquer qu'il vaut mieux avoir un site avec un visuel moyen (mais propre !) qui est rapide, plutôt qu'un jolie site qui rame, mes arguments sont tomber dans le néants. Je ne suis donc pas étonner. Aux utilisateurs de faire savoir qu'ils préfère les sites rapide. Après tout, nous avons enregistrer une augmentation des visites sur notre site internet depuis (Ainsi qu'une durée de visite plus longue ), donc finalement mon avis de dev qui préfère un site rapide, c'est peut être pas vraiment ce que recherche le client

Connaissant ce genre de spécimens, ils travaillent sur des machines surpuissantes par rapport à la moyenne des utilisateurs et forcément siglées Apple, pour être bien, ils font les tests en offline. Bref, tout pour ne pas se rendre compte du problème inhérent à la surcharge inutile des pages web en scripts voire images en ultra-HD redimensionnées en icônes sur le navigateur du client.

[daerlnaxe]

J'ai eu développé il y a longtemps en php, mêlant du javascript. et un peu de flash... le flash me servait pour ma bannière et un menu bouton. (Un bouton avec 4 fonctions, aide contextuelle au lieu de 4 boutons), c'était vers début 2000 sur des forums vbb. En fait je me basais sur le forum et de là je créais des sections entières qui n'étaient plus en rapport avec les interfaces de vbb, et que je dédiais totalement à une fonction, c'était pas mal, pas lourd je trouve surtout les connexions de l'époque... Tout était fait maison assez en avance par rapport à ce qu'on croisait. Ca prenait beaucoup de temps, rien de ce que je ne mettais n'avait été testé avant, de toute façon j'aurais refusé d'implanter du code que je ne connaissais pas de bout en bout... peut être de la paranoïa, mais je cherchais vraiment à savoir exactement si je prenais du code ailleurs ce que ça faisait et selon de l'optimiser en fonction de mes besoins.

Il y a longtemps que j'ai stoppé tout ça, probablement 10 ans (vie familiale et c'est pas mon job). J'ai constaté que les pages webs étaient de plus en plus lourdes, je suis en fibre pourtant, j'ai des bloqueurs dont certains pour ne pas charger forcément tout car certaines pages sont des monstres et pour rien. Pire car ça je continue, je gère souvent dépannage évolution de pcs... un peu à droite et à gauche mais aussi du coup dans les fonctions que j'ai assuré grâce au fait que j'ai réussi à le faire valoriser.. donc gestion de +300 machines sur 3 postes que j'ai occupé.... Je suis consterné de voir des machines qui ont à peine 10 ans, ramer comme pas possible pour afficher certains sites récents. Ce n'est normalement QUE internet et franchement je me demande parfois si certains en ont conscience... c'est peut être moi qui vieillit mal, mais de base pour moi internet est censé surtout servir à se documenter.. et de l'autre côté jouer en réseau. Mais j'attends pas d'un navigateur qu'il lance des applis en fait et encore moins qu'une page bombarde un déluge de choses... c'est sur que certains sites affichent un coup de vieux, mais ils sont bien fonctionnels et agréables. Alors je conçois que ça ne motive pas tout le monde de rajouter chaque chose manuellement, etc.... et comme expliqué je ne programme plus, donc je ne sais pas comment en ce moment ça se passe, mais si effectivement c'est de rajouter des gros blocs programmés par d'autres, pour obtenir une partie sans se soucier d'optimiser en effet il y a un problème. D'autant que tout le monde n'est pas fibré, mr JeanRaoul en adsl bas de gamme au fond du village n'appréciera pas vraiment. En tout cas moi pas, n'étant pas très patient et faisant pas mal de recherches je peux avoir 25 onglets sans soucis, d'ailleurs j'ai du installer un add on sur mon navigateur pour les coller en sommeil vu que certains continuent en dépit de ne pas etre affichés à occuper de l'espace en mémoire... ça aussi ça pose soucis. Alors c'est peut être du côté du navigateur que le problème réside...

J'ajoute un dernier point, ça serait pas impossible en effet que le fait de pouvoir en assemblant comme un patchwork voire en ayant quasiment une solution prête en peu de temps ça ait permis à beaucoup de se lancer là où il fallait bien mettre les mains dans le cambouis avant. J'ai vu ça avec un collègue qui ne programmait jamais et qui s'est mis free-lance, moi je commençais ma vie de père donc je commençais à plus avoir le temps et quand on discutait il me parlait Chinois, il a monté un paquets de sites sans vraiment connaitre grand chose en programmation. A l'époque je me disais que c'était pas mal pour des débutants, des petits sites, je pensais que ça allait se limiter à ça en fait. Si c'est démocratisé, effectivement des dérives pourraient expliquer les problèmes.

[dfiad77pro]

Il y'a largement moyen d'optimiser du React/Angular coté exécution

Le soucis c'est simplement que le chargement d'une page simple sera toujours plus lent car ça pése plus lourd.

Mais cela dit je relativise, j'ai conçus des applis web de 3-4 Mo (bundle js) en react/Typescript .
Vous me direz c'est lourd ! oui, mais derrière c'est une vrai appli avec pleins d'écrans, pas un site. l'équivalent client lourd pése 120 mo (java swing).

Donc pas de miracle, j'ai aussi vu des appli Reac/Angular métier non maitrisés de 50 mo !! Et la on te sort le lazy loading de dépendance qui est une vrai plaie à implémenter


Bref oui à React/Angular, etc , mais pour des vrais applications, pas pour des sites Webs classiques, et avec de bons dev pour cadrer techniquement.

Moralité ( ce n'est que mon avis ), quand on utilise une dépendance npm externe d'un composant UI, il faut l'encapsuler dans un Framework pour pouvoir revenir en arrière, faut pas la copier coller direct. (combien je vois de projets utiliser 2-10 composants combo/select avec 10 libs différentes )

[Mat.M]

Les frameworks Web c'est des véritables usines-à-gaz que l'on ne peut optimiser.
Vous feriez mieux de créer un programme en C qui ouvre bêtement des sockets pour échanger les données avec un serveur...ça doit peser quelques dizaines d'octets en mémoire
Avec un programmen en langace C on peut optimiser à fond.

Rien qu'un Windows "à vide" consomme des milliers d'instructions CPU par seconde et une quantité de mémoire de plus en plus grande mais bien sûr apporte son lot de fonctionnalités supplémentaires.

c'est exact c'est le rôle du Kernel et de kernel.dll

Je pense que la cause est surtout du côté des clients que des devs. Perso, plusieurs fois, j'aurais voulu coder un site moi-même, mais le client voulait absolument Wordpress... Dans ce cas, on se plie à la demande, bien qu'il me semblait évident qu'un site plus simple aurait été bien plus performant...

il fallait être plus "force de proposition" dans ce cas-là

[Patrick Ruiz]

« L’utilisation incessante de frameworks JavaScript de pointe a contribué à rendre le Web moins accessible », d’après Easy Laptop Finder
Selon lequel ces derniers détruisent les performances des sites Web

Le langage JavaScript (JS) est présent sur tous les sites Internet au travers de divers frameworks dont se servent les développeurs Web. Cela vient néanmoins avec un coût étant donné que ce langage s’exécute côté client (sur le PC de l’internaute) : la lourdeur des sites qui découle de l’utilisation abusive de frameworks. C’est une redite de la prise de position des têtes derrière la plateforme en ligne Easy Laptop Finder selon laquelle « L’utilisation incessante de frameworks JavaScript de pointe a contribué à rendre le Web moins accessible. »

L'utilisation incessante JavaScript de pointe a contribué à rendre le web moins accessible, en affectant de manière disproportionnée les utilisateurs dont les appareils et les conditions de réseau sont incapables (1) de télécharger les énormes charges utiles associées à ces frameworks et (2) de gérer la mémoire requise pour exécuter le code du framework dans le navigateur. L'accent mis sur la création d'applications hautement interactives entraîne une coupure d'accès au Web de certains internautes.

Pire encore, les personnes qui ont tendance à posséder des appareils moins puissants et celles qui vivent dans des zones où la connexion à l'internet est plus lente sont souvent celles qui pourraient bénéficier le plus d'un accès bien soutenu au web (par exemple, pour accéder aux services gouvernementaux).

La poussée de l'interaction peut également avoir eu un impact sur l'accessibilité du web : bien que les nouvelles chaînes d'outils de développement puissent inclure un certain niveau d'accessibilité, j'ai constaté que ce niveau était largement dépassé par les développeurs qui affichent et cachent des éléments sur toute la page sans se soucier des personnes qui utilisent des lecteurs d'écran.

Je ne suis pas sûr que nous y parviendrons un jour, mais une approche plus raisonnable consiste à donner la priorité à l'accès à l'information et à l'accessibilité plutôt qu'aux interfaces tape-à-l'œil. La seule chose que le Web nous apporte avant tout, c'est la prolifération et l'accès facile à l'information. Ne gâchons pas cela pour de nouvelles interfaces tape-à-l'œil

L’abus dans la mise à contribution React.JS, Vue.JS et autres Angular.JS rend les pages Web plus lourdes que jamais, avec des tailles de l’ordre du mégaoctet, difficiles à charger pour les tiers avec des connexions à bas débit

Selon cheatmaster30, les frameworks JS ont rendu la page Web moyenne désormais plus grande que jamais, les pages de 2 à 3 Mo étant plus courantes que jamais.

« C'est un fléau sur Internet, et beaucoup de personnes blâment les frameworks dans leur ensemble. Après tout, beaucoup de ces sites sont construits avec des frameworks JavaScript même quand ce n'est pas vraiment nécessaire (comme avec beaucoup de sites de news). Et un bon nombre d'entre eux utilisent aussi Bootstrap pour le CSS », a-t-il dit. Toutefois, selon lui, il ne s’agit pas là du vrai problème. « Je pense plutôt que le problème est l'état d'esprit des développeurs et des concepteurs dans de nombreuses entreprises », a-t-il déclaré.

Les frameworks auraient rendu les développeurs et les ingénieurs moins soucieux de leurs utilisateurs ou de leurs clients que par le passé, plaçant leur satisfaction au-dessus des utilisateurs de leurs applications. « Je crois fermement que beaucoup de développeurs et d'ingénieurs logiciels placent leur satisfaction professionnelle au-dessus de leurs utilisateurs ou de leurs clients », a-t-il déclaré, ajoutant que c’est ce qui a conduit les développeurs vers toutes ces pratiques douteuses, ainsi qu'à un manque d'intérêt pour ce qui compte.

Cheatmaster30 souligne que Webpack et des dizaines de composants NPM sont utilisés pour faire gagner du temps et de l'effort aux développeurs, sans tenir compte des kilo-octets (ou même des méga-octets) de JavaScript qui s'ajoutent au produit fini. Des composants tiers sont apportés avec des quantités importantes de CSS et de JavaScript, simplement pour éviter d'avoir à construire ces composants à partir de zéro, la taille de la page étant damnée (fonctionnalités inutiles, chargement lent, etc.).

Cheatmaster30 ajoute que les développeurs choisissent d’utiliser un langage ou une technologie pour effectuer un travail simplement parce qu’elle est “cool”, et non parce qu’elle est la mieux adaptée pour faire le travail. « Regardez tous ces sites de nouvelles reconstruits comme des SPA avec des frameworks JS très résistants. Ils n'ont pas besoin d'être faits comme ça, et ils ne devraient probablement pas l'être », a-t-il déclaré. Par ailleurs, il ajoute que ces choix ne s’observent pas uniquement chez les développeurs.

« Alors, créateurs, arrêtez de vous focaliser sur votre CV ou votre convenance personnelle. Cessez de faire passer vos propres intérêts avant ceux de vos utilisateurs et de gaspiller des centaines de kilo-octets pour des choses dont personne ne se soucie. Vous n'êtes probablement pas Facebook ou Google, et vous ne devriez pas concevoir ou construire des choses comme si c'était le cas. Faites plutôt ce qui est nécessaire pour le travail et offrez une expérience que l'utilisateur aimera utiliser, avec aussi peu de ressources que nécessaire. Faites cela, et vos utilisateurs et clients vous en remercieront », a-t-il conclu.

Même les bibliothèques JavaScript contribuent à cette situation comme l’illustre l’expérience de Gov.UK avec JQuery

En mars 2022, Matt Hobbs, Responsable du développement front-end de Government Digital Service (qui offre des plateformes, des produits et des services qui aident le gouvernement à devenir intégré, fiable et réactif aux besoins des utilisateurs notamment GOV.UK), a annoncé que GOV.UK avait supprimé sa dépendance jQuery. C'est un gros problème en ce qui concerne l'expérience utilisateur, car GOV.UK fournit des services et des informations en ligne pour le Royaume-Uni à grande échelle. Tout le monde n'utilise pas son MacBook Pro 2022 sur une connexion haut débit à couper le souffle. GOV.UK doit être accessible à tous, et cela signifie qu'il doit rester léger.

Voici quelques-uns des plus grands succès de Matt Hobbs sur ce que GOV.UK a remarqué en supprimant jQuery :

• Moins de temps de traitement frontal dans l'ensemble.
• 11 % de temps de blocage en moins au 75e centile.
• 10 % de temps de blocage en moins pour les utilisateurs au 95e centile. Ce sont des utilisateurs qui rencontrent des conditions de réseau et d'appareils très défavorables, et chaque gain de performance compte particulièrement pour eux.

L’équipe Bootstrap avait mis en avant des arguments similaires pour justifier l’abandon de JQuery

L'équipe Bootstrap qui a annoncé l'abandon de jQuery dès la première version alpha de Bootstrap 5 pour retourner à du pur JavaScript. Selon Mark Otto, créateur du framework et auteur du billet de blog qui a annoncé cette version alpha 1, « jQuery a apporté un accès sans précédent à des comportements JavaScript complexes pour des millions (milliards ?) de personnes au cours des quinze dernières années », et « peut-être qu'il a changé à jamais le JavaScript lui-même », mais le temps était venu pour l’équipe d’abandonner jQuery en tant que dépendance. Selon le billet, ce changement est rendu possible grâce aux progrès réalisés dans les outils de développement front-end et la prise en charge des navigateurs.

Le principal argument avancé pour justifier la suppression de jQuery dans Bootstrap v5 est que maintenant que plus de 95 % des fonctionnalités de jQuery sont désormais natives dans les navigateurs (les 5 % restants étant sans doute des bizarreries excessivement rétrocompatibles qui méritent d'être ignorées), ajouter une dépendance serait soit « stupide », soit un gaspillage de bande passante.

Dans la communauté des développeurs, les avis divergent quant à ce changement. Ceux qui l'ont bien accueilli reconnaissent que jQuery est l’une des bibliothèques les plus importantes de l’histoire JavaScript et a permis de créer de véritables applications Web. Ils estiment cependant que depuis lors, les différences entre les navigateurs se sont considérablement réduites et nous avons appris à créer des applications maintenables et évolutives de manière plus déclarative, grâce à des frameworks comme React, Angular et autres. Du coup, jQuery ne serait plus d'une grande utilité.

Source : ELF

Et vous ?

Les griefs mis en avant à l’encontre des frameworks JavaScript pour ce qui est du développement des sites Web sont-ils cohérents avec la réalité dont vous êtes au fait ?
Quelles sont les alternatives à ces frameworks sur lesquelles vous vous appuyez pour livrer à vos clients des sites Web dynamiques exempt des inconvénients qu’une mise à contribution de JavaScript entrainerait ?
Quels sont les langages et outils dont vous vous servez pour développer des sites Web dynamiques sans vous appuyer sur des frameworks et des bibliothèques JavaScript comme JQuery ? Quels sont les avantages de votre approche en comparaison de celle qui s’appuie sur JavaScript et ses bibliothèques ?

Voir aussi :

Prise en main d’ES6.Aperçu des principales fonctionnalités

Quelles sont les nouvelles fonctionnalités qui pourraient débarquer dans JavaScript en 2019 ? Un tour d'horizon des candidats pour ES2019

La version 12 de Node.js est disponible et serait 30 % plus rapide au démarrage que les versions précédentes

Apprendre à programmer en Node.js avec MongoDB : découvrir le paradigme de MongoDB axé sur les documents dans Node.js, un tutoriel proposé par IBM

[RenarddeFeu]

Le HTML5, le CSS sont des usines à gaz, pas JavaScript en particulier. Et le troll ultime, c'est qu'il faille maîtriser ces 3 langages pour sortir une page web potable.

Les ordinateurs sont infiniment plus puissants qu'en 1995. Les langages à markup apportent-ils encore quelque-chose ? Je ne pense pas !

Les navigateurs internet pourraient très bien être de simple serveurs d'affichage traitant un langage bas niveau quelconque. Ça serait beaucoup plus simple à standardiser.

[sebastiano]

Je vois dans la boite informatique ou je suis, ils ont décider que le site internet devait être gérer par... Le pôle commercial !
Aucune des personnes en question n'a jamais taper une ligne de code. Ils ont donc choisie de passer par un CMS... WordPress.

Bien sur ils voulais faire original. Donc ils ont choisie un thème spécial, ajouter plein de truc à droite à gauche, en ont virer la majorité, ect...
Au final, ils ont sortie un jolie bébé, beau à voir visuellement, mais qui permet de commencer à naviguer au bout de 3/4s et qui s'affiche au complet en 10/12s.

La faute aux nombreux script.
Mais bon la gestion commercial sont content, maintenant ils peuvent ajouter une page ou modifier les informations sur nos produits directement ! Au prix d'un site difficilement navigable...

Tout ça pour dire que c'est parfois plus compliquer que le choix d'un dev. Les CMS permettent à n'importe qui de créer un site, des personnes complétement amateur qui n'y connaissent pas grand chose et font ce qu'ils peuvent pour avoir un jolie visuel.
Et j'ai beau eu leur expliquer qu'il vaut mieux avoir un site avec un visuel moyen (mais propre !) qui est rapide, plutôt qu'un jolie site qui rame, mes arguments sont tomber dans le néants. Je ne suis donc pas étonner. Aux utilisateurs de faire savoir qu'ils préfère les sites rapide. Après tout, nous avons enregistrer une augmentation des visites sur notre site internet depuis (Ainsi qu'une durée de visite plus longue ), donc finalement mon avis de dev qui préfère un site rapide, c'est peut être pas vraiment ce que recherche le client

Tu peux avoir des performances exceptionnelles avec Wordpress, à condition de mettre 1 ou 2 développeurs sur le coup, qui écriront eux-même les lignes de code des modules nécessaires.

Autrement oui, en mode full modules contrib, Wordpress devient vite une usine à gaz imbitable. J'en ai eu l'expérience dans une autre boîte, comme toi : des CP qui préfèrent vendre un projet moins cher en faisant installer puis modifier de manière dégueulasse des modules contrib et un thème (lui aussi bourré de modules inutiles) pré-installé. Et à la fin, l'équipe doit passer 1 mois à améliorer sensiblement les performances (site chargé en 11 secondes à la base ). Soit le temps que ça aurait pris aux 2 devs et à l'intégrateur en question pour faire le taff eux-même et de manière optimale.

Quoiqu'il en soit, il faut TOUJOURS déléguer les questions techniques à des experts techniques. Laisser un pôle commercial gérer un site (ou une application en général), c'est courir à la catastrophe.

[thejoker31]

J'ai quelques réflexions à ce sujet:
d'une part veulent ils perdre toute la clientèle des seniors et autre GJ qui n'ont pas les moyens de changer leur PC pour des laptops?

d'autre part veulent ils faire vendre plus de harware?

au final n'y a t'il pas une perte de pouvoir d'achat pour le Ecommerce la base de leur business?

et par conséquent une migration vers des plateformes Ecommerce type Amazon?

les gagnants sont donc les mastodontes...

[Invité]

Je suis plutôt d'accord avec le constat mais pas vraiment avec les causes qu'il avance. Clairement aujourd'hui une grande partie des sites utilisant React/Angular/Vue ou autre framework front end n'en a au mieux strictement pas besoin et vraisemblablement ça lui fait du tord. Il ne faut pas oublier qu'a la base ces outils ont étés conçus pour gérer des applications du calibre de Facebook ou Gmail, faire son blog en React c'est un joli cas d'utilisation de bazooka pour tuer une mouche.

Aujourd'hui la plupart des personnes vivant dans les pays développés n'auront pas de problèmes à charger une application web de 2-3Mo, quitte à ce que ça prenne quelques secondes pour les mecs en bout de ligne en Lozère. Le problème c'est que dans un monde où il faudrait faire de plus en plus attention à l'utilisation des ressources, on se comporte en informatique comme les rois du pétrole des années 70 et là ou un site pourrait peser quelques kilooctets on colle un gros React de 1Mo+. Ça semble peu important au niveau individuel mais l'économie d'échelle au niveau du web pourrait être colossale.

Pour ce qui est des frameworks backend, il y en a pour tous les goûts mais là tendance est plutôt vers le micro framework depuis quelques années qui me semble être un bon compromis entre performance et maintenabilité, surtout que rien n'empêche de pré-générer ses pages et des les servir comme des fichiers statiques, et pour les contenus plus dynamiques se baser sur du JS et des API.

[darklinux]

Quel est votre avis sur le sujet ?

Que ce monsieur n ' a jamais connus les années 1990 au niveau du web avec les applets Java 1.0 /1.2 , active X etc . Javascript / Python ont permis une normalisation , Chrome , puisque c 'est le leader utilise le GPU pour accélérer , nous avons le MP4 , qui est très bien , un effort considérable par rapport au .WMV de triste mémoire , que ce monsieur , reprenne son MacBook Pro et code !

[kilroyFR]

Oui on peut toujours faire la meme chose en assembleur dans son coin et reinventer la roue carree.

Justement l'interet de ces frameworks (d'autant plus JS ou c'est assez rock n roll pour le dev), ils ont grand interet.
N'est ce pas le propre de l'informatique de faire des composants, mutualiser ? donc de creer des frameworks aboutis qui rendent les services attendus.

On en a bien dans ma boite, principalement des jeunes arrivants, qui bavent sur l'existant et veulent reinventer parce que plus malins que les autres.
Bootstrap et autres c'est de la merde ?... ben on voit comment leur projets depensent une energie folle a maintenir un code qu'ils ont ecrit et qui est une belle usine a merde dans laquelle personne ne veut mettre les doigts.
On a la chance d'avoir l'open source qu'on n'avait pas il y a 30 ans et qui permet des gains considerables en termes de recuperation de composants.
Ca c'est du concret, pas du pipeau de developpeur a l'ego surdimensionné.

Performances du WEB ? les materiels (PC, mobiles etc) n'ont jamais ete aussi surpuissants
Interactivité utilisateurs ? on n'a jamais ete aussi pres d'interface utilisateurs web proches des interfaces desktop rigides.

Non, le gars s'est trompé de siecle.

[tlt]

Je trouve aussi que les frameworks Web ont un peu réduit les performances du Web. C'est peut être parce qu'il y a qu'autres facteurs decisionnels à part la technique pure et donc le dev.
Par contre c'est tout le contraire au niveau expérience utilisateur. Il est plus accessible de remodeler l'experience utilisateurs en passant par des frameworks que plutôt sans. C'est plutôt difficile de recréer la roue à ce niveau là.

edit: ça se ressent beaucoup car là où je suis, je suis à 80% du temps sur de la 2G, mêm si là 4G est là mais pas partout; et la data se monnaye en Mo. Par exemple, il y a pas mal d'offre de 5Mo de data (mais je ne vais pas les citer , en tout cas pas directement ici ). Certaines pages bouffent aussi de la rame,en plus de la data, à cause de certains frameworks même si ils sont à jours et soi disant optimisés, alors que là où je suis, il y a encore beaucoup de téléphone à 1 coeur avec moins de 1Go de ram, parfois même sous android 4.1 ou moins. Et il y a encore pas mal de telephone avec des navigateurs Java (par exemple les telephones itel ).

[Sodium]

Ce discours est un peu le marronnier du développement web, et le discours ne tient pas très longtemps :

• les pages font aujourd'hui souvent plusieurs mo : et alors ? Déjà une fois que c'est chargé c'est chargé, une application one-page ne fait ensuite plus appel qu'à des api. Aujourd'hui on a la fibre optique, la 4g, bientôt la 5g, c'est pour s'en servir ou juste pour le plaisir de payer pour un service qu'on n'utilise pas ? L'auteur a-t-il seulement connu l'époque du 56k quand il fallait une éternité pour charger trois pauvres images ? Oui il y aura toujours les gens qui vivent au milieu de la brousse et ont une connexion moisie, mais si l'on se base toujours sur le maillon le plus faible d'une base d'équipements au lieu de chercher le meilleurs compromis on n'avance jamais
• la puissance pareil, n'importe quel smartphone est aujourd'hui plus puissant que les pc que la majorité des gens achètent chez Darty. C'est pour s'en servir ou pour le plaisir de faire tourner des benchmarks ?...
• ... d'autant que c'est dans l'autre sens qu'il faut voir les choses. Les applications ne sont pas plus lourdes magiquement à cause de l'utilisation de frameworks, elles sont plus lourdes parcequ'ils permettent de faire des choses plus complexes. On pourrait faire la même chose uniquement en jQuery, les manipulations du DOM seraient tout aussi lourdes
• pourquoi l'expérience du développeur ne serait-t-elle pas importante ? On est des humains, on a le droit de travailler dans des conditions correctes, ce qui jusqu'à il y a peu était pratiquement impossible en front-end. Ensuite, si l'application est buguée parce que la complexité du code le rend peu fiable, qui en paie le prix ? L'utilisateur. S'il faut trois fois plus de temps pour sortir des features parce que l'application est compliquée à maintenir et faire évoluer ? L'utilisateur

Quant à l'argument de l'économie de bande passante et donc l'écologie, il est assez ridicule, une minute de vidéo en streaming représentant probablement plus que tout le code qu'un utilisateur télécharge en un an.

[Invité]

Quant à l'argument de l'économie de bande passante et donc l'écologie, il est assez ridicule, une minute de vidéo en streaming représentant probablement plus que tout le code qu'un utilisateur télécharge en un an.

C'est juste faux, certes c'est le streaming vidéo qui fait péter les tuyaux aujourd'hui mais l'ordre de grandeur n'est absolument pas celui que tu avances. Le dernier rapport de Sandvine de 2019, qui est une référence dans ce domaine, nous dis que le web représente 13.1% du trafic global, auxquels tu pourrais rajouter les réseaux sociaux (6.1%) mais c'est sujet à débat donc on va garder nos 13%. Le streaming vidéo c'est 60%, donc on est bien loin du "une minute de vidéo = un an de web".

On parle bien de 13% du trafic internet mondial, c'est colossal en terme d'énergie donc oui, si on peut réduire l'impact de ces 13% avec assez peu d'efforts pourquoi ne pas le faire? Est-ce que c'est si difficile de se passer des SPA là où il n'y en a pas vraiment besoin?

Après c'est philosophique et je conçois qu'on ne soit pas tous d'accord. Si tu es de ceux qui disent de rouler en 4x4 c'est pas important parce que de toutes façons le gros des émission de CO2 n'est pas là, alors en effet on ne s'entendra pas. Personnellement j'aime l'efficience et la sobriété.

[Edrixal]

...

En fait elle n'a pas vraiment tort lorsqu'elle dit qu'une minutes de stream est égale à 1 ans de code envoyer. (Bon faut que ce soit du 4k bien lourd ou être très peut productif, mais pourquoi pas.)

Le problème dans son raisonnement c'est qu'elle oublie que ce code envoyer va être récupérer pas des dizaines/centaines/milliers/millions d'utilisateurs ce qui va donc multiplier la charge de se code. Et quant ont commence à parler de milliers d'utilisateur sur son site, on commence vite à comprendre que le moindre mo télécharger inutilement en front peut vite devenir des go ou des to qui transit inutilement.

[Sodium]

Oui, je me suis plantée, je voulais dire une heure de streaming, ce qui fait à peu près 21go.

Je ne pense pas que tes chiffres soient pertinents. Déjà est-ce qu'on parle de bande passante dédiée au code ou de bande passante tout court, ou images comprises et vidéos insérées dans les pages, notamment dans un flux Facebook, qui ne sont probablement pas comptabilisées comme du streaming ?

Je ne parlais pas en terme de consommation de bande passante globale et mondiale, mais pour utilisateur qui visionne de la vidéo 4k, ce qui exclut une bonne partie de la planète. Pour ces utilisateurs, et ils seront de plus en plus nombreux, le poids du code source des pages qu'ils visitent constitue une goutte d'eau dans un océan.

[clorr]

On ne peut pas nier un effet de mode. Comme le cloud, ou l'IA, les tendances influencent beaucoup les choix des développeurs ou de leur hiérarchie. Maintenant, est-ce juste un effet de mode ?

Il y a un paramètre a ne pas oublier dans le monde du développement, qui est le travail d'équipe. Et le fait est que les frameworks permettent aussi de scinder les projets, de faire travailler les gens en parallèle d'une manière qui n'est peut être pas toujours la plus optimale, mais le framework propose un formalisme qui aide à mettre en place des process et des méthodes de travail en équipe. Et ça, ça plait aussi à la hiérarchie.

Les devs solo peuvent être aussi intéressés car cela rationnalise leurs devs, que ce soit sur un seul site ou d'un site à l'autre pour ceux qui font du freelance.

Malheureusement, cela se fait au détriment du client et de la "beauté" du code, mais ce n'est pas la première fois ni la dernière que cela arrive...

Le point positif que je relèverait néanmoins ici, est que ces pratiques amènent à une rationalisation du dev web et, derrière, amènent de l'innovation a un niveau plus global. J'ai tendance à penser que des évolutions telles que les web components sont aussi le résultat de l'adoption de ces frameworks.

Donc, même si j'ai un ordi antédiluvien et que je peste contre ces pages qui mettent une heure à charger et me ralentissent, et que j'apprécie la beauté du code, j'ai du mal à condamner ces pratiques.