Discussion :

[Lcf.vs]

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.

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.

C'est justement là que l'informatique se distingue de la plupart des vecteurs de pollution, c'est son interconnexion.

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.

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.

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

[sirthie]

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.

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.

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 :

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.

[Invité]

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.

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

[SpaceFrog]

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

[Sodium]

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.

- 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 domaine
- 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"

[Charvalos]

- Inutile : le truc le plus intelligent que je peux répondre à une telle bêtise est "lol". Réponse typique de l'informaticien un peu autiste de base nostalgique du web des années 1990 et qui n'est pas capable de comprendre que ce n'est pas parce qu'il ne trouve pas d'intérêt dans une techno qu'elle n'en a pas pour d'autres

Dixit celui qui crache sur toutes les autres technos autre qu'Angular. C'est fort du café quand même.

[Sodium]

Dixit celui qui crache sur toutes les autres technos autre qu'Angular. C'est fort du café quand même.

Je ne crache pas sur les technos concurrentes d'Angular, je crache sur JavaScript
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.

[SpaceFrog]

Dixit celui qui crache sur toutes les autres technos autre qu'Angular. C'est fort du café quand même.

Je n'aurais pas mieux dit.

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

En fait je ne considère pas que de rajouter des roues stabilisatrices à mon vélo soit une évolution favorable.

[Lcf.vs]

Alors de un c'est parfaitement faux et encore un signe supplémentaire de ton ignorance, de deux je ne permets pas de préjuger de la qualité de mon code, merci bien.

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.

Non, c'est avant tout pour améliorer l'expérience utilisateur

Améliorer l'expérience utilisateur ? hormis le mode hors-ligne, pouvant aisément être réalisé à partir d'éléments DOM aussi.

Je ne crache pas sur les technos concurrentes d'Angular, je crache sur JavaScript
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.

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.

Pareil que ton collègue neuneu plus haut, tu n'as pas la moindre idée de comment je code, tu ferais donc mieux de t'abstenir de faire des jugements hâtifs.

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.

[SpaceFrog]

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

[Lcf.vs]

@sodium : regarde le code source d'anticore et des démos... et viens me dire que tu fais au moins aussi propre que ça.

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

Un framework sert principalement à deux choses :

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.

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.

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.

@sodium : regarde le code source d'anticore et des démos... et viens me dire que tu fais au moins aussi propre que ça.

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)

[Lcf.vs]

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 ^^'

[fredoche]

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

[Sodium]

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 ?

Dans la déclaration de fonction suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

anticore.fetcher = function (element) {

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.

La syntaxe suivante est beaucoup plus claire et concise, ce n'est donc que du bon sens de l'adopter :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
class Anticore {
    fetcher(element) {}
}

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.

Ce n'est pas parce que c'est une nouveauté/mode qu'il faut impérativement en faire.

Ah ben oui, une nouveauté/mode de ... 1975 environ ?

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.

Oui ... en C++...
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.

[Lcf.vs]

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

En effet, cela se fait généralement en workers...

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.

[Lcf.vs]

Dans la déclaration de fonction suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

anticore.fetcher = function (element) {

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.

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.

Ah ben oui, une nouveauté/mode de ... 1975 environ ?

Je te prie de m'excuser, Ô grand gourou du JS, je ne savais pas que les classes existaient en JS depuis 1975

Oui ... en C++...
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.

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.

Tes arguments sont ceux d'une personne ayant (mal) appris à coder dans les années 80 et n'ayant jamais évoluer depuis. J'espère sincèrement que tu as plus de 50 ans histoire d'avoir un minimum d'excuse pour avoir une vision si pacéiste du web.

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, ... ^^'

[SpaceFrog]

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.

[Sodium]

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.

Eh bien oui, c'est justement, c'est bien le problème, c'est de la programmation fonctionnelle.
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 prie de m'excuser, Ô grand gourou du JS, je ne savais pas que les classes existaient en JS depuis 1975

Je te parle des classes en générales.
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.

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.

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

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.

Toujours cette foutue idée que les personnes utilisant tel ou tel framework n'ont pas de bagage derrière...

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.

[Lcf.vs]

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.

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.

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.