Folgore a écrit :



Heureusement que JQuery existe, c’est tellement une plaie manipuler le DOM et compagnie en JS Vanilla…



Apres ce genre d’avis “Une partie des développeurs estime en effet qu’il ne sert plus à rien puisque toutes les opérations effectuées peuvent très bien se faire en JavaScript directement.” c’est quand même peu ridicule… ce genre de propos viens de développeurs qui doivent encore travailler a l’age de pierre, probablement portant un teeshirt “vive linux”, ne jurent que par VIM et le terminal… bref qui sont tres conservateurs d’idéologies tels que performances blablabla, code natif blablabla… En 2016, on a des CPU a 10 cœurs et des smartphones plus puissants qu’une nintendo wii " />







Etant donné le nombre effarant de sites qui rament et qui m’énervent à longueur de journée, y compris sur un desktop bien puissant, je pense qu’il y a vraiment des coup de pied au cul qui se perdent.



Sérieusement les gars, je faisais des trucs plus fluide il y a 30 ans sur des ordinateurs 8 bits…



Si on m’avait dit à l’époque que les programmeurs deviendraient si mauvais qu’avec l’équivalent d’un supercalculateur de l’époque, on ne parviendrait même plus à afficher une simple page de texte de façon fluide, j’aurais trouvé cela déprimant.



Non seulement le langage Javascript est un langage lent, inefficace ou l’abstraction a un coût CPU élevé. Mais le fait d’y rajouter des framework par dessus ne fait qu’achever le malade tout en finissant de déconnecter les programmeurs des réalités qu’ils manipulent et de les pousser à écrire n’importe quoi sans comprendre ce qu’ils font.



Mais le pire est que ce système catastrophique prends maintenant des allures d’infection zombie. Certains en font maintenant des Os, des systèmes pour IHM.



On trouve même des gens pour vouloir mettre du Javascript dans des objets connectés, comme si la consommation énergétique de l’humanité n’était pas un problème écologique suffisamment sérieux et qu’on pouvait se permettre de multiplier par million des objets basés sur des techniques monstrueusement inefficaces sur le plan énergétique pour la simple raison bassement commerciale qu’il existe quantité de programmeurs qui ne maîtrisent que ça.



Mais au fond, exploiter la médiocrité sera toujours plus rémunérateur que de promouvoir l’excellence. C’est un triste exemple qui montre ou la logique mercantile qui bouffe notre civilisation nous mène…

zefling a écrit :



Tu parles du PHP 5.0 ou du PHP 7.0 ? Il y a une différence monumentale entre ces deux versions en terme de perf. D’ailleurs, même PHP 5.6,







PHP 7 ne fait que supprimer des inepties techniques qui n’auraient jamais du exister. C’est mieux, mais ça n’en fera pas un langage rapide pour autant.





les perfs que je vois pas trop le problème, quand je vois mes temps de calculs, c’est la base de données qui ralenti généralement le temps global.





Parce que l’utilisation d’une base de données SQL “lourde” pour stocker la moindre petite données est une mauvaise habitude qui s’est généralisée.



Malheureusement, des langages comme PHP sont aussi responsable de cet état de fait car ils poussent vers ce modèle de programmation.





Et si tu veux améliorer les bilans énergétique de l’humanité, il faut aussi arrêter : Excel, Python, ruby, et… tout ce qui est script ou macro, mais aussi le templating, les parseurs, les logs, etc. et tout passer par du binaire compilé.





A mon gout, les “petits langages de script inefficients” se sont un peu trop multipliés ces derniers temps. Et surtout, ils sortent systématiquement de leur petit rôle pour servir à faire de vraies applications de prod.



Quand aux tableurs, ils sont aussi une énorme source de problèmes en entreprise parce que leur usage aboutit à des programmes inefficients et mal structurés.



Le plus amusant dans tout ça, c’est que les gens pensent se simplifier la vie et gagner du temps avec leurs 500 mauvais outils, tout ça parce qu’ils ont peur d’en apprendre un bon (je simplifie, mais c’est l’idée).





Si tu savais le nombre de calcul « inutile » qu’il y a dans une appli juste pour gagner du temps lors de son écriture.





En même temps, ça serait très dur de l’ignorer étant donné que bien souvent ça se voit comme le nez au milieu de la figure, même sans lire le code.

brazomyna a écrit :



Bien sûr, c’est bien connu: le monde est divisé en deux catégories: les ‘bons’ qui font du low level et écrivent quelques ligbes d’asm chaque matin en se rasant, et les autres, les médiocres, qui font du managé, pas par choix raisonné mais juste parce qu’ils ne doivent pas avoir suffisamment d’intelligence pour arriver à la cheville des bons.







Ce n’est pas parce qu’on critique un langage ou un environnement que les programmeurs qui l’utilisent doivent pour autant se sentir visé.



Je crois que tous les programmeurs dans leur vie ont un jour programmé avec des trucs pas terrible.



Et ce n’est pas parce que je l’ai aussi fait que pour autant je vais trouver ça bien.





A ce jeu, moi j’ai un autre système de catégorisation: les bons qui comprennent que le génie logiciel c’est une affaire de compromis pour des paramètres multiples et divers (et que la perf est un paramètre parmi tant d’autre, et très rarement le facteur critique) ; et les autres, ceux remplis de certitudes dans leur monde tout noir ou tout blanc.





Sauf qu’a force d’accumuler les mauvais compromis année après année tout en se moquant des performances, on a fini par aboutir à un bouzin infâme qui bouffe toute la puissance et détruit l’expérience utilisateur.



Voila à quoi ça mène de faire des compromis…

tanguy_k a écrit :



Ouai mais en local, un site web par definition passe par le reseau, rien que ca ca change bcp de choses.







Etudie la question, tu comprendra que le réseau n’y est pour rien dans la majorité des sites web qui rament.



Il y a même des sites qui permettent d’analyser finement la question.



D’ailleurs, je suis sur un connexion à 100Mb/s et c’est encore plus rageant de voir toute cette lenteur. Sur un smartphone, c’est encore plus insoutenable.





JS est un langage interprete et comparativement aux autres langages du meme type (Python, Ruby, PHP) il est plus rapide.





Félicitation, utiliser un langage un peu plus rapide que ce qui se fait de pire devrait nous rassurer.



Mais javascript n’est pas le seul responsable du problème. Le rapport mal fichu avec le DOM et les multiples framework “pour encapsuler le caca” participent grandement au problème.





Au sujet des frameworks, rien de specifique a JS, il y a en pour tous les langages (Rails, .NET, Django, Laravel, Qt, MFC, Boost, Delphi…).





Sauf que les framework n’ont pas la même incidence suivant le langage. Dans des langages comme Javacript ou PHP ou tout autre langage non compilé, le cout de l’abstraction est très élevé.





“Deconnecter les programmeurs des realites” ? Vite revenons aux char * et aux malloc, au Fortran ou mieux a l’asm 68000…





Un programmeur qui n’a pas appris le fonctionnement a bas niveau ne programmera jamais correctement un langage de haut niveau.



C’était vrai par le passé, ça l’est toujours aujourd’hui et ça le sera toujours demain.

 



Rien de deconnant a ca. Les objets connectes (comprendre a Internet) utilisent logiquement les technos web. Et le langage du web c’est JS. Ca aurait ete du Ruby, du PHP ou du Python ca serait meme ete plus lent que JS.





Sauf que Js n’est qu’un simple langage de script utilisé dans un navigateur.



Toutes les couches réseau, soit le fondement de l’internet, elles sont écrites en C.



D’ailleurs, l’idéal pour les objets connectés n’est pas de se connecter directement au web, mais d’utiliser un intermédiaire, ce qui leur permet d’utiliser des protocoles bien plus simples et des types de liaison plus adaptés.





T’aurais prefere qu’ils mettent du Fortran ?





Et pourquoi pas du Cobol, pendant que tu y est ?



L’idéal pour programmer des objets connectés, c’est l’assembleur ou à la rigueur le C.



Et quand on parle du C, ce n’est pas une préférence de langage, c’est juste que c’est un langage adapté parce qu’il a été conçu pour ça.





T’as raison, c’etait mieux avant, y’avait absolument pas de logique mercantile. Et les devs avaient tous une barbe parceque c’etait des hommes, des vrais, maintenant c’est tous des puceaux.





Visiblement tu n’as pas compris. Alors je vais le rééxpliquer.



En informatique, aucun langage n’est équivalent. Chaque langage a été conçu avec un but et un objectif donné.



Le langage Javascript n’a pas été conçu pour écrire du code de bas niveau.



Le langage C a été conçu pour écrire du code de bas niveau.



La logique mercantile, c’est de dire qu’on va faire un produit qui va se programmer en Javascript pour la mauvaise raison qu’il y a un marché de xxxx millions de programmeurs front end qui pourront le faire sans effort et que ça facilitera la vente des objets.



Sauf que voila, c’est ce genre de logique qui nous éloigne progressivement de l’idéal technique et aboutit précisément à faire de la merde.



Et c’est d’autant plus vrai que cette mauvaise logique est cummulative et qu’au bout d’un certain temps, le résultat devient catastrophique.



Pour l’instant, vous ne voyez peut être pas encore le problème, mais le cout énergétique de l’internet commence déjà à devenir prohibitif.



Quand les objets connectés vont commencer à sortir du cadre du gadget hype et du jouet pour geek, le problème de la consommation va rapidement devenir un sujet de préoccupation majeur.

brazomyna a écrit :



C’est donc ça ton contre-argument: si on n’est pas d’accord c’est parce qu’on se “sent visé” ?

Ca va chercher loin dis-donc ...

Et pourtant, mes critiques n’ont jamais porté sur les programmeurs mais juste sur des technologies.



Penser qu’une mauvaise technologie impliquerait forcément de mauvais programmeurs, ce n’a jamais été le sens de mes paroles. Donc ne les interprétez pas ainsi.

L’overhead d’une telle solution est déjà faible au regard de la pluissance dispo.





C’est malheureusement une pure idée reçue qui se colporte depuis trop longtemps.



Et le résultat, c’est qu’a force de raisonner comme ça, on a accumulé les errements année après année pour aboutir au final à bouffer une puissance démentielle et dégrader l’expérience utilisateur.





Et elle a en plus le bon goût d’être une valeur constante, qui se réduit donc en proportion au gré de l’augmentation exponentielle de la puissance disponible.





Moquons nous de la puissance utilisée, utilisons toujours plus de couches pour programmer vite, de toute façon les ordinateurs de l’an prochain auront doublé de puissance et ça ne se verra plus.



Le seul problème, c’est que ça fait déjà un petit moment que la puissance n’augmente plus comme auparavant et que le mur commence à se rapprocher…





Tu fais surtout silence sur la quantité à peu près incalculable de travail économisé grâce à ce genre de solutions -certes sub-optimales au niveau des perfs mais- incomparativement meilleures en terme d’efficience de développement. C’est autant de projets qui ont pu être menés à bien plus rapidement, avec moins de coûts (au sens large), ou même qui ont tout simplement ont été rendu viables, et ont donc pu voir le jour.





Sauf que l’on peut regretter que la réduction des coûts soit la seule obsession dans l’informatique actuelle et particulièrement dans le monde du web.



Produire rapidement de la merde à bas coût en oubliant que l’utilisateur final est tout à fait sensible au confort d’utilisation des services (et que les critères SEO commencent à l’intégrer) commence à perdre sérieusement de la pertinence.



Mais ce n’est pas le programmeur qu’il faut incriminer mais le marché et l’incompétence des donneur d’ordres qui ont fait du prix le principal critère de choix en informatique.





C’est typiquement l’histoire de la genèse du PHP: un langage super pas efficient en terme de perfs (longtemps des années lumières derrière le JS, d’ailleurs). Bref une “merde absolue” dans ton référentiel étriqué qui prend en compte le seul critère des performances. Pourtant personne aujourd’hui n’osera nier à quel point il a permis de faire exploser les développements web, baisser leurs coûts, et donc enrichir l’offre de services comparé aux CGI qui existaient déjà depuis bien longtemps.





PHP est effectivement une merde absolue sur le plan de l’efficience.



Je suis pourtant d’accord avec toi que ce langage n’a pas apporté que du mauvais. D’ailleurs on peut le dire de beaucoup les langages.



Mais ils serait temps de réaliser que tout ce qui est bon dans PHP pourrait être repris dans un langage bien meilleur. Le bilan énergétique de l’humanité en serait amélioré.





Autre exemple concret: dans mon monde pro, un homme-jour c’est entre 1.0 et 1.5k€. Un serveur  plus puissant c’est 3-5k€, les projets ce sont grand minimum des centaines d’homme jour. Faisons un calcul trivial: pour un projet de 1000 MD, le plus efficient pour moi serait selon toi une solution technique qui sera (soyons fous) 30% plus efficiente niveau perf (soit -5k€), mais demanderait (soyons sympas) 10% d’homme.jour en plus (soit +100k€) ?





Sauf que s’il suffisait simplement de mettre un serveur un peu plus puissant pour absorber le manque d’optimisation, ça se saurait.



Parce que tout ces gens qui ont décrété que l’optimisation c’est un truc d’un autre age et qui l’ont fait tout au long de la chaine, depuis le serveur web en passant par le langage serveur, le langage côté client, les frameworks, tout cela est malheureusement cumulatif… et finit par coûter lourd.



D’ailleurs, le fait que l’expérience utilisateur se retrouve aussi fortement impactée sur un aussi grand nombre de sites web est bien la preuve de l’échec de cette logique.



Et je ne parle même pas des grand services Web tels que Google ou Facebook ou cela fait longtemps qu’ils ont bien réalisé le problème que pose ces technologies mal optimisées et qu’ils travaillent pour améliorer la question. Quand on a des millions de serveurs, le manque d’optimisation, ça se traduit directement par une perte financière récurrente qu’il faut payer tous les mois…