tanguy_k a écrit :



Difficile de reprocher à JS de ne pas être aussi rapide que les langages compilés, il ne joue pas dans la meme categorie.



Oranges vs pommes.

Pour l’instant on a pas encore réussi à créer une “orangomme” qui aurait donc les avantages à la fois des oranges (langages interprétés) et des pommes (langages compilés).







Tout à fait.



Les deux catégories de langage ont d’ailleurs toujours coexisté avec chacun leurs usages de prédilection.



D’ailleurs, Javascript convenait très bien pour l’usage que ses concepteurs imaginaient au départ.



Le problème, c’est qu’aujourd’hui les besoins ont complètement changés. Aujourd’hui, on veut écrire de vraies applications qui tournent dans le navigateur. On veut utiliser des frameworks qui ont des fonctionnalités évoluées. Et le petit langage qui allait bien au départ montre ses limites…

lossendae a écrit :



Les besoins ne sont pas les mêmes pour tout les types d’applications.

Wikipedia, Facebook sont fait en php.

Github et Gitlab tourne avec rails.

Sentry utilise Python.







En cherchant bien, on trouvera toujours des exemples utilisant n’importe quel langage… même en Cobol, Basic ou Lisp.



Mais sur les serveurs, le problème n’est pas comparable.



D’abord, on peut toujours multiplier les serveurs pour compenser un langage lent (contrairement au “front”, on l’on ne peut pas multiplier les CPU de la machine du client). Et le serveur web, ça se parallélise bien.



Même si c’est un énorme gaspillage de ressources et d’argent, il est évident que les sociétés du web ont privilégié la rapidité de développement en se disant qu’elles auront toujours le temps d’optimiser si besoin après.



D’ailleurs, c’est justement ce qu’on constate quand les projets deviennent mature et comptent des centaines de milliers de serveur… et que ça commence à chiffrer sévère : A ce stade, ça commence à se gratter l’occiput en se demandant comment on peut améliorer le débat sans tout jeter aux orties, ce qui aboutit à des choses comme cela :



WikipediaOn peut facilement prédire que tôt ou tard, avec les normes écologique et les taxes carbone, les langages lents finiront par disparaître. Et la meilleure raison, c’est que finalement, ça n’est pas très difficile de créer de meilleurs outils.





Si les langages plus bas niveau étaient plus pratique (et plus facile d’acces pour les developeur lambda), il domineraient outrageusement le marché. Ce n’est pas le cas.





Tout à fait.



Il faut bien reconnaître qu’il manque cruellement à ces langages un environnement facile d’utilisation pour des programmeurs néophytes.



Mais au moins, c’est techniquement faisable contrairement au fait d’essayer de rendre performant les langages dynamiques…





Le dévelopement n’est pas une profession à part, il y a plusieurs niveau de complexité et plusieurs solution pour regler différents problèmes.



Mon DSI qui aujourd’hui ne fait plus de php, se concentrant sur du langage bas niveau ultra optimisé pour de la domotique, crache des qu’il peut sur “cette horreur qu’est php” et la supériorité des langages qu’il utilisent.

Même si je ne doute pas de ses capacités dans ses travaux actuels, et que dans l’absolu il n’a pas tout à fait tort, le code php/js qu’il a codé il n’y a pas 5 ans est un tres bon exemple de ce qu’il ne faut surtout pas faire.





Pour avoir programmé en PHP j’ai aussi trouvé que malgré ses défauts, ce langage apportait certaines choses intéressantes en terme de facilité. Donc je n’aurais pas une vision aussi radicale que lui.



Mais au final, sur le constat, je le rejoint. PHP ne se contente pas d’être lent, il présente aussi de redoutables travers.



Par exemple, si l’on veux écrire le code le plus performant en PHP, cela nuit assez rapidement à d’autres aspects du projet.



Un langage comme C/C++ est indéniablement plus efficace quand il s’agit de concilier optimisation, bonne structure et bonne architecture.





Du coup je me méfie encore plus des cadors qui pensent tout savoir et qui au final, se montre incompétents une fois sorti de leurs zone de confort.





En même temps, en informatique, il y a toujours eu l’outil à la mode du moment… et celui qui sera à la mode dans quelques années.



Les vieux briscards voient le chemin idéal à long terme. Et l’évolution leur donne le plus souvent raison.



Les jeunes programmeur voient concrètement les outils avec lesquels ils peuvent travailler aujourd’hui et ils n’ont pas tort. Mais ils n’ont pas toujours conscience qu’ils en verront passer d’autres…



Les deux ont raison, c’est juste qu’ils ne parlent pas toujours la même langue.

tanguy_k a écrit :



D’ou WebAssembly. Mais ca ne remplacera pas JS.







Rien ne permet d’affirmer cela aujourd’hui.



Qui prédisait au départ ce que l’on fait de Javascript maintenant ?





Pour faire des applis web (90%) on continuera d’utiliser JS comme aujourd’hui (a mon avis).





Pourtant, on voit tellement de choses qui rament sur le web. L’intérêt à changer de technologie est bien réel.



Et cela sans compter tout ce qu’on ne fait pas encore parce que Javascript n’est pas assez rapide.





Et encore une fois, les perfs de JS sont loin d’être ridicules.





Personne ne dit qu’elles sont ridicules.



Mais les faits sont la, Javascript est très loin des langages rapides.



(on trouve facilement des benchmarks un peu partout sur le web.)



Il faut réaliser qu’aujourd’hui des gens changent d’ordinateur pour quelques pourcent de gain alors que changer de langage de programmation apporte un gain incommensurablement plus important.



Il fut une époque ou les performances des processeurs augmentaient régulièrement. Alors on se moquait d’utiliser un langage lent. Si ça ramait, on attendait quelques mois les nouveaux processeurs.



Aujourd’hui, d’une génération à l’autre de processeur, on ne gagne presque plus rien.



Les langages restent un des rare “réservoir” de gain potentiel.





Tu penses à quoi ? Delphi, VB6 ?





On pourrait ajouter Access, DBase, FoxPro, Turbo Pascal ainsi qu’une pléthore de langages plus anciens comme Cobol, Fortran.



Même des langages comme Basic, tu aurait dit à une époque qu’il disparaîtrait, personne ne t’aura cru.

lossendae a écrit :



Atom qui utilise du js est un editeur de texte “riche” tout a fait honorable.







Est ce qu’on doit pour autant gaspiller des cycles machine(et donc de l’énergie) sous prétexte que nos ordinateurs ont largement plus de puissance que nécessaire pour manipuler du texte ?



Est ce que tout le monde est réellement satisfait de la rapidité de cet éditeur ? Une petite recherche avec les mots “atom” et “slow” me laisse une réponse qui parait plutôt mitigée.



Enfin, j’ai assez pesté contre la lenteur d’Eclipse (écrit en Java) pour penser qu’il faut que les programmeurs d’aujourd’hui réapprennent à considérer la vitesse comme un point important de l’expérience utilisateur.

stefann sasori a écrit :



…

Moi perso cette solution me va actuellement car je crois que le futur (j’entend l’évolution) se chargera lui même de virer définitivement Javascript du web. Les besoins en perfs seront de plus en plus importants à l’avenir et le JS pourra pas suivre, les grands acteurs du web seront donc obligés de proposer autre chose. C’est juste une question de temps.







C’est en effet plus que probable.





A ce propos, j’ai vu dans un commentaire sur macg, que Apple pousserait swift sur le web (backend et frontend). Je sais pas si c’est crédible mais c’est ainsi que je vois l’avenir du web.

Des solutions open source poussées par les grands acteurs du web qui uniformisent le développement front end et backend.





Quel que soit les qualité d’un langage, il ne conviendra jamais à tous les usages. Et il ne faut pas répéter les erreurs du passé en laissant une multinationale acquérir trop de pouvoir sur les standard du web.



Pour le futur du “langage du web”, Je pense qu’il faudrait améliorer le concept de Web Assembly.

brazomyna a écrit :



Tout comme un employé d’edf vous dira que promouvoir un langage super pas optimisé est une méga aubaine pour inciter à consommer encore plus d’énergie.



De toute façon, c’est clair que les millions d’adeptes de nodejs sont pour un tiers des commercieux complotistes, un autre tiers des moutons suiveurs incapables de prendre du recul et le dernier tiers des dev. tellement abrutis qu’ils sont pas capables de comprendre les quelques principes triviaux d’un langage fortement typé.



Et puis tant pis si on n’avance pas le moindre élément étayant cette thèse, l’important c’est pas tant de présenter la réalité, mais bien de se forger une posture, genre “regardez-moi les mecs, z’avez-vu comment que ch’suis fort, j’arrive même à avoir un regard critique de vieux routard pendant que les autres se débattent dans leur petites considérations étriquées et leur hype à 2 balles. Mais on me la fait pas à moi.”.



Et le jour où on nous démontrera par a+b que notre thèse ne tient pas 2 secondes, on pourra toujours s’en sortir en invoquant les complots et autres “faits alternatifs”. Après tout, Trump a bien démontré que ça fonctionnait bien de nos jours.







L’économie est le moteur de nombreux comportements humains. Ce n’est pas un complot, simplement de la sociologie.



La proposition de NodeJs est commercialement efficace et bien ciblée : vous savez programmer du front Web en Javascript, vous pourrez faire la même chose côté serveur avec le même langage.



Quand au fait de penser qu’une majorité de programmeurs web auraient une bonne compréhension des mécanismes internes des langages, je pense qu’il ne faut pas rêver.

brazomyna a écrit :



Non, c’est une théorie fumeuse qui a autant de valeur que la mienne à propos de l’agent EDF.





C’est dommage de voir autant d’expérience gâchée par une incapacité latente à remettre en question ses petites certitudes et son ego.



Tu as dû confondre vieillesse et sagesse, manifestement.







L’ennui, c’est que les insultes et les attaques personnelles ne sont pas pour autant des arguments.



On a le droit de ne pas être d’accord. Mais il faut savoir garder un ton respectueux.

brazomyna a écrit :



…

Tu as dû confondre vieillesse et sagesse, manifestement.







Vous savez, les langages dynamiques, ce n’est vraiment pas nouveau.



Ils nous ont aussi fasciné à une époque…

Nithril a écrit :



JS n’est pas plus un “langage lent” que python ou ruby.







Tout à fait. Mais vous comparez un langage lent à d’autre langages lents.



Même si les profs en raffolent, ce sont tous des petit langages de script avec lesquels on écrit rarement plus que des petits projets.



Parlons plutôt des langages dont on se sert pour créer les logiciels qui sont les cadors du marché.





Au contraire même, les moteurs JS ont fait d’importants progrès.





Certes, mais malgré la débauche d’optimisations déployées on reste loin d’un vrai langage statiquement compilé.



Et le problème de pousser ce genre d’optimisation, c’est qu’on peut y récolter aussi quelques effets de bord.





Mais bien entendu, certaines constructions rendront difficile une compilation native efficace.





C’est bien cela le problème.



Pour l’instant, personne n’a trouvé la solution pour obtenir quelque chose de performant à partir des langages dynamiques.



Même si en informatique il ne faut jamais dire jamais, force est de constater que pour l’instant les langages dynamiques sont toujours une impasse en terme de performances. Pour ma part, je ne vois pas comment on pourrait solutionner le problème.



Et je pense que si quelqu’un avait pondu une thèse qui apporte des solutions, on le saurait déjà.





L’overhead n’est vraiment pas l’argument principal qui font que certains revent mieux que JS.





Quand ils verront ce que certains feront de WebAssembly, ça devrait réveiller leur capacité à rêver…



Javascript, ça fait déjà un moment qu’on touche les limites quand on veut faire des choses ambitieuses.





Tu évoques les moteurs JS d’il y a 10 ans ?





Non.



On ne peut qu’admirer le talent et le niveau technique des auteurs des derniers moteurs Javascript



Le problème, c’est que même le meilleur talent du monde n’arrive pas toujours à faire des miracles devant des problèmes qui sont peut être insolubles.



Ce qui est triste, c’est de voir autant de programmeurs croire que tout ces problèmes de performances seront réglés un beau matin par l’apparition d’un compilateur magique.



Le grand compilateur magique ne viendra pas.

tanguy_k a écrit :



Pour information, parmi tous langages interprétés (Python, Ruby, Perl, PHP…), JavaScript est actuellement le plus rapide, exemples :

http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=node&lang2=pyt…

http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=node&lang2=yar…

http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=node&lang2=php







Ce sont tous des langages qui sont réputés pour être lents, voir très lents.



En comparaison, Javascript dispose aujourd’hui de moteurs beaucoup plus optimisés.



Hélas, cela ne lui permet pas pour autant de rivaliser avec des langages compilés rapides.