Version imprimable
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 :aie::aie::aie:
:aie:
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 !Citation:
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.Citation:
Envoyé par Sodium
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 !Citation:
Envoyé par kilroyFR
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 .....
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.Citation:
Envoyé par Sodium
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.Citation:
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 ?).Citation:
Envoyé par 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 ...Citation:
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...Citation:
Envoyé par Sodium
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...
S'agissant de l'accroissement du volume (et du poids) du code HTML, je parlerais plutôt de dizaines voire de centaines de Ko.Citation:
Envoyé par Sodium
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.Citation:
Envoyé par Sodium
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...Citation:
Envoyé par Lcf.vs
L'écologie c'est un effort et une prise de conscience... pour absolument tout ce qu'on fait.Citation:
Envoyé par SimonDecoline
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.Citation:
Envoyé par Lcf.vs
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 viande ;)Citation:
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.
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.Citation:
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.Citation:
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.
Je n'ai strictement rien d'un "gros", comme tu dis... néanmoins, je suis un concepteur d'outils de dev (bibliothèques/frameworks)... sachant que mes outils sont, au minimum, utilisés par des dizaines de milliers de développeurs, qui eux mêmes font d'autres outils ou sites avec, qui seront utilisés, au final, par un nombre incalculable de clients finaux... ben, même un tout petit changement peut avoir un énorme impact.Citation:
Envoyé par SimonDecoline
C'est justement là que l'informatique se distingue de la plupart des vecteurs de pollution, c'est son interconnexion.
Si tu apprenais à faire de l'HTML propre et sémantique... il serait presque aussi léger que le JSON que tu transfères avec ta crasse qu'est Angular.Citation:
Envoyé par Sodium
Là où réside la différence, c'est dans la quantité de code que tu exécutes côté client, le coût du calcul de génération des éléments, le coût du redraw/reflow, dans tout ce que ça prend en mémoire, dans le délai de réactivité de tes pages, car TOUT est généré à chaque affichage.
Crois-moi, à mes tout débuts (tu peux même aller consulter mes plus anciens topics pour vérifier, si tu veux), j'expérimentais justement à fond la génération, côté client. Je trouvais cela tellement plus simple... mais j'en suis revenu, après avoir mesuré combien la batterie de mon PC de l'époque en était impacté.
Pourtant, je ne puis te donner entièrement tort, il y a bien, avec ce genre de stratégie, une différence de coût énergétique... côté serveur, mais c'est parce que ce coût est reporté et multiplié, côté client, par le nombre d'affichages.
C'est justement pour ça que les "gros" l'utilisent... ce n'est que pour réduire LEURS COÛTS !!!
Je sors apparemment d'un siècle où les gens qui produisaient du code essayaient de comprendre ce qu'il produisaient. Je constate que ce n'est plus le cas pour beaucoup, et qu'aujourd'hui, des gens se félicitent de leur ignorance et conspuent ceux qui ne font pas de même.Citation:
Envoyé par Sodium
Moi, quand je le peux, j'essaie tout simplement de faire ceci, pas par considération écologique mais par esthétisme, parce que c'est plus élégant, parce que ça me plait, parce que je devrai (moi ou ou quelqu'un d'autre) revoir mon code dans 6 mois, un an, deux ans et que je préfère le comprendre le plus facilement et rapidement possible, les préoccupations écologiques viennent seulement après :
Citation:
Tout le monde peut écrire du code que la machine peut comprendre mais seul les bons développeurs sont capable d’écrire du code compréhensible par les humains.
Martin Fowler,
programmeur, consultant, blogueur,
coauteur du Manifesto for Agile Software Development
Sa page sur Wikipedia :
https://fr.wikipedia.org/wiki/Martin_Fowler
Et sans forcer sur la recherche, je constate que d'autres ont des préoccupations proches des miennes :
Écrire un code propre, lisible, réutilisable et de haute qualité
Bootstrap est une régression pour un développement Front-end de qualité
Enfin, ils sortent peut-être d'un autre siècle...
Au passage, félicitations pour tes commentaires, Lcf.vs, je n'ai pas les connaissances pour produire de tels arguments.
La lisibilité, c'est physique : dessin des caractères, taille des caractères, espacement des caractères, longueur des lignes, hauteur des lignes, taille des paragraphes, espacement des paragraphes ; l'intelligibilité (certains parlent de "lecturabilité"), c'est sémantique, c'est la "compréhensibilité" du code, et tu peux avoir du code parfaitement lisible physiquement mais complètement inintelligible.
Je constate que l'argument des 10 centrales nucléaires n'a pas porté. Bon, essayons autre chose :
Internet bientôt premier consommateur mondial d"électricité
Si tu t'en fous, je ne sais pas de quel siècle tu sors.
Aujourd'hui, quasiment tout le monde de plus de 12 ans possède un téléphone portable pour jouer à des jeux et poster des selfies, avec les conséquences que l'on connait niveau consommation d'énergie, exploitation de ressources, pollution, etc. Si tu arrives à te donner bonne conscience en passant tes pages web de 100ko à 10ko tant mieux pour toi. J'espère juste que tu as vérifié que ton serveur aussi est optimisé et qu'il ne tourne pas dans un conteneur dans une VM dans un cloud de l'autre côté de la planète...Citation:
Envoyé par Lcf.vs
Je plussoie le coté crasse d'angular qui est je persiste juste une surcouche inutile qui met le développement web à la portée de ceux qui n'ont pas les connaissances spécifique du développement web, tout comme bon nombre de framework supposés simplifier les technologies en les "portants" dans les univers de pratiques d'autres langages.
C'est d'ailleurs peut-être grâce (ou a cause ) de ces framework que tu as pu aborder le développement web ...
De là à dire qu'il faut systématiquement utiliser des frameworks il y a un grand pas.
De la à se permettre de traiter les gens de neueux, on, peut alors rapidement se demander qui a des jugements hâtifs et préformatés...
- Pas les connaissances spécifiques : Quand on fait de l'Angular, on fait toujours du HTML, du CSS et du scripting, y a plutôt intérêt à avoir de bonnes connaissances dans le domaineCitation:
Je plussoie le coté crasse d'angular qui est je persiste juste une surcouche inutile qui met le développement web à la portée de ceux qui n'ont pas les connaissances spécifique du développement web, tout comme bon nombre de framework supposés simplifier les technologies en les "portants" dans les univers de pratiques d'autres langages.
- Simplifier les technologies : Sérieusement, tu as déjà touché à Angular ? Angular est très loin d'être "simple", il faut un bon moment pour rentrer dedans et saisir la logique et mieux vaut disposer de sérieuses connaissances en OO pour ne pas s'y perdre. Angular est efficace, ce qui n'est pas un synonyme de "simple"
Dixit celui qui crache sur toutes les autres technos autre qu'Angular. C'est fort du café quand même.Citation:
Envoyé par Sodium
Je ne crache pas sur les technos concurrentes d'Angular, je crache sur JavaScript ;)Citation:
Dixit celui qui crache sur toutes les autres technos autre qu'Angular. C'est fort du café quand même.
L'avantage majeur d'Angular est d'être pensé pour TypeScript. Au delà de ses fonctionnalités, on a donc un code de bien meilleure qualité et beaucoup plus maintenable.
Je n'aurais pas mieux dit.Citation:
Dixit celui qui crache sur toutes les autres technos autre qu'Angular. C'est fort du café quand même.
@sodium:
Si tu lisais, mon intervention, j'ai bien précisé que je limitais l'utilité de tels frameworks à permettre à ceux qui n'y connaissent rien en dev web de développer en web.
En gros ce sont plutôt des roues stabilisatrices comme tu peux en rajouter au vélo de ton gamin pour qu'il puisse commencer à faire du vélo. Le but a terme étant que ces roues ne soient que provisoires ....
Malheureusement certains font de cette nouvelle discipline de "vélos à roues stabilisés" une discipline en soi avec une fédération et championnat du monde ...
J'imagine un tour de France de cette nouvelle discipline.:mouarf:
En fait je ne considère pas que de rajouter des roues stabilisatrices à mon vélo soit une évolution favorable.
Quand tu fais de l'HTML propre, si, il est super léger ET sémantique et s'il est bien minifié, à peine plus lourd que le JSON.Citation:
Envoyé par Sodium
Améliorer l'expérience utilisateur ? hormis le mode hors-ligne, pouvant aisément être réalisé à partir d'éléments DOM aussi.Citation:
Envoyé par Sodium
Mais même en pur JS, tu peux faire des choses très propres et facilement maintenables... suffit d'apprendre... mais évidemment, saisir toutes les subtilités du langage, ça prend des années.Citation:
Envoyé par Sodium
Il n'y a pas besoin de voir la qualité de ton code, tes propos, ton attitude, tes arguments, y a même pas 3 années d'expérience, là-derrière... dans le cas contraire, il y a un sérieux problème.Citation:
Envoyé par Sodium
Je crois que si tu veux vraiment pouvoir progresser, dans ce métier, il va falloir que tu apprennes à accepter la critique, accepter que tes certitudes ne sont peut-être pas fondées... et, surtout, à apprendre les bases du langage, avant d'utiliser des frameworks.
Si tu est tellement convaincu du pouvoir des frameworks; essaye d'écrire un chef d’œuvre de la littérature Japonaise en utilisant Google translate ...
@sodium : regarde le code source d'anticore et des démos... et viens me dire que tu fais au moins aussi propre que ça. :mrgreen:
Un framework sert principalement à deux choses :Citation:
Si tu lisais, mon intervention, j'ai bien précisé que je limitais l'utilité de tels frameworks à permettre à ceux qui n'y connaissent rien en dev web de développer en web.
En gros ce sont plutôt des roues stabilisatrices comme tu peux en rajouter au vélo de ton gamin pour qu'il puisse commencer à faire du vélo. Le but a terme étant que ces roues ne soient que provisoires ....
Malheureusement certains font de cette nouvelle discipline de "vélos à roues stabilisés" une discipline en soi avec une fédération et championnat du monde ...
J'imagine un tour de France de cette nouvelle discipline.
1) harmoniser la méthode de travail d'une équipe sur l'ensemble des projets sur lesquels ils travaillent
2) répondre aux problèmes qui se posent systématiquement sur ce genre de projet : routage, appels serveur, rendu des données dans le DOM (et côté backend mise en cache, appels à la bdd, internationalisation, gestion des assets...)... Cela fait d'autant plus sens pour le JavaScript qui nativement n'est pas conçu pour la conception d'applications complexes
En tant que professionnels du web, une bonne partie de notre travail consiste à faire de la veille technologique et à se former constamment à l'état de l'art actuel.
J'ai 7 ans d'expérience professionnelle et bien plus en tant qu'amateur. Environ 35 sites derrière moi, aucun fait à partir d'un CMS, la plupart sans aucun framework. Les-dits sites sont rapides et légers et ont été réalisés extrêmement vite car j'ai une excellente connaissance de HTML, PHP, CSS et JavaScript du fait de mes études qui comportaient des cours très poussés sur les bases de ces langages, complétées par des stages, de l'expérience en entreprise et minimum 5-7 gros bouquins par an sur des sujets divers et variés. Mes patrons et clients sont très satisfaits dans mon travail et mes collègues viennent régulièrement me trouver quand ils ont besoin de conseils sur l'un des langages précédemment cités car je fais partie des rares développeurs web à avoir réellement appris leurs bases sans me lancer immédiatement dans l'utilisation d'outils facilitant le boulot.Citation:
Il n'y a pas besoin de voir la qualité de ton code, tes propos, ton attitude, tes arguments, y a même pas 3 années d'expérience, là-derrière... dans le cas contraire, il y a un sérieux problème.
Je crois que si tu veux vraiment pouvoir progresser, dans ce métier, il va falloir que tu apprennes à accepter la critique, accepter que tes certitudes ne sont peut-être pas fondées... et, surtout, à apprendre les bases du langage, avant d'utiliser des frameworks.
Commence déjà par l'adapter aux dernières normes Ecmascript et on en reparlera (la priorité étant de remplacer les "truc.machin = function() {..}" parfaitement dégueulasses de JavaScript par des classes)Citation:
@sodium : regarde le code source d'anticore et des démos... et viens me dire que tu fais au moins aussi propre que ça.
Sérieusement, c'est juste risible... depuis quand faire des classes influe-t-il sur la qualité du code, d'autant plus avec un langage orienté objet sans ?
Ce n'est pas parce que c'est une nouveauté/mode qu'il faut impérativement en faire.
Tu remarqueras, si tu y fais attention, qu'il n'y a pas un seul constructeur (ce à quoi les classes ne sont qu'une alternative), donc, des classes pour quoi faire ?
De plus, si tu te renseignais un peu sur les best practices, tu saurais que les classes sont beaucoup mais alors vraiment beaucoup moins performantes. Ce n'est donc pas un vecteur de performances.
Comme je disais, tes arguments sont juste risibles. ^^'
EDIT: Et, pour ta gouverne, je parlais d'usage sémantique des balises, à savoir : quand il faut utiliser une balise plutôt qu'une autre, ne pas avoir la moindre balise ne servant qu'au design, ne pas avoir de balises conteneurs sans contenu, ...
Quand tu respectes tout ça, tu n'as (quasi) plus une div, (quasi) plus de spans, quasi plus de br, ... et quasi pas besoin de class/id... et, étrangement, ton HTML en est sacrément plus léger ^^'
des classes qui se ne sont que du sucre syntaxique
Les dernières normes tant qu'elles ne sont pas des standards de fait t'obligent à patcher pour tout ce qui n'est pas compatible : IE c'est entre 3 et 5%, et ça ne supporte pas les classes
Ton site ou tes applis, c'est censé marcher pour tout le monde bien souvent
C'est le grand intérêt d'un truc comme Jquery. Bonnant malant l'histoire du dev web, ça a toujours été de supporter les exceptions de chaque navigateur il me semble.
Bon pour en revenir au sujet de départ, le truc un peu con c'est bien que quelle que soit l'origine du script à exécuter, toutes les instructions viennent s'ajouter à la même et unique boucle d'événement du moteur JS ? C'(est une question même si je mle doute que la réponse est "oui"
N'y aurait il pas moyen que tout ce qui est non essentiel au site ou à l'appli porteur de contenu s'exécute dans une deuxième boucle indépendante ? Avec tous les multi-cores et les multi-threads dont on dispose, qu'est ce qui l'empêche ?
J'imagine que certains y ont déjà pensé ? genre web workers en plus indépendant
Dans la déclaration de fonction suivante :Citation:
Sérieusement, c'est juste risible... depuis quand faire des classes influe-t-il sur la qualité du code, d'autant plus avec un langage orienté objet sans ?
Tu as une moitié du code qui ne sert à rien. Du code qui ne sert à rien, c'est de la pollution qui nuit à la compréhension du code.Code:anticore.fetcher = function (element) {
La syntaxe suivante est beaucoup plus claire et concise, ce n'est donc que du bon sens de l'adopter :
Et pour que ça soit réellement propre, il faudrait que tes paramètres et retours de fonctions soient typés, ce qui n'est pas faisable actuellement en JavaScript.Code:
2
3
4
Ah ben oui, une nouveauté/mode de ... 1975 environ ?Citation:
Ce n'est pas parce que c'est une nouveauté/mode qu'il faut impérativement en faire.
Oui ... en C++...Citation:
De plus, si tu te renseignais un peu sur les best practices, tu saurais que les classes sont beaucoup mais alors vraiment beaucoup moins performantes. Ce n'est donc pas un vecteur de performances.
Ce n'est absolument pas le cas en PHP et je doute très, très fortement que ça soit le cas en JavaScript, d'autant plus que les classes ne sont que du sucre syntaxique et que le code est probablement interprété de la même manière.
Si tu veux me prouver le contraire, je te prierai de sourcer un minimum quand tu balances de trucs de ce genre.
Si différence il y a, cela tombe dans le domaine de la micro-optimisation et celle est pratiquement toujours mauvaise pour la qualité du code.
En effet, cela se fait généralement en workers...Citation:
Envoyé par fredoche
Perso, je rêve d'une new génération de browsers dont toutes les APIs seraient des modules qu'on pourrait appeler ou non mais qui ne seraient instanciées que si un import est fait dessus.
Il y a de plus en plus d'APIs déjà instanciées, dont on ne se sert pas, pour chaque window, on gagnerait énormément en perfs & en consommation si ce n'était le cas.
Juste du code que tu n'as visiblement pas comprisCitation:
Envoyé par Sodium
Premièrement, c'est de la programmation fonctionnelle. Ensuite, le but est de pouvoir facilement lui faire des plugins, si nécessaire. Et, enfin, en théorie, tu n'as jamais besoin de fetcher des données avec anticore, il le fait, de manière automatique.
Je te prie de m'excuser, Ô grand gourou du JS, je ne savais pas que les classes existaient en JS depuis 1975 :ptdr:Citation:
Envoyé par Sodium
Parce que c'est à moi de faire ta veille technologique, en plus ? Il y a plein d'articles, sur le net, à ce sujet.... et on ne parle pas de micro-optimisations mais bien d'un rapport du simple au double, voire davantage.Citation:
Envoyé par Sodium
Mes arguments ? ce sont ceux de quelqu'un qui fait énormément d'expérimental, qui passe le plus clair de son temps à étudier les specs (j'connais, par exemple, la spec HTML de WHATWG sur le bout des doigts, idem en PHP, idem en JS, idem en CSS, idem en SQL), à étudier les best practices, qui explore des tas de concepts de programmation, toujours en avance sur les specs, ... ^^'Citation:
Envoyé par Sodium
C'est très bien de vouloir aller de l'avant.
Il faudrait tout de même lever la tête pour voir le mur qui est devant.
Opter pour un framework sous prétexte que c'est nouveau en à la mode de les utiliser, sans connaître le langage de base qu'ils viennent agrémenter, et sans avoir aucune idée de la pérennité de ces frameworks, pour moi un simple pari sur l'avenir, pour ne pas dire c'est suicidaire.
C'est sûr que sur le coup ça ouvre de nouvelles portes et facilite le travail à un instant T.
J'en reviens aux offres d'emplois fantaisistes qui exigent des compétences dans tel ou tel Framework souvent inconnu, cela encourage juste une spécialisation et n'assure en rien la pérennité des projets.
Eh bien oui, c'est justement, c'est bien le problème, c'est de la programmation fonctionnelle.Citation:
Juste du code que tu n'as visiblement pas compris
Premièrement, c'est de la programmation fonctionnelle. Ensuite, le but est de pouvoir facilement lui faire des plugins, si nécessaire. Et, enfin, en théorie, tu n'as jamais besoin de fetcher des données avec anticore, il le fait, de manière automatique.
Et la programmation fonctionnelle, c'est juste moche.
Et je me fiche parfaitement d'anticore, je te parle de JS en général.
Je te parle des classes en générales.Citation:
Je te prie de m'excuser, Ô grand gourou du JS, je ne savais pas que les classes existaient en JS depuis 1975
Si les langages de programmation modernes ont massivement adopté le concept des classes, ce n'est pas pour rien, c'est tout simplement parce que c'est plus clair, compréhensible et concis.
Le fait que JavaScript ait fini par s'y plier n'est qu'un aveux d'échec de la programmation fonctionnelle ou par prototypage et à part quelques intégristes de JS aux idées arriérées, tout le monde en est très content.
Justement, les articles sur le sujet je les ai lus puisque j'avais un collègue ayant les mêmes idées que toi. J'ai pu lui prouver facilement qu'il avait tort ;)Citation:
Parce que c'est à moi de faire ta veille technologique, en plus ? Il y a plein d'articles, sur le net, à ce sujet.... et on ne parle pas de micro-optimisations mais bien d'un rapport du simple au double, voire davantage.
Toujours cette foutue idée que les personnes utilisant tel ou tel framework n'ont pas de bagage derrière...Citation:
Opter pour un framework sous prétexte que c'est nouveau en à la mode de les utiliser, sans connaître le langage de base qu'ils viennent agrémenter, et sans avoir aucune idée de la pérennité de ces frameworks, pour moi un simple pari sur l'avenir, pour ne pas dire c'est suicidaire.
Les frameworks tels qu'Angular et React ne font que répondre à un problème existant depuis les débuts de l'AJAX : comment injecter proprement dans le DOM des données issues d'une API. Angular a une manière particulièrement élégante d'y répondre. React moins.
Un aveu d'échec ? elle est bien bonne, celle-là... l'adoption des classes, en JS, n'est qu'une opération de séduction, pour attirer les développeurs provenant d'autres langages, nullement pour répondre à un besoin technique. :aie:Citation:
Envoyé par Sodium
De plus, si c'était un tel échec, pourquoi bon nombre de news features existent-elles ? justement pour encore faciliter le full fonctionnel. ^^'
Tu sais juste pas de quoi tu parles, ni ce que tu critiques.