Discussion :

[anat1212]

Totalement en désaccord avec l'article probablement écrit par un flemmard de suivre ce qui se passe et réfractaire au changement.
L'utilité de frameworks tels que vue/react est d'améliorer grandement l'UX car plus de rechargement intempestifs à chaque changement de page (2,3,n ème page visitée). Ceci est d'ailleurs une métrique absente d'outils tels que Google PageSpeed.
De plus avec des technologies comme le rendu de page statiques, le code-splitting. Tout ceci apporte une vitesse de chargement de 1er page parfait.
Prenez un framework comme Nuxt.js, essayez, ça s'apprend en 2 jours dans les principes de base qui sont largement suffisant pour commencer.
Maintenant repensez à ces 20 dernières années à faire des sites web, vous verrez alors qu'aujourd'hui notre métier de développeur s'est amélioré. L'article parle de SPA et non de JAM Stack. Soyez blasés mais allez vous documenter, ou arrêtez de faire du Web si ça vous fait chier.
Toute cette perdition des node modules mène enfin à des bonnes choses. Il aura fallu du temps. Maintenant évidemment que la technologie pour la technologie ne sert à rien mais c'est un autre sujet. Si les outils de création permettent d'abstraire de la complexité pour libérer la création alors l'avancement technologique n'a rien d'inutile au contraire. Rangez vos vieux clearfix et hacks sordides.

[PomFritz]

Du Symfony ou de l'Angular, c'est tout sauf de la bricole. Si tu fais toujours tout en jQuery, effectivement c'est du bricolage et tu ne peux t'en prendre qu'à toi-même, il est temps d'évoluer car le web lui évolue.

Pour ce que je fais, c'est suffisant (ce n'est pas le coeur de mon métier, juste des interfaces intranet plus ou moins complexes de gestion d'opérations en temps réél). Bien sûr que je me tiens au courant et que j'essaie des choses.
Mais désolé, pour moi cette syntaxe qui mélange des tags, des strings en dur, des variables, du console.log(), de la mise en forme moyennement prédictible et de nombreux framework, j'appelle ça du bordel. C'est bien joli de séparer les choses, mais quand tout s'appelle parmi sans lien facilement traçable, ça reste moyen. Au niveau modélisation je n'ai jamais rien vu de probant.
C'est justement parce que j'ai évolué vers des environnements de dév modernes que j'ai l'impression de revenir en arrière. On empile les couches et les outils pour faire du jetable. Je ne sais pas s'il existe une solution au problème, mais pour moi c'est juste pas beau Je ne critique personne et je comprends les choix faits, mais il est clair que quelque chose ne va pas et qu'on ne peut pas s'en passer.

[autran]

On a industrialisé le code pour baisser les couts de développement, à commencer par les couts de main d’œuvre. Et c’est là que les frameworks entrent en action. On entend sans cesse dire que l’avantage majeur des frameworks est de permettre à un nouveau développeur d’entrer sur un projet sans avoir besoin de le connaitre car tout est uniforme avec le framework.

C’est vrai que le framework unifie le développement (paradigmes issu des best practices – configuration standard ….). Malheureusement les SSII ont tordu cette vérité pris comme hypothèse de recrutement que n’importe quel débutant fera l’affaire si on utilise un framework. Du coup on se retrouve avec des équipes de junior qui ne tiennent pas la route faute de compétences / expérience.

Quant à l’XP utilisateur, elle tient tout aussi peu la route face aux impératifs de time to market et de coût.

C’est sans doute la principale raison qui fait que les craftmen qui sont à leur compte développent sans framework.

[Wasimolo]

Le prix et le temps pour un budget alloué !
Le développeur a d'autres contraintes que les aspects techniques dans la grande majorité des ses taches. On ne développe pas tous les jours la prochaine sonde pour la l'exploration spatiale, un exemple de projet où les concessions sont rares.

Il faut faire la part des choses et l'utilisation d'un framework même en contrepartie d'une baisse de performance est un choix rationnel.
Mais framework ne veut pas dire de mettre à la poubelle l’expérience utilisateur et la performance, c'est le rôle d'un développeur de trouver le bon chemin avec les bonnes méthodes.

[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.

[Dgamax]

Je viens d'installer un Wordpress pour une amie et après un premier chargement initial qui doit sûrement mettre des trucs en cache, le temps de latence sur les pages n'est pas décelable.
Dans tous les cas, il faut être réaliste, les serveurs beaucoup moins cher que les humains, mieux vaut monter en puissance plutôt que de multiplier le temps de dev par 10.
Et si l'on a besoin d'une application ultra-performante, c'est que le projet est suffisamment ambitieuse pour nécessiter une équipe derrière qui fasse les bons choix techniques.

Oui on vit dans un monde ou il est plus logique de surconsommer au lieu de s'amuser à optimiser
Un wordpress avec un plugin wordpress de cache ça reste de la merde

[Sodium]

Tu voudrais vivre dans un monde où chaque personne qui veut un site de trois pages administrable doit payer un développeur 60 heures ?

[dfiad77pro]

et encore en 60 heures il te fera pas grand chose

[Sodium]

Ah bah si on part du principe qu'il ne peut pas utiliser de framework, même pas le sien car chaque ligne de code doit être écrite amoureusement pour le projet en cours c'est sûr.

[Chuck 3.50]

Je suis plutôt d'accord avec l'article mais malheureusement je m'y retrouve aussi pas mal, avoir sur son CV un framework à la mode qui paye bien et qui ouvre des opportunités c'est un peu l'astuce pour progresser ...

[sebastiano]

Oui on vit dans un monde ou il est plus logique de surconsommer au lieu de s'amuser à optimiser
Un wordpress avec un plugin wordpress de cache ça reste de la merde

On vit en effet dans un monde où ceux qui prétendent ne pas vouloir surconsommer, se complaisent à surconsommer de l'électricité et du temps pour réécrire du code qui existe déjà.

[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 )

[Askalma]

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...

[Dodfr2]

Pour moi rien de nouveau, les framework javascript ne sont que le reflet (et une nouvelle surcouche) des multiples librairies ou dll (si je parle de Windows par exemple) en surcouche des OS graphiques pour des exécutables, si on utilisait pas toutes ces "facilités" la majorité des applications consommeraient bien moins de mémoire et gagneraient en performances mais demanderaient bien plus de temps et d'effort en temps de développement.

Il est loin le temps on je comptais le nombre de cycles processeurs de chaque instruction assembleur et chaque octet gagné (souvenir souvenir), aujourd'hui les développeurs (ou plutôt ceux qui financent les développements) se foutent pas mal d'optimiser quoi que se soit (sauf si c'est vraiment nécessaire), l'appli est trop lente ? il suffit de faire tourner ça sur un CPU plus performant, l'appli est trop gourmande en mémoire ? il suffit de rajouter de la RAM car aujourd'hui cela ne coûte "presque" rien ce qui n'était pas le cas il y a 30 ans.

Et bien sûr il faut ajouter à cela la surcharge du code pour gérer les multiples problèmes de compatibilité Chrome IE FF, ou dans le cas d'exécutables les différentes versions d'un système d'exploitation ou système graphique comme Windows 7, Windows 8, Windows 10 et pour peu qu'on fasse une appli 3D on y ajoute aussi les incompatibilités /différences entre les différentes cartes vidéo (même si celles-ci sont supposées êtres "masquées" derrière des surcouches à la Direct 3D ou équivalent.

On retrouve d'ailleurs le même problème sur les smartphones avec Android par exemple, avec un effet moindre sur les appareils Apple dont l'environnement et la diversité matériels sont plus restreints et nécessitent donc moins de code/ressources pour pendre en compte cette diversité.

Le moteur d'exécution JAVA tout comme .NET sont aussi de belles surcouches, enfin bref toutes ces surcouches permettent de développer plus rapidement/facilement mais augmentent considérablement les ressources nécessaires à faire tourner un simple "hello world" qui au lieu d'utiliser quelques instructions CPU du temps de MSDOS vont en utiliser des milliers en mode graphique et encore plus en mode graphique dans un navigateur avec sa surcouche d'interprétation/exécution HTML/JS.

Les développeurs d'aujourd'hui ne sont même plus capable de dérouler tout le processus nécessaire à afficher un simple caractère dans une fenêtre Windows car tout est "transparent", mais derrière il faut bien qu'une librairie intermédiaire traite l'accès au fichier de la la police de caractère, et ensuite traduise cette police en points qui seront affichés à l'écran pixel par pixel, l'affichage lui-même faisant appel à une librairie graphique qui elle même va appeler des fonctions du pilote de la carte vidéo de l'ordinateur etc ... mais avec un processeur et une carte graphique à xxx Ghz on ne s'en rend aperçoit pas et tout le monde s'en balance.

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.

Javascript n'est plus du tout utilisé comme il y a 20 ans, aujourd'hui on crée des applications complètes "à la photoshop" par exemple et plus simplement le petit bandeau de texte qui défile ou la simple vérification d'un champs de saisie dans un formulaire.

Ceci dit on retrouve ça un peu partout, rien que dans les voitures par exemple on a une "surcharge" rien que pour faire démarrer le moteur si je compare ma vieille AX dont le système de démarrage est ultra simple et relativement direct entre la clé et le démarreur si on compare ça à une voiture récente avec les clés intelligentes, l'anti-démarrage, qui sont autant de "surcouches" intermédiaires entre la clé et le démarreur, sauf que là on impacte pas la performance d'exécution mais on ajoute pas mal de SPOF et on augmente très nettement le prix de vente ;-)

Je suis sûr que certains se diront que les termes que j'emploi ou mes descriptions ne sont pas tout à fait exactes mais je rédige rapidement et le but de mon commentaire n'est pas d'avoir une exactitude technique, juste de décrire que cette tendance à la "surcharge" et ses inconvénients ne sont pas du tout nouveaux peu importe la technologie utilisée.

[ManPaq]

Ce qui me laisse sceptique mais vient abonder dans le sens de prendre de la discussion est la place des frameworks et des gestionnaires de contenu dans l'enseignement: ils offrent un cadre au développement et un outil pédagogique afin d'appréhender les modèles, l'ordre des fichiers, les patterns, les objets, les langages...

Cependant ils n'apportent pas les éléments pour l'apprentissage et la pédagogie s'appuie pour l'essentiel par la prise en main.

Ce n'est pas là leur vocation mais l'attachement procure la satisfaction du fabricant et de son utilisateur en créant une relation partenaire de profit réciproque: où éducation, économie et produit sont liés et le travailleur est sevré (pas formaté) et le consommateur tiraillé entre les intérêts discordant du fabricant de s'attacher une clientèle, transmettre un enseignement, fabriquer du contenu.

Autant l'application peut s'appuyer sur une arborescence à deux ou trois étages, autant elle peut se ramifier en circonvolutions obscures (marche ou trêve).

P.S.: aussi Laravel sympa...

[TJ1985]

Comme vieux machin blanchi sous le harnais, je ne peux que constater la prolifération malsaine d'outils qui tous sont plus mieux bien que la merveille sortie six mois avant eux. Je n'ai pas de pratique réelle de ces frameworks, mais il y a fort, fort longtemps j'ai utilisé leurs précurseurs, plus ou moins. Il est clair que pour être performant et produire des applications qui tiennent debout, il faut un temps d'apprentissage certain, et il me semble qu'aujourd'hui plus personne ne prend le temps de cette maturation, préférant courir après le dernier outil à la mode pour remporter le mirifique contrat qui rendra tout le monde millionnaire, surtout le commercial qui le signe d'ailleurs.
C'est dommage. Manifestement, hormis les querelles de clocher, la plupart des frameworks connus sont efficaces et performants. En apprendre la maîtrise en se concentrant sur l'un d'eux permettrait de dégager du temps et de l'énergie pour comprendre le vrai métier de l'utilisateur, et ainsi de lui proposer des applis agréables à utiliser et efficaces.
Je ne compte plus le nombre de sites français ou j'ai fermé mon browser, las d'essayer de comprendre le cheminement intellectuel (?) de l'auteur, alors que je souhaite juste acheter un kilo de patates (je résume).
Quant aux performances, il est peut-être plus efficace d'attaquer les petites applis directement dans les langages de base. Le peu d'expérience que j'ai du WEB m'a montré que si on se base sur les standards ça a tendance à plutôt bien marcher, maintenant que IE est passé à la trappe. Mais je m'avance peut-être beaucoup. En tout cas je n'ai jamais constaté que Java était plus rapide que C, pour faire une analogie audacieuse...
Bon, dodo Papy, à la prochaine !

[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.