Discussion :

[Invité]

Je ne parlais pas d'Anticore pour les 200+ dépendances mais d'un framework comme React par exemple. Par curiosité et pour ne pas trop sortir de chiffres de mon postérieur je viens de faire une install en utilisant create-react-app et mon node_modules contient un superbe 1009 modules

[Lcf.vs]

[Lcf.vs]

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

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

[tankd03]

On peut très bien avoir des années d'expérience et être parfaitement incompétent si l'on travaille dans une techno qui n'incite pas à de bonnes pratiques.
Le nombre de "développeurs" JS qui sortent des non sens du genre "l'encapsulation et le typage strict ça ne sert à rien" par exemple est juste effrayant.
JS crée des armées de professionnels qui resteront des débutants en programmation une bonne partie de leur carrière.

Ca reste vrai pour beaucoup de langages.
Ce que je trouve dingue, c'est le nombre de dev qui ont choisit ce taf pour la paye.
Il faut être un minimum intéressé et passionné pour avancer.

[sancelot]

Je lis ici les gens se plaindre de l'utilisation de framework. Mais n'est ce pas le propre de l'informaticien de ne pas reinventer la roue a chaque fois ?
qui envisagerait serieusement de ne pas utiliser de framework js aujourd'hui dans ses applis webs ? (ou alors si c'est pour refaire ce ne serait qu'un micro framework et quel interet ?) En 2018 le metier de developpeur c'est pour beaucoup de l'assemblage de composants. On n'a plus le temps de reecrire completement des frameworks from scracth.
On a une team qui a voulu le faire chez nous. 3 ans qu'ils sont dessus, ca nous a couté une blinde (soit disant codé dans l'etat de l'art). Et pourtant des barons du javascript (des ninjas du code comme ils aiment a le dire. Au final un framework js d'une rigidité sans nom, plein de manques; donc l'alternative est la fuite en avant ou alors utiliser des frameworks deja eprouvés, maintenus par une communauté.
Ca me semble plus le sens de l'histoire que ceux qui ont un ego surdimensionné et croient qu'ils vont revolutionner l'informatique en reecrivant tout. Bien le propre du dev de toujours critiquer le travail des precédents. Plus malin que les autres.
D'ailleurs au bout de 3 ans, il ne reste plus que 2 dev d'origine sur la 10aine. On se retrouve avec un framework difficilement maintenable et evolutif (malgré un code propre).
Tellement de choses absentes qu'on aurait deja eu dans des frameworks open source (ou du commerce) et là on rame comme c'est pas possible.
Quel gachis quand tout existe. Une selection des bonnes boites a outils suffit la plupart du temps a couvrir les 95% des besoins. Se focaliser sur les 5% me semble plus pertinent que refaire les 95%.

J'ai connu le meme probleme avec un framework python, les mecs des tronches , ok , mais ils avaient pas vu venir les erreurs de conceptions... au final aprés leur départ on paie encore la dette technique !

Aujourd'hui, j'entends également un discours pour les choix technologiques, vraiment affolant, par des mecs qui sont compétents mais que dans un domaine (du c++) . A propos d'un framework c++ : "Je suis persuadé que l'on fait le bon choix, de plus ce framework est utilisé par le fabricant No 1 de XXXX manufacturing". Et bien entendu , sans se soucier des autres technos, tu dois prendre en compte le fait que c'est acté et que l'on ne reviendra pas dessus ! Bref .....

[sirthie]

J'en connais aussi beaucoup. Des gens parfaitement incompétents qui ont choisit de refaire ce qui existait déjà en moins propre, moins efficace, moins fiable et n'offrant que peu de perspective d'avenir puisqu'ils acquièrent une expertise sur un système propriétaire qui ne leur servira jamais à rien ailleurs.

Ne pas confondre solution de facilité et solution raisonnée.
Un framework (un vrai, comme Symfony ou Angular, pas comme cette merde de ReactJS) permet de répondre à un besoin partagé par le plus grand nombre tout en forçant à une certaine rigueur et uniformité au sein d'une équipe, ce qui permet d'intégrer plus facilement de nouveaux arrivants tout en permettant de conserver plus facilement un code maintenable sur la durée.

Donc, si je comprends bien, toute autre solution autre que déjà existante et éprouvée est une idiotie ? Heureusement qu'on n'a pas dit ça au(x) créateur(s) du premier framework.

[Sodium]

Donc, si je comprends bien, toute autre solution autre que déjà existante et éprouvée est une idiotie ? Heureusement qu'on n'a pas dit ça au(x) créateur(s) du premier framework.

Dans tous les domaines, il y a des centaines milliers de gens qui se prennent pour des génies qui vont révolutionner le monde. Une poignée d'entre eux ont raison. Les autres se vautreront pour la plupart lamentablement.
Quand on a plus de 10 ans d'expérience dans une techno, qu'on est reconnu comme expert (pas autoproclamé) et qu'on a identifié un problème ainsi qu'une manière élégante de le résoudre, ça vaut le coup de se lancer.
Si c'est pour refaire ce que font déjà des projets open source à plusieurs milliers de contributeurs ou produits par des ingénieurs de chez Google/Facebook/Microsoft en moins bien, juste pour le plaisir d'avoir SA techno, autant éviter de se tirer directement une balle dans le pied.

[sirthie]

Avec un autre langage on n'aurait pas le même problème car on n'aurait pas à lui greffer systématiquement 5mo de plugins, librairies et frameworks directs pour faire le moindre truc, un peu comme une créature de Frankenstein difforme et repoussante.

Pareil que Paenitentia : même si le problème ne serait pas si important avec un autre langage, il n'en reste pas moins que les pages web actuelles utilisent des scripts/bibliothèques de scripts pour des effets que je trouve tout à fait dispensables, genre le contenu qui surgit des bords de la page pour se positionner sur celle-ci (exemple rencontré récemment) ou dispendieux en termes de rapport volume de code/intérêt... voire pour aucun effet ou aucune fonctionnalité (à quoi sert une Lightbox si vous ne mettez pas d'images dans vos pages ?).

Cette inflation de code ne concerne d'ailleurs pas que le JavaScript. Depuis l'avènement des CMS, le code HTML des pages web contient de plus en plus de balises, au point d'en être inintelligible. Il serait possible de refaire ces pages web à l'identique ou à l'analogue avec un code HTML beaucoup moins volumineux.

[Sodium]

Cette inflation de code ne concerne d'ailleurs pas que le JavaScript. Depuis l'avènement des CMS, le code HTML des pages web contient de plus en plus de balises, au point d'en être inintelligible. Il serait possible de refaire ces pages web à l'identique ou à l'analogue avec un code HTML beaucoup moins volumineux.

On parle là au mieux de quelques ko de gain hein ...

À partir du moment où tout est optimisé, compressé et caché, il n'y a aucune raison pour qu'il y ait des problèmes. La plus grosse partie du trafic vient des régies pubs, vidéos en autoplay et autres nuisances.

[eleydet]

Le JS est très particulier. Il laisse rarement indifférent : Bien souvent, on l'adore ou on le déteste. Il est donc un langage polémique!

[Excellion]

Depuis peu je m'occupe d'un site asp.net mvc 5.

Une pure horreur. Entre Bootstrap, Jquery, Less et consort, on se retrouve avec des pâtés, voire des pâtés de pâtés qui prouvent que les personnes qui ont créé le site ne maîtrisaient ou même ne connaissaient rien.

En fait, comme dit précédemment, ces "frameworks" ont été utilisés pour pallier les meconnaissances des équipes.

Dans certains cas, l'utilisation des librairies ne se justifiait pas du tout, et dans d'autres, tout était chargé en bloc pour un seul appel.

Prendre des librairies pour éviter de recréer la roue, pourquoi pas, mais encore faut-il connaître un minimum les bases.

Et aujourd'hui, avec les évolutions des css, des javascripts et des navigateurs, l'utilisation des frameworks se justifie de moins en moins.

[Beginner.]

C'est toujours le même non argument : on peut coder a peu près n'importe quoi dans n'importe quel langage. Il n'y a pas si longtemps que ça, les gens faisaient encore des choses très complexes en assembleur.
Tant que ça marche on s'en fout, l'utilisateur final ne verra pas la différence.
Ce qui compte pour le développeur, c'est de pouvoir avoir un code propre, maintenable et sur lequel il sera facile d'intégrer de nouveaux développeurs. Et ça, je suis désolé mais en JavaScript ce n'est pas possible, rien que l'absence de typage fort oblige à multiplier les vérifications pour être sûr qu'une fonction reçoit bien des variables du type attendu, donc c'est du code plus long, moins lisible et avec plus de bugs potentiels.

Sur un autre topic, j'ai demandé aux inconditionnels de JS de me donner des exemples de code de qualité écrit en pur JavaScript, du code où l'on comprend immédiatement ce qui se passe avec le minimum de commentaires : je n'ai jamais obtenu de réponses, j'attends toujours.

Ben sur l'autre fil je parlais justement de la JSDoc que certains linter prennent en compte mais si pour toi "avec le minimum de commentaires" signifie pas de JSDoc ni de commentaires indiquant le type alors c'est vrai que personnellement (c'est-à-dire moi avec mon faible niveau mais peut-être que d'autres ont trouvé des solutions) je ne vois pas comment on pourrait faire (sans débogueur)... Comme déjà dit sur l'autre fil je suis passé par Java avant JS et c'est vrai qu'au début j'ai cherché à savoir si il existait un bon IDE fournissant une assistance en JS se rapprochant de l'assistance qu'on a en Java...

C'est vrai que parfois quand on essais de comprendre le code développé par quelqu'un d'autre cela peut être plus difficile et plus long, je ne parle pas des types primitifs (là ça passe encore) mais des objets (instances), quand une fonction reçoit en argument un objet eh bien pour comprendre on a besoin de savoir de quelle "class" cet objet est l'instance... Alors pour ça il y a les commentaires, la JSDoc ou encore le débogueur mais c'est sûr si un outil permettait d'aller à cette "class" juste en cliquant (go to definition) sur le nom de l'argument ce n'est pas moi qui serait contre... Parfois même en survolant le nom de l'argument on peut voir apparaitre une description de cette "class"...

Parfois cet objet peut contenir juste des méthodes et même si on a une liste de ces méthodes (obtenue par exemple avec le déboguer) cela peut être quand même difficile de comprendre ce qu'elles font car elles peuvent travailler sur des données dont on ne peut connaitre l'origine qu'en regardant la "class" dont cet objet est l'instance (le déboguer n'indique pas la provenance de ces données à moins que cela m'ait échappé ???)...

C'est sûr aussi que si je veux avoir une autocomplétion quand j'utilise cet objet à l'intérieur de la fonction eh bien il va bien falloir que l'IDE sache d'où provient cet objet...

Mais même avec tout ça on pourra avoir besoin d'une documentation la plus complète possible d'ailleurs en Java on a souvent une JavaDoc pour toutes les classes...


Enfin bref, ce n'est pas moi qui serait contre le fait d'avoir en JS le même genre d'assistance qu'on a en Java après cela ne veut pas dire qu'en JS pur on ne peut pas avoir un code propre et lisible, c'est possible de bien le structurer (par exemple en utilisant les modules ES6, les class ES6, ...), on peut aussi avoir un minimum d'assistance si on connait les outils qui la fournissent... Cela peut bien se passer au moins pour les petits projets après pour les gros projets sur lesquels plusieurs développeurs travaillent et qu'on doit maintenir je peux comprendre que l'on soit plus exigeant...

[sirthie]

On parle là au mieux de quelques ko de gain hein ...

À partir du moment où tout est optimisé, compressé et caché, il n'y a aucune raison pour qu'il y ait des problèmes. La plus grosse partie du trafic vient des régies pubs, vidéos en autoplay et autres nuisances.

S'agissant de l'accroissement du volume (et du poids) du code HTML, je parlerais plutôt de dizaines voire de centaines de Ko.

Selon cet article, de 2017 à 2018, le poids du code HTML des pages web a augmenté de 117,5% :

https://www.artwai.com/poids-moyen-d...s-web-en-2018/

Et il n'y a pas que le poids du code, il y a aussi son intelligibilité.

Certes, comme tu le dis, "tout est optimisé, compressé et caché", mais il n'en est pas moins vrai que tout cela serait encore plus efficace si on parvenait à réduire le poids du code, tous langages confondus.

Et à la base, comme déjà dit, le problème est écologique : toujours plus de code, toujours plus de bande passante, toujours plus de serveurs, des devices toujours plus puissants (bien qu'il y a sans doute aussi eu des gains du côté de la consommation).

A titre de comparaison, les jeux vidéo consommeraient actuellement l'équivalent de 10 réacteurs nucléaires :

https://www.sciencesetavenir.fr/natu...u-video_130021

[Sodium]

Je te laisse tout seul à ton combat de diminuer le code source des pages pour sauver la planète, si tu persistes assez tu gagneras peut-être un IG-Nobel.

Quant à la lisibilité du code source, je ne sais pas de quel siècle tu sors mais sur une application sérieuse, les différents contenus sont séparés en module avec le minimum de code dans chacun d'eux.
À moins que tu ne parles de la lisibilté quand on consulte le code source d'une page, auquel cas c'est un non-argument, ce code étant destiné aux navigateurs et non aux humains.

[Lcf.vs]

Je te laisse tout seul à ton combat de diminuer le code source des pages pour sauver la planète, si tu persistes assez tu gagneras peut-être un IG-Nobel.

Sérieusement, je ne sais si c'est de conscience ou d'intelligence dont tu manques, pour ne te rendre compte de la multiplication exponentielle du coût des sites/applications utilisés chaque jour par des milliards de personnes.

1Ko de code en plus sur un facebook/google, ce sont des milliards de Ko par jour en plus de chargés ET d'interprétés.

Quand tu vois des sites en bootstrap (qui grossit ton HTML en te forçant à ajouter plein de classes et de balises inutiles), quand t'utilises une lib comme React/Angular/Vue.js qui fait tout le rendu, côté client, ça fait beaucoup + de code transféré et interprété et, ce, pour chaque utilisateur, plutôt que de simplement générer le rendu une seule fois, sur le serveur, le cacher et l'envoyer à chacun.

[Beginner.]

Par curiosité j'ai jeté un œil à TypeSrcipt, en particulier j'ai voulu savoir ce qu'il en était des variables privées eh bien le résultat de la compilation nous donne un code JS où les variables (déclarées privées en TS) ne sont pas "privées" du tout, ce sont des variables "normales"... Pourtant en JS on peut faire quelque chose qui se rapproche d'une variable privée (au sens de "non accessible" par une instance) en utilisant le scope d'une fonction...

Mais c'est vrai que l'assistance TS nous indique l’erreur : Property 'maVar' is private and only accessible within class 'Maclass' (mais la variable est quand même accessible dans le code).
Et que l'autocomplétion ne propose pas les variables déclarées privées.

[Invité]

Sérieusement, je ne sais si c'est de conscience ou d'intelligence dont tu manques, pour ne te rendre compte de la multiplication exponentielle du coût des sites/applications utilisés chaque jour par des milliards de personnes.

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

[Lcf.vs]

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

L'écologie c'est un effort et une prise de conscience... 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.

[Invité]

L'écologie c'est un effort et une prise de conscience... 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.

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.

Evidemment qu'il faut tout prendre en compte, mais il y a quand même des priorités. Quand je dois optimiser un code, je commence par le passer dans un profiler.

[Sodium]

Sérieusement, je ne sais si c'est de conscience ou d'intelligence dont tu manques, pour ne te rendre compte de la multiplication exponentielle du coût des sites/applications utilisés chaque jour par des milliards de personnes.

Au lieu de remuer du vent pour des conneries, fais un vrai geste écologique, comme arrêter de manger de la viande

Si tu tiens absolument à faire baisser le trafic web, tu peux aussi montrer l'exemple en arrêtant d'utiliser de la bande passante pour venir poster des âneries.

quand t'utilises une lib comme React/Angular/Vue.js qui fait tout le rendu, côté client, ça fait beaucoup + de code transféré et interprété et, ce, pour chaque utilisateur, plutôt que de simplement générer le rendu une seule fois, sur le serveur, le cacher et l'envoyer à chacun.

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.

Par curiosité j'ai jeté un œil à TypeSrcipt, en particulier j'ai voulu savoir ce qu'il en était des variables privées eh bien le résultat de la compilation nous donne un code JS où les variables (déclarées privées en TS) ne sont pas "privées" du tout, ce sont des variables "normales"... Pourtant en JS on peut faire quelque chose qui se rapproche d'une variable privée (au sens de "non accessible" par une instance) en utilisant le scope d'une fonction...

Ca a très peu d'importance. L'utilité d'un propriété ou méthode privée, c'est d'empêcher qu'elle puisse être utilisée pour de mauvaises raison par les codeurs sur l'application.
Si après, lors de l'exécution, quelqu'un veut s'amuser à bidouiller dans les outils de développement pour accéder ce à quoi il ne devrait pas... eh bien tu ne peux pas faire grand-chose, c'est le principe même des langages interprétés par le navigateur.