Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
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
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 !Envoyé par Mograine
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.
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.
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 .....
Heureusement qu'on n'a pas dit ça au(x) créateur(s) du premier framework...
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.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.
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.
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.
On parle là au mieux de quelques ko de gain hein ...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.
À 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.
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!
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.
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...
Un peu plus que de quelques Ko...
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
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.
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.
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.
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.
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.
Au lieu de remuer du vent pour des conneries, fais un vrai geste écologique, comme arrêter de manger de la viandeSé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.
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.
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.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.
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.
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.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...
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.
Répondre avec citation
Partager