Node.js 6.0 : de nombreuses nouveautés, mais pas encore « Stable »

Node.js 6.0 : de nombreuses nouveautés, mais pas encore « Stable »

Pas de précipitation

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

27/04/2016 3 minutes
115

Node.js 6.0 : de nombreuses nouveautés, mais pas encore « Stable »

L’environnement Node.js vient de passer à la version 6.0. Il s’agit d’une évolution majeure apportant des améliorations importantes, notamment via le passage à la version 5 de la machine virtuelle JavaScript V8. Le risque de régression pour les développeurs est cependant bien présent.

Node.js est un environnement de développement entièrement focalisé sur le JavaScript. Sa spécialité est la création de projets pour les serveurs, ces derniers étant alors capables de diverses tâches, comme la génération de pages web. Il est conçu pour simplifier le développement de ces travaux et ses performances élevées ont fait sa popularité. Au point que Microsoft a d’ailleurs proposé une série de pull requests pour rendre Node.js compatible avec sa machine virtuelle JavaScript, Chakra.

93 % de la norme ECMASCript 2015

La version 6.0 de Node.js, tout juste disponible, comporte un important lot d’améliorations. Tout d’abord, sur le terrain des performances globales. Ensuite, la nouvelle mouture charge plus rapidement les modules, améliore les différents tests, la documentation ainsi que l’utilisation de plusieurs API, notamment Buffer et File Syste.

Mais la plus significative est le passage à la version 5 de V8, la machine virtuelle JavaScript du projet Chromium, que l’on trouve donc dans Chrome et Opera. Node.js 6.0 devient donc du même coup compatible avec environ 93 % des fonctionnalités de la norme ECMAScript 2015 (anciennement ES6). Une bascule qui ne se fera pas forcément sans heurts.

Une nouvelle version « Current », mais pas « Stable »

À cause de ces changements internes, certains développeurs devront faire attention. Par exemple, ceux qui utilisent des extensions natives devront impérativement les compiler, au risque sinon de voir apparaître des erreurs à leur lancement. Par ailleurs, ceux qui travaillent sur des projets sensibles ont tout intérêt à rester sur la version 4, toujours considérée comme la version stable.

On remarque en effet que Node.js 6.0, en dépit de sa version finale, n’est pas accompagné de l’étiquette « Stable », mais de « Current » (en cours). L’équipe de développement explique que l’objectif est bien de passer la nouvelle mouture en stable (ou LTS), mais qu’une série de mises à jour mineures est d’abord prévue. Elle prévient que ces apports risquent d’apporter différentes régressions, entrainant la recommandation de rester sur Node.js 4 en attendant une stabilisation.

Node.js 6.0 est donc pour le moment surtout réservé aux développeurs qui veulent les dernières nouveautés sans avoir d’impératifs précis en termes de suivis de projets. Ce qui implique notamment de vérifier les régressions à chaque nouvelle version pour réparer les problèmes qui surviendront à la compilation. Dans le domaine des précisions importantes, ajoutons enfin que Windows XP et Vista ne sont plus pris en charge.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

93 % de la norme ECMASCript 2015

Une nouvelle version « Current », mais pas « Stable »

Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

Fermer

Commentaires (115)


Obidoub
Le 27/04/2016 à 13h 06

Nodejs le cauchemar des sysadmin.


youtpout978
Le 27/04/2016 à 13h 07

Aussi celui des dévs&nbsp;<img data-src=" />


MoonRa
Le 27/04/2016 à 13h 10

On ne peut toujours pas faire des imports?


Obidoub
Le 27/04/2016 à 13h 13







youtpout978 a écrit :



Aussi celui des dévs&nbsp;<img data-src=" />





Ah bon, je pensais justement que c’était amusant pour les dev, vu le succès qu’il rencontre et les milliards de dépendances qui viennent avec tous les projets…



youtpout978
Le 27/04/2016 à 13h 21

Effets de mode toussa, il existe quelque dev Full JS, perso je suis plus polyvalents et je fais du JS et du C#, à côté des langages de haut niveau JS fait pâle figure, toujours à devoirs ajouter 15 biblio, des langages de plus haut niveau pour travailler sur de gros projet même si c’est amené à changer avec la nouvelle norme EcmaScript,

et écrire 15 lignes de codes en JS sachant pertinemment que dans un autre langage tu l’aurais fait en une seule, le débogage assez merdique…&nbsp;

Le réel intérêt en faite c’est d’en faire à la fois côté serveur et côté client grâce à Node.Js, mais quitte à choisir autant utiliser un framework php/java/c# côté serveur pour gagner en productivité, même s’il est vrai que parfoir Node est plus performant face à certains framework mais est-ce que t’es gagnant financièrement au final, surtout que la main d’oeuvre manque.


MaLaaK
Le 27/04/2016 à 13h 30

Ce qui est très pratique, c’est la Package Manager de Node (NPM).

&nbsp;Il y a une communauté très prolifique qui y contribue.

Peu importe votre architecture (ASP.NET, Spring, PHP …), NPM rend bien des services.



Les cas d’utilisation de NodeJS comme backend principal doivent être assez rare. En général, il est utilisé pour des besoins bien spécifiques. Socket.io est par exemple utilisé pour le temps réel. Je sais aussi que NodeJs est pas mal utilisé comme middleware, pour enrichir la requête avant d’être envoyé au serveur. Ou pour faire du load balancing.


Munsh
Le 27/04/2016 à 13h 37

Jamais été tenté par TypeScript avec ton passif JS et c# ?


martino
Le 27/04/2016 à 13h 38

Ca dépend si on est passé en isomorphic pour le developpement web ou si on est resté en 2011 en fat-client thin server ou encore plus loin dans le temps en thin client fat server.

Après ce la dépend aussi du besoin.

De ce que tu dis tu sembles avoir oublié de “veiller” depuis 2011 , me trompai je ?


KP2
Le 27/04/2016 à 13h 56







Obidoub a écrit :



Nodejs le cauchemar des sysadmin.







+10000000000

A chaque fois qu’un client m’annonce qu’il veut intégrer NodeJS à son appli, je lui demande 5 min, je me place en position foetale dans un coin et je pleure un peu.

Ensuite, je reviens et il m’expose son idée que je peux joyeusement démonter…







MaLaaK a écrit :



Ce qui est très pratique, c’est la Package Manager de Node (NPM).

 Il y a une communauté très prolifique qui y contribue.

Peu importe votre architecture (ASP.NET, Spring, PHP …), NPM rend bien des services.







Sauf que c’est de la merde en barre vomie par un tas de nazes qui pensaient réinventer la roue en mieux mais qui sont tombés dans TOUTES les ornières apprises et évitées depuis des années par tous les package managers antérieurs.

Le plus drole a été le retrait de left-pad qui a fait foiré des centaines de modules…



Et puis bon, la communauté si prolifique est tellement prolifique qu’elle a plus tendance a laisser pourrir des milliers de modules en version alpha qu’autre chose… génial le suivi. Un projet de dev fait juste pour les devs sans se poser la question de la prod…



MaLaaK
Le 27/04/2016 à 14h 18

Mouais tu parais un peu catégorique.

Gulp est par exemple un task runner hyper léger.

&nbsp;Pour automatiser la compilation du SSAS, ou la minification du JS par exemple, c’est génial.



Aujourd’hui plus que jamais, l’intérêt d’être développeur c’est associer le meilleur de tous les mondes …


youtpout978
Le 27/04/2016 à 14h 25







martino a écrit :



Ca dépend si on est passé en isomorphic pour le developpement web ou si on est resté en 2011 en fat-client thin server ou encore plus loin dans le temps en thin client fat server.

Après ce la dépend aussi du besoin. 



De ce que tu dis tu sembles avoir oublié de "veiller" depuis 2011 , me trompai je ?






euh, disons que j’ai commencé à bosser en 2011 dans le monde du dev, à l’époque du bon vieux Asp.Net WebForms, le seul JS que je faisais c’était du document.getelementbyId(&lt;%= control.clientId %&gt;), avec un bon scriptlet des familles, avec des commandes tellement caché que tu les découvres par hasard sur d’obscure site d’entraide …

&nbsp;

Il y a 3 ans j’ai bossé sur un projet Asp.Net pour Sharepoint(quelle abomination) là j’ai commencé à utiliser Jquery et de + en + de JS, au point ou des pages était gérer complètement en JS avec l’appel au WS par Jquery … (sans un autre framework certaines page contenais 3000 lignes de JS).



Il y a 1 an et demi, j’ai bossé sur du Asp MVC avec du angular, on appelé soit le controleur ou des WS Web Api en angular, résultat des pages qui était rendu une fois par le serveur et tous le reste gérer par Angular (à part quand on changeait de page le Asp MVC reprenait la main), je trouve c’est un compromis pas trop mauvais …



Depuis 6 mois je suis sur un front full Html/css/js avec angular, donc routage gérer par angular et qui appele des WS &nbsp;Rest, au départ j’utilisais node pour lancer mon site en http-serv, après la page principale est devenu une page php (lié à d’autre besoin non géré par moi) qu’on héberge directement sur un apache avec le JS qui va bien (tout mon code vue+js tient dans un JS minifié de 200ko générer avec grunt), donc non je ne suis pas resté en 2011, mais pour travailler tous les jours avec et avoir connu les joie du C# et du framework .net c’est une vrai tare d’utiliser JS au quotidien (après on peut se dire que c’est un défi).



&nbsp;

&nbsp;



Munsh a écrit :



Jamais été tenté par TypeScript avec ton passif JS et c# ?





J’en ai fait, j’ai développé une appli mobile cordova à l’époque ou la ctp1 avait été intégré à Visual Studio, j’avais limite pu copier mon code C# en TS et modifié quelque truc (Flyff cordova), par contre je ne l’utilise pas sur le projet actuel étant donné qu’il sera amené à être repris et les connaisseurs de TS ne courent pas les rues c’est pour ça qu’on ne m’a pas vraiment autorisé à l’utiliser, alors que j’aurai gagné en productivité avec l’auto-complétion, et j’aurai une homogénéité parfaite sur tout mon code…



&nbsp;



MaLaaK a écrit :



Ce qui est très pratique, c’est la Package Manager de Node (NPM).

&nbsp;Il y a une communauté très prolifique qui y contribue.

Peu importe votre architecture (ASP.NET, Spring, PHP …), NPM rend bien des services.





Je l’utilise essentiellement pour ça, il est même intégré à visual stuio, et tu peux aussi utiliser bower sur visual studio, sinon j’ai jamais dev des WS sur du node.JS.



KP2
Le 27/04/2016 à 14h 26







MaLaaK a écrit :



Mouais tu parais un peu catégorique.

Gulp est par exemple un task runner hyper léger.

 Pour automatiser la compilation du SSAS, ou la minification du JS par exemple, c’est génial.







Oui, c’est genial tant que ca reste sur le poste du dev ou sur un serveur de dev… le problème avec NodeJS, c’est que ça va en prod aussi…



NodeJS, c’est typiquement le projet de dev qui voulait faire un petit truc sans pretention et qui a pris des proportions dantesques malgré lui et beaucoup trop vite.



Et puis bon, coder coté serveur en js, rien que ça… <img data-src=" /> <img data-src=" /> <img data-src=" /> <img data-src=" /> <img data-src=" /> <img data-src=" /> <img data-src=" /> <img data-src=" /> <img data-src=" /> <img data-src=" /> <img data-src=" /> <img data-src=" />



Folgore
Le 27/04/2016 à 14h 28

J’ai horreur de node.js mais heureusement qu’il y a des frameworks haut niveau pour manipuler cet api <img data-src=" />


MaLaaK
Le 27/04/2016 à 14h 34

Mais de manière générale, dans une même journée, passer du C# au JS, ça fait mal …


kj
Le 27/04/2016 à 15h 09

Fuck yeah !



J’utilise NodeJS pour un projet perso, qui fait juste de simple requêtes à une bdd et les renvoient en JSon, mon expérience s’arrête là… pour le moment.&nbsp;



&nbsp;





MaLaaK a écrit :



Mais de manière générale, dans une même journée, passer du C# au JS, ça fait mal …





+1



Kako78
Le 27/04/2016 à 15h 10







KP2 a écrit :



Sauf que c’est de la merde en barre vomie par un tas de nazes qui pensaient réinventer la roue en mieux mais qui sont tombés dans TOUTES les ornières apprises et évitées depuis des années par tous les package managers antérieurs.

Le plus drole a été le retrait de left-pad qui a fait foiré des centaines de modules…



Et puis bon, la communauté si prolifique est tellement prolifique qu’elle a plus tendance a laisser pourrir des milliers de modules en version alpha qu’autre chose… génial le suivi. Un projet de dev fait juste pour les devs sans se poser la question de la prod…





+1.

Le nombre de packages npm à l’abandon, c’est à pleurer.

Même chose pour les packages bower.



L’avantage d’un framework comme .NET, au moins c’est que tu as une bonne cohérence entre les APIs et c’est maintenu.



Maintenant, j’utilise quand même beaucoup NodeJS, mais plutôt pour développer des protos qui peuvent se déployer facilement sur une VM, voire même un poste client.



ValCapri Abonné
Le 27/04/2016 à 15h 31

@KP2 et @Kako78 :&nbsp;&nbsp;&nbsp;

C’est pareil sur tous les gestionnaires de dépendances (Maven, Bower, NPM, Composer, NuGet,…), il faut utiliser les librairies maintenue et/ou les forker. Sur GitHub, il y pléthore de repository abandonné aussi.&nbsp;



C’est pareil dans les App Store et Google Play, le nombre d’apps n’ont mis à jour est impressionnant. Certes, c’est désolant, et il faudrait penser de temps à autres penser à mettre cela dans des archives.&nbsp;&nbsp;



Concernant NodeJS, c’est pas mal du tout, un cauchemar pour les SysAdmins? Pourquoi? On a une version LTS si on veut ou la version courante/stable. Le tout est gérable via les paquets des distributions du moins pour le monde Linux. C’est possible de le monitorer et de voir les logs. Je ne vois pas en quoi, NodeJS est pire que PHP, Java et autres, à ce niveau là.


vloz
Le 27/04/2016 à 15h 32

&nbsp;Ts en tant que langage a vraiment aucun lien avec le C# (c’est juste que certains mec qui ont bossé sur le c# ont taffé sur le TS)… En tout cas pas plus que le JS…



D’ailleurs se qui se rapproche le plus du c# actuellement que ce soit en terme de noms, de syntaxe ou de fonctionnement, c’est clairement Dart.



(Edit: ce post etait en reponse à&nbsp;Munsh&nbsp;)


rastabanane Abonné
Le 27/04/2016 à 15h 47

Et la version 5 ?


Munsh
Le 27/04/2016 à 15h 52

J’vais pas te contredire, ça serait absurde et faux, mais si j’ai fait la remarque c’est parceque VS permet de mixer très aisément les projets mêlant les deux.



En tout cas c’est comme ça que j’y suis venu, bossant auparavant sur du js et du C# en parallèle :)


statoon54
Le 27/04/2016 à 15h 53







Obidoub a écrit :



Nodejs le cauchemar des sysadmin.





J’approuve&nbsp;<img data-src=" />



&nbsp;Dans le cas où le besoin en interactivité est requise, j’utilise le couple reactjs + rails . Sinon pour le reste rails c’est un pur&nbsp;<img data-src=" />.&nbsp;&nbsp;



&nbsp;



KP2 a écrit :



+10000000000

A chaque fois qu’un client m’annonce qu’il veut intégrer NodeJS à son appli, je lui demande 5 min, je me place en position foetale dans un coin et je pleure un peu.

Ensuite, je reviens et il m’expose son idée que je peux joyeusement démonter…





Faut avouer que npm , bower et la quantité de modules avec des dépendances foireuses ça exaspère lol&nbsp;



KP2
Le 27/04/2016 à 16h 16







ValCapri a écrit :



@KP2 et @Kako78 :   

C’est pareil sur tous les gestionnaires de dépendances (Maven, Bower, NPM, Composer, NuGet,…), il faut utiliser les librairies maintenue et/ou les forker. Sur GitHub, il y pléthore de repository abandonné aussi.







Quand je parle de package managers antérieurs, j’ai plutot tendance à penser à APT et RPM qui, eux, savent ce que c’est que maintenir un repo durablement avec un haut niveau de qualité et stabilité. Les trucs que tu cites sont aussi mauvais ou presque que npm.

Le problème dans tout ce bazar c’est qu’il n’y aucun controle sur les versions de packages proposés. Y’a meme pas de controle sur l’entrée dans le repo. Et je parle meme pas de qualité…







ValCapri a écrit :



C’est pareil dans les App Store et Google Play, le nombre d’apps n’ont mis à jour est impressionnant. Certes, c’est désolant, et il faudrait penser de temps à autres penser à mettre cela dans des archives.







Je sais pas les details pour Google play mais pour l’AppStore, il y des controles. Assez pour que pleins de devs ont trouvé le moyen de chialer quand ça a été mis en place (mais tout le monde s’est habitué depuis).

Si une app ne fonctionne pas, elle est éjectée.

Mais bon, la problèmatique pour les stores n’est pas tout a fait la même…







ValCapri a écrit :



Concernant NodeJS, c’est pas mal du tout, un cauchemar pour les SysAdmins? Pourquoi?







Parce qu’il n’y a pas de script de demarrage, parce que le monitoring est chiant a faire, parce que deployer ce truc et les modules qui vont avec, c’est long, chiant et la gestion des dependances est tellement pourrie que t’es jamais sur que ca va marcher.

Et enfin, le suivi des modules justement est tellement degueulasse que les mises a jour sont toujours une aventure dont tu ne peux pas etre le héro… et si, pour une raison ou une autre, les devs ont malheur de sauter qq versions, t’es bon pour requalifier l’ensemble de l’appli.

Bref, on peut se plaindre des packages systeme linux mais c’est le pays des bisounours a coté…







ValCapri a écrit :



On a une version LTS si on veut ou la version courante/stable. Le tout est gérable via les paquets des distributions du moins pour le monde Linux. C’est possible de le monitorer et de voir les logs. Je ne vois pas en quoi, NodeJS est pire que PHP, Java et autres, à ce niveau là.







PHP, Java et autres sont matures. Ils release pas tous les mois avec des modifications majeures pleines de régressions.



Je reproche pas à NodeJS d’exister. Je lui reproche d’être autant poussé en prod alors qu’il n’est encore clairement pas prêt pour cela. Ca viendra mais pour l’instant, c’est carrément pas taillé pour.



Honnêtement,&nbsp; j’ai toujours pas compris comment des gens ont pu apprécier développer en Javascript au point de le vouloir côté serveur.



Pire, que ceux-ci aient pensé que ce serait une bonne idée. Et de le proposer au reste du monde avec le sourire.


Munsh
Le 27/04/2016 à 16h 24

C’est assez aisé à comprendre pourtant : c’est le langage phare des navigateurs ;)


sr17
Le 27/04/2016 à 16h 31









ValCapri a écrit :



@KP2 et @Kako78 :   

C’est pareil sur tous les gestionnaires de dépendances (Maven, Bower, NPM, Composer, NuGet,…), il faut utiliser les librairies maintenue et/ou les forker. Sur GitHub, il y pléthore de repository abandonné aussi. 



C’est pareil dans les App Store et Google Play, le nombre d’apps n’ont mis à jour est impressionnant. Certes, c’est désolant, et il faudrait penser de temps à autres penser à mettre cela dans des archives.  



Concernant NodeJS, c’est pas mal du tout, un cauchemar pour les SysAdmins? Pourquoi? On a une version LTS si on veut ou la version courante/stable. Le tout est gérable via les paquets des distributions du moins pour le monde Linux. C’est possible de le monitorer et de voir les logs. Je ne vois pas en quoi, NodeJS est pire que PHP, Java et autres, à ce niveau là.







Peut être parce que ce truc improbable arrive à commettre l’exploit de combiner presque toutes les tares qu’on peut trouver dans d’autre langages…. en y rajoutant les siennes.



Bref, si j’avais du imaginer dans mes cauchemars les plus fous ce qui aurait pu s’approcher du pire environnement de programmation jamais inventé, ça ressemblerait certainement à ça.



Et pour ceux qui arrivent encore à trouver ça bien parce qu’ils sont jeunes, rendez vous dans quelques années quand vous aurez perdu tous vos cheveux devant des projets impossibles à maintenir parce que la moitié des bibliothèques qui les composeront auront été abandonnées et remplacées par de nouveaux trucs à la mode.




jojofoufou
Le 27/04/2016 à 16h 54

Très très bon ce thread, une avalanche de vomi, avec une majorité de gens qui n’ont jamais touché a la techno 😂



Je sors le classique Stackshare&nbsp;http://stackshare.io/nodejs pour vous rappeler que Node est utilisé en prod sur de gros services chez: 9gag, Netflix, Uber, &nbsp;Medium, DuckDuckGo, Viadeo, Lendix, Chauffeur Privé et j’en passe…



Concernant les SysOps… je partage votre frustration, ne pas avoir su prendre le virage DevOps, et ne plus servir a grand chose, c’est forcément inquiétant.


spidermoon
Le 27/04/2016 à 16h 57





  • Développement à l’ancienne C++ avec MFC ou .NET, accès base ODBC. Installation manuelle sur les postes client. Un seul langage à connaitre et à débugger. simple et performant

  • Développement presque aussi ancien Applet Java + JDBC, pas d’installation, facile à débugger.

  • Développement moderne : java/php + css + html + maven/gradle + hibernate/jpa + serveur web et/ou jee + spring (parfois) + le framework Javascript à la mode, actuellement c’est Angular JS.





    On ne jamais vraiment si ça va marcher, ni comment ça peut marcher, et quand ça fonctionne, on ne touche surtout plus au pom, à moins de vouloir flinguer les centaines de dépendances, tout en espérant que ça continuera à fonctionner avec les nouvelles versions d’IE/Firefox/Chrome <img data-src=" />

    Quand y’ à un bug, c’est direction stackoverflow ou à 90% d’autres développeurs de par le monde on rencontrés les mêmes problèmes… problèmes que l’on n’aurait jamais eu dans l’ancien temps <img data-src=" />


Munsh
Le 27/04/2016 à 17h 03

Ah, quand même. Que dire de plus ?


sr17
Le 27/04/2016 à 17h 45







jojofoufou a écrit :



Très très bon ce thread, allez, une avalanche de vomi, avec une majorité de gens qui n’ont jamais touché a la techno 😂



Je sors le classique Stackshare&#160http://stackshare.io/nodejs pour vous rappeler que Node est utilisé en prod sur de gros services chez: 9gag, Netflix, Uber,  Medium, DuckDuckGo, Viadeo, Lendix, Chauffeur Privé et j’en passe…



Concernant les SysOps frustrés… je partage votre frustration, ne pas avoir su prendre le virage DevOps, et ne plus servir a grand chose, c’est forcément inquiétant.







Le PC fut certainement l’un des ordinateurs les plus médiocre jamais conçu. Cela n’a pourtant pas empêché de très grandes entreprises de l’acheter… et des milliers de programmeurs de subir son horrible mode segmenté pendant de longues années…



Des experts ont expliqué cela par un phénomène amusant : un produit médiocre permet à de nombreuses sociétés de vivre en fournissant des solutions pour combler ses tares. En retour, ces sociétés ont intérêt à parler de ces produit médiocre, ce qui crée une mode.



sr17
Le 27/04/2016 à 18h 02







jojofoufou a écrit :



Très très bon ce thread, une avalanche de vomi, avec une majorité de gens qui n’ont jamais touché a la techno 😂

…







Pour ceux qui ont connu de vrais langages, plus on y touche, plus on vomit…. c’est normal docteur ?



Programmer en javascript, pour un programmeur, ça donne juste l’impression de manger de la viande de zombie après avoir goutté à la gastronomie.



Et dire qu’on avait cru toucher le fond avec PHP…



Du coup, je me demande ce qu’ils vont bien encore pouvoir nous inventer dans le futur…



jojofoufou
Le 27/04/2016 à 18h 16

Cool ton avis, il me semble quand même que tu as oublié d’y glisser des faits concrets ou des arguments valables 🙃


127.0.0.1
Le 27/04/2016 à 18h 25

Node.js, le futur langage incontournable pour tous les backends !!



Dire que j’avais déjà porté le code perl du serveur en python. Et que j’avais fini le portage python a ruby. Et que j’allais commencer le portage de ruby a Go.


KP2
Le 27/04/2016 à 18h 44







eax13 a écrit :



Honnêtement,  j’ai toujours pas compris comment des gens ont pu apprécier développer en Javascript au point de le vouloir côté serveur.







Ben ce truc pue le dev frontend rompu au js qui voulait se bricoler un “petit truc” coté serveur sans avoir à apprendre un nouveau langage/framework et qui a fini par pondre cette immondice.

J’arrive pas à expliquer cette situation autrement que par un énorme coup de fainéantise au tout départ… parce que, bon, les langages coté serveur, c’est pas ce qui manque. Y’en a vraiment pour tous les gouts…







eax13 a écrit :



Pire, que ceux-ci aient pensé que ce serait une bonne idée. Et de le proposer au reste du monde avec le sourire.







Le problème n’est pas chez ceux qui proposent le truc, le problème est chez ceux qui disent “ah ouais ! c’est une bonne idée, je vais faire pareil !”



KP2
Le 27/04/2016 à 18h 46







sr17 a écrit :



Et dire qu’on avait cru toucher le fond avec PHP…







Effectivement, le PHP était très décrié à l’époque mais il a su progresser… Mais que des mecs trouvent encore le PHP trop compliqué et préfèrent aller vers le JS, là, je sais plus quoi dire…



jojofoufou
Le 27/04/2016 à 18h 51

Les performances, la portabilité, la rapidité de développement, la faible emprunte mémoire ? Que tu aimes ou que tu n’aimes pas le langage c’est une autre histoire, mais ce n’est pas un argument recevable pour dire que c’est de la merde ;)


KP2
Le 27/04/2016 à 18h 52







spidermoon a écrit :



problèmes que l’on n’aurait jamais eu dans l’ancien temps <img data-src=" />







Mouais, sauf que “dans l’ancien temps”, c’était la foire au code spaghetti, aux bloatwares et autres horreurs monopostes bourrées de régressions avec une version payante tous les 2 ans…

Alors bon, pour ceux qui voulaient faire du sale, ils avaient aussi un vaste champs de mines à creuser devant eux…



jojofoufou
Le 27/04/2016 à 18h 53

Si tu penses que le Js est moins subtil que le PHP, c’est que tu n’a jamais fait autre chose que du jquery pour afficher de la neige sur le site de mamie.


Bejarid
Le 27/04/2016 à 18h 55







vloz a écrit :



&nbsp;Ts en tant que langage a vraiment aucun lien avec le C# (c’est juste que certains mec qui ont bossé sur le c# ont taffé sur le TS)… En tout cas pas plus que le JS…





Pour être précis, la personne qui a conçu le C# est la même que la personne qui a fait le TS. Derrière il y a une équipe pour gérer le compilo, ajouter des modules, mettre à l’épreuve le concept, en parler aux partenaires, etc., mais c’est bien 1 ingénieur qui a spécifier ces langages, pas des équipes.

&nbsp;

Source & nom de la personne donc je parle :https://en.wikipedia.org/wiki/Anders_Hejlsberg



Donc forcément, quand on est conçu par une seule et même personne, on se ressemble beaucoup, malgré les contraintes différentes.



brazomyna
Le 27/04/2016 à 19h 00







jojofoufou a écrit :



Très très bon ce thread, une avalanche de vomi, avec une majorité de gens qui n’ont jamais touché a la techno 😂






  Lol, tellement vrai.        







  &nbsp;






eax13 a écrit :



Honnêtement,&nbsp; j’ai toujours pas compris comment des gens ont pu apprécier développer en Javascript au point de le vouloir côté serveur.






  Dans la vie, on a souvent deux façons d'aborder une tendance lourde qui se trouve être en décalage avec sa propre opinion:        







  1) j'ai raison ; donc tous les autres sont forcément des cons / des abrutis aveuglés par l'effet de mode / des incompétents / des moutons suiveurs / des ... (rayer la mention inutile)   


  &nbsp;        


  2) s'il y a un grand nombre d'avis différents du mien (et sauf à penser que je suis supérieur à tout le monde), il y a sans doute des raisons valables. Ça devrait me pousser à remettre en cause quelques unes de mes 'certitudes' initiales.        


  &nbsp;        


  Je te laisse deviner laquelle de ces deux options aide le plus à avancer.        


  &nbsp;


brazomyna
Le 27/04/2016 à 19h 06







KP2 a écrit :



J’arrive pas à expliquer cette situation autrement que par un énorme coup de fainéantise au tout départ… parce que, bon, les langages coté serveur, c’est pas ce qui manque. Y’en a vraiment pour tous les gouts…





CQFD.

cf. option 1 ci-avant: je ne peux pas avoir tort, donc il y a forcément un problème chez les autres.

&nbsp;



KP2
Le 27/04/2016 à 19h 21







jojofoufou a écrit :



Les performances, la portabilité, la rapidité de développement, la faible emprunte mémoire ? Que tu aimes ou que tu n’aimes pas le langage c’est une autre histoire, mais ce n’est pas un argument recevable pour dire que c’est de la merde ;)







Performances et empreinte memoire, ouais bof… ça reste à prouver. Ce qu’on fait en node.js n’a pas grand chose a voir avec ce qu’on fait dans un autre langage donc c’est impossible à réellement évaluer.

Pour la portabilité, je vois pas en quoi c’est plus ou moins portable que du PHP, du J2EE ou du Rail

Et coté rapidité de développement, c’est pas si simple à évaluer… Aujourd’hui, quelque soit le langage, c’est pas tellement le code lui-même qui prend du temps car tous les langages sont bourrés de frameworks, de libs et de machins pour te faire gagner du temps. Le temps est reporté sur les tests, la doc, les specs, la maintenance de la PIC, les scripts de déploiement, la recette, etc et ça, c’est commun à tous les langages.

Alors ouais, gagner 10% de temps sur le code, c’est cool (et encore, je suis gentil) mais si coder prend 10% du total d’un projet alors ça fait peanuts au final.



KP2
Le 27/04/2016 à 19h 31







jojofoufou a écrit :



Si tu penses que le Js est moins subtil que le PHP, c’est que tu n’a jamais fait autre chose que du jquery pour afficher de la neige sur le site de mamie.







Ah non, bien au contraire ! Faut être une brutasse pour réussir à faire faire ce qu’on veut à JS et le débugger “correctement” (quand bien même ça serait possible)… c’est une évidence…

Le problème est quand un jeune dev sans expérience démarre avec ça, il n’apprend pas à “bien” coder. Il n’apprend pas non plus les concepts de base d’un langage moderne et ça ne va pas l’aider quand il s’agira de passer à une autre techno







brazomyna a écrit :



CQFD.

cf. option 1 ci-avant: je ne peux pas avoir tort, donc il y a forcément un problème chez les autres.







Je trolle beaucoup car j’aime bien troller les devs d’une manière générale et a fortiori sur les dev js

(t’inquiète, je sais troller confortablement les devs java et les devs php aussi)



Mais en fait, je m’en fous un peu de js. Si ça déconne à ce niveau, c’est très facile pour moi de poser le caca sur le bureau d’un dev et le regarder se dépatouiller avec un oeil amusé et un brin paternaliste.

Ce qui me gène surtout c’est la gestion des modules et des dépendances npm. C’est une vraie plaie pour un sysadmin et ça encourage le plus mauvais coté des (jeunes) devs : pousser des trucs pas assez testés et matures en prod.



jojofoufou
Le 27/04/2016 à 20h 00

Après, forcément, si tu compare un mauvais dev X, à un bon dev Y, quelque soit la techno, le dev Y s’en tirera mieux.&nbsp;

Un dev Node consciencieux n’aurais jamais eu de problème avec “l’affaire” leftpad/npm par exemple, les mecs le disent même clairement depuis longtemps “Don’t depend on machines you don’t own”&nbsp;


vloz
Le 27/04/2016 à 20h 01







Bejarid a écrit :



Donc forcément, quand on est conçu par une seule et même personne, on se ressemble beaucoup, malgré les contraintes différentes.





Heu… Ben je suis desolé mais je vois pas en quoi le TS s’approche du c# par rapport au JS… Je veux dire, pour utiliser les deux au quotidient, pour moi le TS ça reste juste une surcouche de JS apportant le typage et le support de certaines features d’es6/7… Mais rien qui soit propre au c# et qui se detache du JS… :/



jojofoufou
Le 27/04/2016 à 20h 03

SAY MARKÉ MICROSOFT SUR LA BOITE.


cyp Abonné
Le 27/04/2016 à 20h 14







KP2 a écrit :



Performances et empreinte memoire, ouais bof… ça reste à prouver. Ce qu’on fait en node.js n’a pas grand chose a voir avec ce qu’on fait dans un autre langage donc c’est impossible à réellement évaluer.







C’est tout de même un peux le pourquoi du comment…

&nbsp;Si node.js à du succès c’est entre autre parce qu’il à rendu accessible des technos qui n’était (et sont souvent encore) qu’a l’état de POC boiteux dans d’autres langages (à commencer évidemment par websocket).

&nbsp;Pour le reste on a le droit de ne pas aimer (JS j’ai jamais été fan non plus)&nbsp;mais ça serait idiot de&nbsp; nier les avancées qu’il procure.

Quand au problématique de déploiement et autres, avec les outils actuels et un minimum de bonnes pratiques ça reste assez anecdotique. C’est devenu tellement facile de packager tout son système et ses dépendances autour de son applicatifs et de le tester/versionner/dupliquer massivement avant toute utilisation que la question ne se pose plus vraiment.



durbamp
Le 27/04/2016 à 21h 04

Ahh NodeJS.

Quelle merde à foutre en prod!



Heureusement que la 6 n’est pas stable, sinon ce bouzin aurait changé de nom.



&nbsp;



&nbsp;


sr17
Le 28/04/2016 à 00h 25







jojofoufou a écrit :



Cool ton avis, il me semble quand même que tu as oublié d’y glisser des faits concrets ou des arguments valables 🙃







Parce que raisonnablement, il faudrait passer des heures, voir des jours de discussion pour vous faire entrevoir les justifications de conclusions qui sont le fruit d’années de métier.



Un avis, c’est déjà une information précieuse qu’il faut savoir apprécier comme tel. <img data-src=" />



stb007
Le 28/04/2016 à 07h 51







sr17 a écrit :



Parce que raisonnablement, il faudrait passer des heures, voir des jours de discussion pour vous faire entrevoir les justifications de conclusions qui sont le fruit d’années de métier.



Un avis, c’est déjà une information précieuse qu’il faut savoir apprécier comme tel. <img data-src=" />





Tu sais moi aussi je vieillit mais cela ne m’empêche pas de ne pas devenir un vieux con, ca sert à ça la veille technologique, et aussi s’amuser à tester avant de parler et dire des conneries.

T’es génération COBOL ou JAVA en fait ?&nbsp; :p



lmarecha
Le 28/04/2016 à 07h 53







jojofoufou a écrit :



Très très bon ce thread, une avalanche de vomi, avec une majorité de gens qui n’ont jamais touché a la techno 😂



Je sors le classique Stackshare&nbsp;http://stackshare.io/nodejs pour vous rappeler que Node est utilisé en prod sur de gros services chez: 9gag, Netflix, Uber, &nbsp;Medium, DuckDuckGo, Viadeo, Lendix, Chauffeur Privé et j’en passe…



Concernant les SysOps… je partage votre frustration, ne pas avoir su prendre le virage DevOps, et ne plus servir a grand chose, c’est forcément inquiétant.





c’est pas parce que tout le monde cède a l’effet de mode que c’est une bonne solution. Il y a le pour et le contre. Comme toutes techno elle a sa place, mais pas partout pour tout. Ça reste un outil pour une situation donnée, tu ne met pas une visse avec un marteau,&nbsp; sauf si tu es a Paris (vieille expression, mettre une vis a la parisienne)



martino
Le 28/04/2016 à 08h 21

Donc tu as commencé par bosser en 2011 sur des projets bâti sur des technos/concepts de 2004. 



   (2011 en .net il était plus courrant de partir sur du mvc voire pour les plus en avance sur uniquement avec du web api coté server (bien sur selon les besoins et &nbsp;l'existant)         


   Mais au delà de ce que tu vois au boulot (souvent daté car des projets ont du vécu) regardes tu les nouvelles approches d'architecture leur avantages /défauts ? &nbsp;quand les utiliser ?         


   Faire du thin server (server rest) avec du fat client (angular ou autre) c'est bosser avec les "trends" de 2011.         


   Mais encore une fois ça peut suffire selon les besoins.         







   J'ai 7 ans d'exp en c# et quand on regarde la modularisation du .net avec nuget je ne vois plus trop la différence entre choisir un package npm js pour éviter de faire une tâche from strach en js ou un package nuget en .net.         


   En fait si , il y en a une en full stack js si je choisis un package qui le prévoit il pourra fonctionner aussi bien coté client que server.         







   &nbsp;

jojofoufou
Le 28/04/2016 à 08h 34

Effectivement ! Je n’ai jamais dis le contraire, ni dénigré aucune techno, je pratique un peu de tout, Swift, Java, Kotlin, Go, Node, C, PHP, Scala, Rust…&nbsp;&nbsp;

Je dis simplement que Node.js à énormément de potentiel, que c’est clairement ma techno de choix pour du la majorité des services web que je dev, et qu’il ne faut clairement pas écouter les 2-3 gugus qui prétendent jouir de la science infuse.


athlon64
Le 28/04/2016 à 08h 37

Juste une précision sur Composer, son créateur regrette amerment que des gens foutent leurs lib dessus et ne les maintiennent pas. Il l’a clairement exprimé pendant une conf, si les gens pouvaient arreter de mettre leur moindre lib dessus et que ca pouvait etre utilisé seulement pour le projets maintenus. Ca lui fait du taff pour rien, ca alourdit le gestionnaire et a plus d’effets négatifs que positifs. <img data-src=" />


jun
Le 28/04/2016 à 08h 39

T’as déjà essayer PM2, Forever, ou le gestionnaire de StrongLoop (dont j’ai oublié le nom exacte), pour résoudre ton problème de script de démarrage ?&nbsp;



Pour un cas concret de performance, y’a le cas d’école Paypal. Pour passer un même projet de Java vers Node, ils ont gagner 20% de perf.&nbsp;



&nbsp;Pour tout ce qui est doc et test, les outils sont là. Le problème vient des dev =).


youtpout978
Le 28/04/2016 à 09h 48

A part sur le dernier projet sur lequel je bosse, je n’ai jamais bossé sur un projet depuis 0 donc c’est surtout de l’existant et c’est pour ça que c’était plus souvent du WebForms que du MVC, donc j’ai rarement la maîtrise sur ce je quoi je bosse, et oui je me tiens au courant je suis dvp.com, et ce qui se passe sur la faire .net essentiellement, je reste ouvert d’esprit mais pour faire du JS au quotidien si j’ai le choix je préfère faire du c#.

Pour les Ws c’est une équipe essentiellement composé de dev PHP donc WS en symphony 2 (des équipes maitrisant Node ça court pas les rues).



Si demain je doit développer un nouveau site je le ferais en Asp.net MVC avec peut être du angular si le besoin se ressent, et du Web Api pour la couche Service, histoire de pouvoir l’exploiter au mieux sur mobile et autre, je ne nie pas les avantages d’une solution JS avec le typage dynamique, la rapidité que peut avoir un Node vu que c’est très light et les modules peuvent être développer en C, mais par contre ça peut vite devenir problématique si le projet est gros et les algorithmes complexe …



J’ai jamais critiqué le système de module NPM, surtout que Nuget n’est pas une ref, pour avoir créer des packages Nuget (jamais testé pour npm), ça peut vite devenir la merde, surtout que le truc merde 1 fois sur 2 à la récup des packages (alors qu’il a une fonctionnalité pour ça) et que des fois il faut carrément forcer la réinstallation en ligne de commande quand on doit pas tous les supprimer pour les réinstaller ensuite…



Et ta pas toujours besoin des mêmes packages côté client et serveur, après je vais pas m’avancer dessus je n’ai jamais développer de véritable service tournant en permanence sur Node (en faite l’idée ne m’a jamais réellement traversé l’esprit), de toute façon je ne peux pas me passer de Linq …



Sinon j’attends de pied ferme Web Assembly, l’annonce de ce projet m’a mis du baume au cœur, mais je sais que ça ne sera pas exploitable avant quelques années.



Au faite une problématique des SPA le SEO, j’y ai été confronté, je conseil d’avoir une couche côté serveur pour gérer ça …


Plam
Le 28/04/2016 à 09h 51

Lol, ces vieux trolls ici.



Comme n’importe quel outil, il peut être mal utilisé. Par contre, sinon, c’est une très bonne techno. Je dis ça en connaissance de cause : je bosse dessus depuis 2013, et franchement, c’est très chouette.



Même former des nouveaux dessus se fait bien. Il faut comprendre comment ça marche, la boucle d’événements, les flux etc. C’est très flexible et puissant.



Et je l’utilise pas pour un petit projet perso, c’est en prod chez des milliers de clients.


Anakior
Le 28/04/2016 à 11h 59

C’est clair… Pfiou la bande de troll dis donc.



Node est une bonne techno. Elle a ces défauts mais comme toutes les technos utilisés. Il y a beaucoup d’applications stables aujourd’hui qui sont fait sous node et qui marche très bien et souvent plus rapidement qu’une même application sous php.



Alors, certes, on peut faire tout et n’importe quoi avec Node mais c’est pareil avec n’importe quoi d’autres.



Personnellement, je suis dev PHP, Symfony 2, angular et je tate du nodejs pour des projets annexes. Je le trouve très interessant justement par rapport à ces technos et bien sur ils se couplent très bien avec un angular. Et quitte à faire crier certains, je m’amuse bien plus avec un petit couple angular / node, qu’avec du Symfony ce qui ne me fait pas dire que ce dernier n’a pas de grosses qualités sur bien d’autres points.



La base c’est quand même de rester flexible et ne pas rester sur ces acquis non?


youtpout978
Le 28/04/2016 à 13h 20

En même temps PHP aussi c’est de la merde, en plus si t’utilise le combo JS+PHP+MYSQl tu tien là le combo gagnant de plus&nbsp;grosses bouses inventé dans le monde du développement&nbsp;<img data-src=" />&nbsp;(semi-troll)


athlon64
Le 28/04/2016 à 13h 29

Je sais pa trop si le problème vient de PHP ou de Symfony2 <img data-src=" />


sr17
Le 28/04/2016 à 13h 48







cyp a écrit :



C’est tout de même un peux le pourquoi du comment…

 Si node.js à du succès c’est entre autre parce qu’il à rendu accessible des technos qui n’était (et sont souvent encore) qu’a l’état de POC boiteux dans d’autres langages (à commencer évidemment par websocket).

 Pour le reste on a le droit de ne pas aimer (JS j’ai jamais été fan non plus) mais ça serait idiot de  nier les avancées qu’il procure.

Quand au problématique de déploiement et autres, avec les outils actuels et un minimum de bonnes pratiques ça reste assez anecdotique. C’est devenu tellement facile de packager tout son système et ses dépendances autour de son applicatifs et de le tester/versionner/dupliquer massivement avant toute utilisation que la question ne se pose plus vraiment.







Des programmeurs qui se ruent en masse sur une techno sous prétexte qu’elle offre les derniers gadgets kikoolol du moment, j’ai du voir ça des dizaines de fois. Mais la mode, ça finit toujours par passer. Et les programmeurs qui passent d’une techno à l’autre finissent toujours par se fatiguer et quitter le métier, que ce soit par le haut ou par le bas.







Plam a écrit :



Lol, ces vieux trolls ici.



Comme n’importe quel outil, il peut être mal utilisé. Par contre, sinon, c’est une très bonne techno. Je dis ça en connaissance de cause : je bosse dessus depuis 2013, et franchement, c’est très chouette.



Même former des nouveaux dessus se fait bien. Il faut comprendre comment ça marche, la boucle d’événements, les flux etc. C’est très flexible et puissant.



Et je l’utilise pas pour un petit projet perso, c’est en prod chez des milliers de clients.







PHP est utilisé bien plus massivement que NodeJs. Est ce une preuve de qualité ?



Pourtant, PHP possède de nombreux défaut en plus d’un moteur d’exécution vraiment peu optimisé.







jojofoufou a écrit :



Effectivement ! Je n’ai jamais dis le contraire, ni dénigré aucune techno, je pratique un peu de tout, Swift, Java, Kotlin, Go, Node, C, PHP, Scala, Rust…  

Je dis simplement que Node.js à énormément de potentiel, que c’est clairement ma techno de choix pour du la majorité des services web que je dev, et qu’il ne faut clairement pas écouter les 2-3 gugus qui prétendent jouir de la science infuse.







Du potentiel ?



Franchement, Le langage est mauvais, le paradigme de base est mauvais.



A partir de ce moment la, le seul potentiel de ce truc, c’est d’être une perte de temps et une voie sans issue de plus. Une mode de plus qui passera comme elle est venue…







Anakior a écrit :



C’est clair… Pfiou la bande de troll dis donc.



Node est une bonne techno. Elle a ces défauts mais comme toutes les technos utilisés. Il y a beaucoup d’applications stables aujourd’hui qui sont fait sous node et qui marche très bien et souvent plus rapidement qu’une même application sous php.







Vu le machin peu optimisé qui sers de moteur d’exécution à PHP, c’était vraiment pas dur…



Mais si votre critère, c’est la rapidité d’exécution, il y a vraiment mieux que ces deux bousins.





Alors, certes, on peut faire tout et n’importe quoi avec Node mais c’est pareil avec n’importe quoi d’autres.



Personnellement, je suis dev PHP, Symfony 2, angular et je tate du nodejs pour des projets annexes. Je le trouve très interessant justement par rapport à ces technos et bien sur ils se couplent très bien avec un angular.





En même temps, comparer de la daube avec de la daube…



Les programmeurs moderne manquent de compréhension du fonctionnement interne des langages et du fonctionnement à bas niveau des ordinateurs, c’est la raison pour laquelle ils peuvent utiliser quotidiennement des outils qui sont techniquement mauvais.





Et quitte à faire crier certains, je m’amuse bien plus avec un petit couple angular / node, qu’avec du Symfony ce qui ne me fait pas dire que ce dernier n’a pas de grosses qualités sur bien d’autres points.





Oui, c’est très amusant dans la phase “je met 3 gadgets à l’écran et je m’amuse avec”.



Par contre, quand il faudra rentrer dans le côté plus “chiant” de l’informatique, comme maintenir de très gros projets sur une période importante avec une énorme base de code et à débusquer toutes sortes de bugs, préparez vous à vivre des moments beaucoup moins fun…





La base c’est quand même de rester flexible et ne pas rester sur ces acquis non?





Si je faisais la liste de tous les langages et environnements que j’ai pu voir passer dans ma vie, vous seriez terrifiés. La plupart des informaticiens n’y ont d’ailleurs pas survécu.




jojofoufou
Le 28/04/2016 à 13h 52

En gros t’as toujours bossé sur de gros monolithes mal architecturés et tu prends ton cas pour une généralité ? Qu’est-ce que tu as déjà fait de concret en Js qui te permette de dire que c’est de la merde ?


sr17
Le 28/04/2016 à 14h 01







youtpout978 a écrit :



En même temps PHP aussi c’est de la merde, en plus si t’utilise le combo JS+PHP+MYSQl tu tien là le combo gagnant de plus grosses bouses inventé dans le monde du développement <img data-src=" /> (semi-troll)







Si seulement c’était un troll…



Le pire, c’est que beaucoup de programmeurs ne se rendent même pas compte à quel point tout ça est techniquement mauvais…. et de plus en plus mauvais.



Et quand il y a d’énormes problèmes à la base, au lieu de changer de base, ils pondent juste des couches d’abstraction pour encapsuler la merde.



Peut être que c’est le triste résultat d’un mode de formation ou l’on s’arrête au strict minimum pour pisser du code.



Et le pire, c’est que ce n’est même pas la peine d’essayer de discuter avec eux, la plupart des programmeurs n’ont aucune compréhension des “rouages” internes des outils qu’ils utilisent. Pas la peine d’essayer de leur expliquer comment est stockée une variable en PHP. Tout ce que vous direz se heurtera au mur de la “Funitude” dans laquelle ils sont plongés et les objectifs à court terme qu’on leur fixe pendant leur CDD.




Plam
Le 28/04/2016 à 14h 02

Merci de relire avec le doigt. J’ai pas dit qu’il était très utilisé, j’ai dit&nbsp;« il peut être mal utilisé ».Tu trolles toujours autant, genre tout est mauvais dans le JS, c’est utilisé par des gens qui comprennent rien… C’est ton opinion, mais elle n’a pas l’air d’être basée sur une grande compréhension du langage ni de son environnement. Venant de ta part, ça ne m’étonne pas : parler de choses que tu ne connais pas en faisant des jugements à l’emporte pièce, du sr17 dans le texte.


sr17
Le 28/04/2016 à 14h 32







jojofoufou a écrit :



En gros t’as toujours bossé sur de gros monolithes mal architecturés et tu prends ton cas pour une généralité ?







Bah quand tu sera vraiment confronté au problème, tu comprendra que le mythe de l’architecture parfaite issue de l’analyse descendante du “grand génie”, ça n’existe que dans les rêves de jeunes programmeurs pas encore déniaisés…




sr17
Le 28/04/2016 à 14h 54







Plam a écrit :



Merci de relire avec le doigt. J’ai pas dit qu’il était très utilisé, j’ai dit « il peut être mal utilisé ».Tu trolles toujours autant, genre tout est mauvais dans le JS, c’est utilisé par des gens qui comprennent rien… C’est ton opinion, mais elle n’a pas l’air d’être basée sur une grande compréhension du langage ni de son environnement. Venant de ta part, ça ne m’étonne pas : parler de choses que tu ne connais pas en faisant des jugements à l’emporte pièce, du sr17 dans le texte.







Sauf que c’est la triste réalité.



La très grande majorité des programmeurs Javascript ou PHP n’ont jamais vraiment pratiqué en C ni en assembleur, ils ne comprennent rien à la façon dont un langage est interprété ou compilé ni à la façon dont une machine fonctionne à bas niveau.



Parce que s’ils le comprenaient, la simple évocation du mot “Javascript” provoquerait des vomissements immédiats.



Et au final, ils ne comprennent pas les problèmes sur le long terme parce que la vérité, c’est que leur stage ou leur CDD de 6 mois sera terminé bien avant que les mots “gestion d’un projet à long terme” aient la moindre signification pour eux.



Donc au fond, quoi de surprenant à ce qu’ils ne comprennent pas la médiocrité de ce qu’ils utilisent ?





C’est ton opinion, mais elle n’a pas l’air d’être basée sur une grande compréhension du langage ni de son environnement





C’est le genre d’argument qui montre a quel point il est inutile et vain de vouloir discuter avec des jeunes qui se croient des génies incompris alors qu’ils ne font que répéter des erreurs monumentales déjà commises par le passé. Comme l’ont dit d’autres sur ce thread, ils veulent réinventer la roue et même plutôt la roue carrée…



Parce que la vérité, c’est que Javascript est un petit langage sans ambition qui a été écrit sur un coin de table. Et plus on regarde les détails de ce langage, que ce soit sa définition ou son implémentation, plus ça fait peur…



youtpout978
Le 28/04/2016 à 15h 11

T’inquiète beaucoup pense comme toi dans le domaine du dev, même certains dev dédié à ces plateformes connaissent leur défaillance, moi je ne connais pas assez PHP pour émettre un véritable jugement.



Ce que je trouve con c’est que tout le monde s’est entêté sur JS ces dernières années au point de nous pondre des moteurs d’exécution ultra-performant, alors qui l’aurait dédié à d’autre langage plus abouti ou même un nouveau, on aurai pu avoir de sacré résultat, mais beaucoup de boite défendent leurs point de vue, heureusement que ça évolue il y a qu’à voir WebAssembly pour s’en persuader.



Et je trouve ça con la mode du tout Web, sous prétexte du multi-plateforme et de la non nécessité de déploiement alors qu’en faite les navigateurs se transforment peu à peu en OS, résultat on a comme des micro-os qui tournent sur un autre OS qui potentiellement tourne sur une VM …


Plam
Le 28/04/2016 à 15h 19

La vrai question c’est comment est-ce possible d’être autant de mauvaise foi et pédant. Tu sais tout et tu as un avis parfaitement tranché, c’est qui est typique de quelqu’un qui ne sait même pas de quoi il parle.



Il y a des tonnes d’exemples de boîtes qui utilisent Node sur des gros projets. Et ça marche très bien.&nbsp;Paypal est une petite boîte qui recrute des CDD de 6 mois peut être ? Franchement, c’est même plus du troll à ce niveau.



Et pour parler de ce que je connais, ça fait 3 ans que je bosse sur un projet en Node. On est loin du stage. Et ça, c’est pas dans une grosse boîte où tu peux te planter, parce que c’est ma startup, pour un soft qu’on vend partout dans le monde.



Bref, tu as une vision biaisée de l’écosystème JS, probablement parce que tu n’y connais rien.


JCDentonMale
Le 28/04/2016 à 15h 29

sr17 a raison, on devrait coder la partie serveur en assembleur, le bas niveau, y’a que ça de vrai, c’est fait pour les vrais programmeurs, ceux qui en ont des grosses comme ça.

Tout le reste c’est de la merde et les jeunes sont des petits cons!


brazomyna
Le 28/04/2016 à 16h 01

Don’t feed the troll.


statoon54
Le 28/04/2016 à 16h 09







jojofoufou a écrit :



Qu’est-ce que tu as déjà fait de concret en Js qui te permette de dire que c’est de la merde ?






 Peut être le nombre de supersets (coffeescript,typescript,etc..) &nbsp;créent pour ce langage pour tenter d'avaler la pilule.&nbsp;&nbsp;      


Après il est difficile de contredire le fait que ce langage a énormément de tares . Suffit d'avoir déjà programmer dans d'autres langages pour s'en rendre compte.&nbsp;




Les performances de NodeJS ne sont pas si extraordinaire.

https://www.techempower.com/benchmarks/#section=data-r12&hw=peak&test=json 




Maintenant dans mon cas j'estime que JS en frontend c'est déjà bien suffisant et que si l'aspect performance s'en fait ressentir Go est certainement un bien meilleur choix puis au moins on étend son savoir et les pratiques à d'autres langages. La découverte d'un autre langage ne peut être que bénéfique. &nbsp;    


&nbsp;      


Après il faut aussi relativiser et prendre du recul sur les besoins des applications web, si c'est pour développer une application qui doit supporter 500req max/s , pas besoin de sortir la tronçonneuse.      


J'ai déjà vu des applications développés en + d'un an parce que le choix de la &nbsp;techno à la mode a été choisie, alors qu'il m'aurait fallu moins de 6mois pour la développer en Rails par exemple.


youtpout978
Le 28/04/2016 à 16h 09







JCDentonMale a écrit :



sr17 a raison, on devrait coder la partie serveur en assembleur, le bas niveau, y’a que ça de vrai, c’est fait pour les vrais programmeurs, ceux qui en ont des grosses comme ça.

Tout le reste c’est de la merde et les jeunes sont des petits cons!





Je ne pense pas que c’est ce qu’il a voulu dire, mais qu’avec des langages bas niveau tu comprendrai mieux comment la machine fonctionne et pourquoi les langages modernes sont parfois merdiques dans leur conception.



sr17
Le 28/04/2016 à 16h 56







Plam a écrit :



La vrai question c’est comment est-ce possible d’être autant de mauvaise foi et pédant. Tu sais tout et tu as un avis parfaitement tranché, c’est qui est typique de quelqu’un qui ne sait même pas de quoi il parle.







Toujours le problème récurent en informatique ou les jeunes cultivent l’illusion qu’ils sont les maitres du monde. Mais quand ils réalisent qu’il y a des anciens qui en savent bien plus qu’eux, rien ne va plus…





Il y a des tonnes d’exemples de boîtes qui utilisent Node sur des gros projets. Et ça marche très bien. Paypal est une petite boîte qui recrute des CDD de 6 mois peut être ? Franchement, c’est même plus du troll à ce niveau.



Et pour parler de ce que je connais, ça fait 3 ans que je bosse sur un projet en Node. On est loin du stage. Et ça, c’est pas dans une grosse boîte où tu peux te planter, parce que c’est ma startup, pour un soft qu’on vend partout dans le monde.



Bref, tu as une vision biaisée de l’écosystème JS, probablement parce que tu n’y connais rien.





Mouais, toujours les mêmes argument à deux balles “si tu critiques, c’est que tu connait rien”.



Vu que j’était déjà programmeur quand beaucoup ici n’étaient pas né, ça me fait bien marrer.





“Il y a des tonnes d’exemples de boîtes qui utilisent Node sur des gros projets”.





Et que doit t’on en conclure ?



Un petit passage par la case “histoire de l’informatique” vous démontrera qu’on ne compte pas les impasses technologiques qui ont été utilisées un temps par beaucoup de monde.





Et pour parler de ce que je connais, ça fait 3 ans que je bosse sur un projet en Node. On est loin du stage. Et ça, c’est pas dans une grosse boîte où tu peux te planter, parce que c’est ma startup, pour un soft qu’on vend partout dans le monde.





Toutes les modes en informatique ont finalement la même cause : des gens qui voient une opportunité commerciale à investir dans une technologie naissante à un instant T. Mais à partir de ce moment la, ils vont avoir intérêt à pousser à fond cette technologie pour qu’un maximum de gens l’utilisent.



Une fois qu’on a compris la base de ce phénomène, on comprends pourquoi des produits médiocres ont eu de grand succès au mépris de toute considération technique.



Bill Gates explique parfaitement cela dans son livre “La route du futur” paru il y a très longtemps ou il expliquait comment un produit aussi médiocre que le PC avait réussi à tuer des concurrents bien meilleur sur le plan technique et comment les intérêts commerciaux ont poussé cette machine au détriment de toute autre considération.



sr17
Le 28/04/2016 à 17h 22







youtpout978 a écrit :



Je ne pense pas que c’est ce qu’il a voulu dire, mais qu’avec des langages bas niveau tu comprendrai mieux comment la machine fonctionne et pourquoi les langages modernes sont parfois merdiques dans leur conception.







C’est exactement comme cela qu’il faut le comprendre.



Oui, l’étude des langages de “bas niveau”, c’est précisément ce qui permet de comprendre que les caractéristiques des langages de programmation peuvent influer directement sur leurs performances.



De la même façon, le fait de gérer de gros projets sur le très long terme (bien plus que 3 ans) permet de comprendre en quoi certains langages facilitent la vie dans ce cadre en apportant de la rigueur et de la structuration.



C’est avec le recul qu’on comprends que la facilité immédiate de certains langage se paye plus tard dans le projet…



jojofoufou
Le 28/04/2016 à 17h 24

Arrête tout de suite de t’enfoncer mec, t’as clairement aucune idée de comment fonctionne V8 et t’as probablement jamais entendu parler de la libUV 😂


jojofoufou
Le 28/04/2016 à 17h 31

Cadeau:https://developers.google.com/v8/design#dynamic-machine-code-generation et une fois que tu te sentira chaud tu pourra jeter un œil aux sources, ensuite tu pourra dire ce que tu veux 😂


Munsh
Le 28/04/2016 à 17h 47







sr17 a écrit :



Mouais, toujours les mêmes argument à deux balles “si tu critiques, c’est que tu connait rien”.



Vu que j’était déjà programmeur quand beaucoup ici n’étaient pas né, ça me fait bien marrer.





Et ça se sent, tes propos sur Node ressemble étonnamment à ces vieux qui jugent via ce qu’ils ont vu sur le JT de TF1 des sujets qu’ils ne connaissent absolument pas.



sr17
Le 28/04/2016 à 17h 48







jojofoufou a écrit :



Arrête tout de suite de t’enfoncer mec, t’as clairement aucune idée de comment fonctionne V8 et t’as probablement jamais entendu parler de la libUV 😂







Encore un exemple qui montre pourquoi ça ne sers vraiment à rien de discuter avec les fanboys javascript.



Ils ne comprennent strictement rien au fonctionnement à bas niveau, mais ils croient dur comme fer dans leur dieu tout puissant : le grand mythe du Fabuleux Compilateur Magique. Un outil développé par “une grande boite” et donc forcément merveilleux.



C’est un mythe selon lequel n’importe quel langage pourrait devenir aussi performant qu’un autre grâce a la grande magie d’un outil qui résoudrait tout les problèmes par magie.



Quand à moi qui a écrit plusieurs interpréteurs et compilateurs dans ma vie, ça me fait réellement marrer de voir autant d’obscurantisme.



Et au passage, avant d’essayer de faire la leçon à plus fort que toi, va juste voir par curiosité en quoi est écrite ta fabuleuse “libUV” ….



Ah ben merde alors, pourquoi ils ne l’ont même pas écrite dans ce merveilleux langage qu’est Javascript. C’est vraiment trop con ça… Moi qui croyait que Javascript pouvait tout faire <img data-src=" />




Munsh
Le 28/04/2016 à 17h 57







sr17 a écrit :



Ah ben merde alors, pourquoi ils ne l’ont même pas écrite dans ce merveilleux langage qu’est Javascript. C’est vraiment trop con ça… Moi qui croyait que Javascript pouvait tout faire <img data-src=" />





C’est chaud mec, t’es tellement coincé dans ton trip que tu as oublié qu’avant tout un logiciel c’est fait pour répondre au mieux à un besoin.



Jamais quelqu’un n’a dit que Javascript pouvait, ou même devrait, tout faire. Par contre, parfois on peut l’utiliser pour effectuer tel ou tel job. D’autres technos auraient aussi pu le faire, chacune ses forces et faiblesses, tu fais ton choix selon le cadre de ton projet. Y’a aucune réponse universelle.&nbsp;&nbsp;



sr17
Le 28/04/2016 à 18h 10







Munsh a écrit :



Et ça se sent, tes propos sur Node ressemble étonnamment à ces vieux qui jugent via ce qu’ils ont vu sur le JT de TF1 des sujets qu’ils ne connaissent absolument pas.







Ouais, le gros cliché quoi.



L’ennui, c’est qu’a côté de la majorité de vieux qui ne comprennent rien, il y a aussi une minorité de vieux dont c’est le métier depuis très longtemps.



Sauf qu’en informatique, les jeunes partent du principe qu’ils n’ont strictement rien à apprendre de leurs prédécesseurs, ce qui les conduit à refaire les mêmes conneries.



Ce que vous ignorez, c’est qu’une grande partie des paradigmes des langages de programmation ont été posé bien avant les années 80. Même la programmation orientée objet et la programmation concurrente.



Je pense que vous seriez très surpris en étudiant tout ce qui s’est déjà fait par le passé.



Au final, en croyant innover, beaucoup de gens ne font que réinventer la roue.



LostSoul Abonné
Le 28/04/2016 à 18h 26

Ca sert à quoi encore NodeJS ?



-&gt;[]


sr17
Le 28/04/2016 à 18h 32







Munsh a écrit :



C’est chaud mec, t’es tellement coincé dans ton trip que tu as oublié qu’avant tout un logiciel c’est fait pour répondre au mieux à un besoin.



Jamais quelqu’un n’a dit que Javascript pouvait, ou même devrait, tout faire. Par contre, parfois on peut l’utiliser pour effectuer tel ou tel job. D’autres technos auraient aussi pu le faire, chacune ses forces et faiblesses, tu fais ton choix selon le cadre de ton projet. Y’a aucune réponse universelle.







Sauf que c’est grâce à ce mode de pensée typique du monde commercial qu’on se retrouve aujourd’hui avec une multiplication de langages médiocres qui ont chacun un champ d’action très réduit.



Et je ne suis pas d’accord avec toi. Je pense qu’un langage bien pensé peut s’avérer suffisamment universel pour convenir à la très grande majorité des besoins.



Si on prends l’exemple de PHP, le langage lui même n’a rien de très particulier. Ses quelques points forts peuvent parfaitement être ajoutés à n’importe quel langage. D’ailleurs, ce langage peut t’il seulement être qualifié de bonne réponse à la demande dans son champ d’application primaire quand on connait le peu d’optimisation de son moteur d’exécution ?



Mais le jour ou vous comprendrez que la multiplication des langages qu’on observe actuellement tiens bien moins de l’innovation que d’objectifs commerciaux d’entreprises qui espèrent une place au soleil, vous aurez fait un grand pas vers moins de naïveté.



youtpout978
Le 28/04/2016 à 18h 42

Toute façon quand ça parle de JS ça finit toujours en clash …


jojofoufou
Le 28/04/2016 à 19h 09

Okay, tu semble sûr de toi, du coup tu me conseilles quoi comme archi et comme techno pour un produit de gestion de flotte temps réel qui sera servi sur des clients mobile et sur du web ?


sr17
Le 28/04/2016 à 19h 12







jojofoufou a écrit :



Cadeau:https://developers.google.com/v8/design#dynamic-machine-code-generation et une fois que tu te sentira chaud tu pourra jeter un œil aux sources, ensuite tu pourra dire ce que tu veux 😂







Désolé de te décevoir, mais je connait bien tout ça.



Pour situer le contexte, nous sommes face à un compilateur jit très perfectionné et optimisé.



Mais ce que les néophytes comme toi ignorent tant ils sont impressionné par cette débauche de complexité qu’ils ne comprennent pas, c’est que la meilleure machine d’exécution du monde écrite par les meilleurs spécialistes ne fera pas de miracles avec un langage qui ne leur permet pas d’être optimal.



Par exemple, un langage fortement typé permet à un compilateur de n’avoir aucun doute sur le type d’une variable à l’exécution. Il peut donc optimiser mieux et d’emblée. Et surtout, se passer de truffer le code de vérifications incessantes à l’exécution qui ont un coût non négligeable.



Autre exemple édifiant, le document parle de la création des classes et de la façon dont les propriétés sont ajoutées dynamiquement avec tout l’overhead que la méthode suppose et que le document reconnait “It might seem inefficient to create a new hidden class whenever a property is added…”. C’est la qu’on tombe sur le cul. Franchement, quand on compare avec l’efficience de la gestion des objets en C++ et son overhead quasiment nul, la comparaison se passe de commentaire.



Bref, on voit bien que vous n’avez pas creusé le sujet…



Gundar
Le 28/04/2016 à 19h 44







sr17 a écrit :



Désolé de te décevoir, mais je connait bien tout ça.



Pour situer le contexte, nous sommes face à un compilateur jit très perfectionné et optimisé.



Mais ce que les néophytes comme toi ignorent tant ils sont impressionné par cette débauche de complexité qu’ils ne comprennent pas, c’est que la meilleure machine d’exécution du monde écrite par les meilleurs spécialistes ne fera pas de miracles avec un langage qui ne leur permet pas d’être optimal.



Par exemple, un langage fortement typé permet à un compilateur de n’avoir aucun doute sur le type d’une variable à l’exécution. Il peut donc optimiser mieux et d’emblée. Et surtout, se passer de truffer le code de vérifications incessantes à l’exécution qui ont un coût non négligeable.



Autre exemple édifiant, le document parle de la création des classes et de la façon dont les propriétés sont ajoutées dynamiquement avec tout l’overhead que la méthode suppose et que le document reconnait “It might seem inefficient to create a new hidden class whenever a property is added…”. C’est la qu’on tombe sur le cul. Franchement, quand on compare avec l’efficience de la gestion des objets en C++ et son overhead quasiment nul, la comparaison se passe de commentaire.



Bref, on voit bien que vous n’avez pas creusé le sujet…







Faut bien qu’Intel vende des proco en même temps <img data-src=" />



jojofoufou
Le 28/04/2016 à 19h 45

Argument ad hominem, c’est la fin.



T’inquiete pas pour moi, j’ai deja eu a mettre les mains dans V8 et dans la LibUV, je connais mes outils et je connais ses limites ;)


sr17
Le 28/04/2016 à 19h 51







jojofoufou a écrit :



Okay, tu semble sûr de toi, du coup tu me conseilles quoi comme archi et comme techno pour un produit de gestion de flotte temps réel qui sera servi sur des clients mobile et sur du web ?







Je sais que ça fait un peu réponse de normand, mais ça dépends beaucoup des impératifs que tu vise d’emblée, du nombre de client que tu prévoit à moyenne échéance, des compétences que tu as sous la main et des détails de ton projet.



Une bonne évaluation ça tient compte de tout. Donc c’est difficile de te répondre comme ça sans risquer de t’induire en erreur.




sr17
Le 28/04/2016 à 19h 52







Gundar a écrit :



Faut bien qu’Intel vende des proco en même temps <img data-src=" />







C’est clair… <img data-src=" />



jojofoufou
Le 28/04/2016 à 20h 02

@sr17 Et l’overhead lié a la vtable, ca te fait pas faire des cauchemars ?


sr17
Le 28/04/2016 à 20h 52







jojofoufou a écrit :



@sr17 Et l’overhead lié a la vtable, ca te fait pas faire des cauchemars ?







Au moins, c’est bien de poser des vraies questions <img data-src=" />



Et bien regarde à quoi sers la vtable, dans quel cas elle est utilisée (ou ne l’est pas) et surtout, de combien (et comment) se traduit cet overhead dans les cas ou il se produit.



Ou sont donc les raisons de faire des cauchemars ?



youtpout978
Le 28/04/2016 à 21h 12







Gundar a écrit :



Faut bien qu’Intel vende des proco en même temps <img data-src=" />





Par contre ils sont à la rue sur mobile et c’est là ou le besoin se fait le plus ressentir, je vois que mon tel commence à galérer sur mon front full JS et certains autre site mobile blindé de JS, après c’est vrai qu’il est un peu vieux mon tel.



Munsh
Le 29/04/2016 à 07h 49

Je suis bien plus ennuyé par la multiplication des frameworks qui font quasiment la même chose à un poil de paradigme prêt que par les langages, qui bougent si peu sur le tiobe annuel.



L’aspect ‘commercial’ de la chose m’est bien inégal, même si je vois où tu veux en venir. Mais quitte à choisir je préfère un peu d’excès dans le trop que de subir du trop peu. J’apprécie assez le foisonnement actuel, malgré ses travers.



Au moins ça a le mérite de fournir à tous des technos, des environnements, des communautés dans lesquelles il pourra s’épanouir (et apporter à son tour sa contribution).&nbsp;


youtpout978
Le 29/04/2016 à 07h 58

Les frameworks JS, ça me rappel ça :&nbsp;Framework JS


Zed-K
Le 29/04/2016 à 08h 18

Je me trompe peut être, mais l’impression que j’ai dans cette discussion… c’est que tout le monde a raison.

&nbsp;

Chacun travaille sur des projets radicalement différents, aux besoins en terme de rapidité de développement et de temps de maintenance tout aussi différent.



Chaque point de vue/techno peut se défendre en fonction du type du projet sur lequel on bosse.



Pour caricaturer à l’extrême, on ne développera pas un système de train d’atterrissage en JS, tout comme on ne codera pas un site marchand en assembleur.


brazomyna
Le 29/04/2016 à 08h 33







Munsh a écrit :



J’apprécie assez le foisonnement actuel, malgré ses travers.







Critiquer le foisonnement en prétextant que ça ferait baisser la qualité globale est à peu près aussi pertinent que de dire que le web ‘cay2laMayrde’ parce que pour un site de qualité tu as 1000 over-blogs de Kevin de 14 ans.



En fait, c’est tout l’inverse: ça n’empêche pas d’avoir toujours autant de projets de qualité disponibles, et ça permet d’augmenter la diversité et l’émergence de ‘bonnes idées’ qui peuvent ensuite apporter leur pierre à l’édifice, quitte à ce qu’elles soient reprises partiellement dans les ‘gros’ projets.



Le monde du libre a un peu toujours fonctionné comme ça d’ailleurs.



n poussant le bouchon à trolldi, on pourrait même dire que ce genre de remarque ça vient le plus souvent de gens peu habitués à un minimum de liberté, pour lesquels il leur faut absolument au-dessus d’eux une “entreprise qui leur veut du bien” en choisissant ce qui est bon pour elles à leur place ; genre Microsoft et son écosystème.

&nbsp;

&nbsp;



youtpout978
Le 29/04/2016 à 15h 51

L’interêt des dictatures dans le monde du dev c’est qu’elles avancent souvent plus vite que les autre, où ils passent 15 ans à se mettre d’accord sur des normes, les validés, les supportés, il n’y a qu’à voir l’évolution du C# par rapport à JAVA.


sr17
Le 29/04/2016 à 17h 31







Zed-K a écrit :



Je me trompe peut être, mais l’impression que j’ai dans cette discussion… c’est que tout le monde a raison.

 

Chacun travaille sur des projets radicalement différents, aux besoins en terme de rapidité de développement et de temps de maintenance tout aussi différent.



Chaque point de vue/techno peut se défendre en fonction du type du projet sur lequel on bosse.



Pour caricaturer à l’extrême, on ne développera pas un système de train d’atterrissage en JS, tout comme on ne codera pas un site marchand en assembleur.







Je serais tenté de dire que tu as raison, chaque technologie ayant ses forces et faiblesses, ses usages et ses applications.



Le problème, c’est que de nos jours, ça ne se passe pas du tout comme ça dans la réalité.



A cause des principes liés au système commercial dont j’ai parlé plus haut, une technologie peut s’étendre bien au delà de son domaine de pertinence. Un peu comme le principe de peter dans le monde du travail.



Ce qui n’était au départ qu’un petit langage de script sans prétention pour navigateur écrit sur un coin de table et sans beaucoup de réflexion se retrouve progressivement utilisé dans des vraies applications toujours plus importantes, jusqu’à devenir même l’unique langage applicatif de certains os (comme Firefox Os).

Le comble, c’est de voir Javascript arriver dans l’embarqué alors que de toute évidence, ce langage est aux antipodes des qualités qu’un langage doit avoir pour cet usage.



Quand on observe ce phénomène, on se demande comment nous avons pu en arriver la.

La réponse est tristement simple : a cause du web, les programmeurs Javascript ont été formés à la chaine.



Il n’en faut pas plus pour que des entreprises commerciales se disent qu’elles feront du pognon en commercialisant des grille pains qui fonctionnent avec Javascript.

Dans le monde commercial, tout ce qui a du sens, c’est le nombre et les parts de marché. La qualité et la pertinence technique n’ont aucun sens pour les commerçants.



Voila comment de nos jours le marché fonctionne au détriment de la qualité et du bon usage des technologies.



Bejarid
Le 29/04/2016 à 19h 18







vloz a écrit :



Heu… Ben je suis desolé mais je vois pas en quoi le TS s’approche du c# par rapport au JS… Je veux dire, pour utiliser les deux au quotidient, pour moi le TS ça reste juste une surcouche de JS apportant le typage et le support de certaines features d’es6/7… Mais rien qui soit propre au c# et qui se detache du JS… :/





Tu expliques à des gens qui trouvent que les deux langages se ressemblent quelque chose de faux, je te corrige, c’est tout.



Après ton avis sur un langage que manifestement tu connais peu, j’avoue je m’en fout pas mal :)



lossendae
Le 01/05/2016 à 10h 32

De maniere générale, tu n’aimes pas les languages dynamiques faiblement typés.



Mais quand bien même tu aurais raison, c’est une bonne choses ces languages de noob, ça donne du travail à BEAUCOUP de mondes.&nbsp;



C’est ùême une double chance dans le fond, ça te permet également d’avoir moins de concurrence sur ton poste. T’imagines l’angoisse&nbsp; si tous la grande majorité des devs étaient aussi doués que toi ?



En revanche, on ne peut rien faire pour tes commentaires un rien pédant qui se base sur “J’ai raison, vous avez tous torts parce que vous êtes incompétents”.&nbsp; Un peu comme le chirurgien qui se ballade dans son cabinet et qui ne salue pas la secrétaire parce qu’elle est que secrétaire.

Niveau de compétences inversement proportionel au niveau d’humilité ? J’espere pour toi



&nbsp;


sr17
Le 01/05/2016 à 17h 35







lossendae a écrit :



De maniere générale, tu n’aimes pas les languages dynamiques faiblement typés.







Cela n’a rien à voir avec le fait d’aimer ou de détester, mais simplement d’utiliser le bon outil pour le bon usage.



Techniquement parlant, les langages dynamiques et faiblement typés sont des langages prévus pour faire du petit script de manière rapide, pas pour faire des gros projets.

Au niveau vitesse d’exécution, ces langages ne peuvent pas être compilés efficacement et n’offrent donc pas des performances optimales.

Du point de vue gestion de projet, leurs caractéristiques apportent de lourds inconvénients et finalement peu d’avantages.





Mais quand bien même tu aurais raison, c’est une bonne choses ces languages de noob, ça donne du travail à BEAUCOUP de mondes.





Je ne vois pas pourquoi ces langages seraient “des langages de noob”.



Dans la pratique, ce n’est pas parce qu’ils sont faiblement typés qu’ils serait pour autant plus simple d’écrire de vrais programmes avec. C’est une illusion.



Quand à l’informatique “qui donne du travail à beaucoup de monde”, elle donne surtout le sentiment aux donneurs d’ordre que le logiciel n’est pas un investissement pérenne et durable et que la seule voie d’optimisation serait dans la pression sur les salaires.





C’est ùême une double chance dans le fond, ça te permet également d’avoir moins de concurrence sur ton poste. T’imagines l’angoisse  si tous la grande majorité des devs étaient aussi doués que toi ?





Certains peuvent voir les choses ainsi.



Mais pour ma part, je suis fier de mon métier et j’ai la notion du travail bien fait.



Je ne vois pas la multiplication des langages inutiles, des technologies redondantes ou la généralisation de mauvais paradigmes techniques comme un facteur d’amélioration du métier de programmeur, ni un facteur de progrès de la condition humaine.





En revanche, on ne peut rien faire pour tes commentaires un rien pédant qui se base sur “J’ai raison, vous avez tous torts parce que vous êtes incompétents”.  Un peu comme le chirurgien qui se ballade dans son cabinet et qui ne salue pas la secrétaire parce qu’elle est que secrétaire.

Niveau de compétences inversement proportionel au niveau d’humilité ? J’espere pour toi





Merci de ne pas déformer mes propos en m’attribuant des paroles je n’ai jamais tenu ni même pensé. <img data-src=" />



Quand au problème d’humilité, il n’est pas la ou tu le penses.



Une erreur très courante chez de nombreux de jeunes qui se voient intelligents, c’est de croire que leur intelligence suffirait à remplacer l’expérience…



Nous, ce qu’on voit, c’est que cette jeune communauté est en train de bâtir des cathédrales sur du sable. Eux, ne le savent pas encore.



Surtout, ils ne réalisent pas encore que de devoir jeter le travail de ses plus belles années à la poubelle, c’est une punition terrible. <img data-src=" />



Quand on est jeune, on croit que tout ce qu’on connait est la pour rester. Quand on est plus agé, on mesure à quel point le temps peut changer les choses.



brazomyna
Le 01/05/2016 à 21h 10







sr17 a écrit :



de jeunes qui se voient intelligents, c’est de croire que leur intelligence suffirait à remplacer l’expérience…

&nbsp;

(…)

&nbsp;

Quand on est jeune, on croit que tout ce qu’on connait est la pour

rester. Quand on est plus agé, on mesure à quel point le temps peut

changer les choses.





Lol, l’âge faisaint, il ne se rend même plus compte qu’il se contredit lui-même dans le même post.



Overnumerousness
Le 01/05/2016 à 22h 40

Intéressant ce thread.

&nbsp;







brazomyna a écrit :



Lol, l’âge faisaint, il ne se rend même plus compte qu’il se contredit lui-même dans le même post.





Je ne vois pas en quoi.



Le problème des vieux, c’est qu’ils râlent dès qu’il s’agit de changer de techno, peu importent les&nbsp; technos de départ et d’arrivée. Du coup ça n’est jamais évident de prendre leurs plaintes au sérieux, on se dit que c’est le comportement habituel.



Et pourtant, moi qui suis modestement jeune et noob, je souscris aux propos de sr17, du moins sur le fond.

J’ai bien aimé l’explication qu’il présente sur les mécanismes d’expansion de la médiocrité.

&nbsp;

Je n’ai peut-être pas une grande expérience mais je trouve le javascript incroyablement laid…

typage faible, typage dynamique, portée des variables, comportements aberrants pour un humain, le hissage (« hoisting ») qui complique parfois la compréhension du comportement du programme… autant de sources possibles de bogues qu’on n’aurait jamais avec du C, du Java, du Scala, ou bien d’autres. Et pour quels bénéfices ?

&nbsp;

Ce qui m’amuse le plus sont ceux qui critiquent l’arrogance de sr17 (et c’est vrai qu’il y en a), sans s’apercevoir de la leur. Les fameux « si tu fais de la merde avec javascript c’est que tu ne sais pas t’en servir ». Ben tiens, j’aimerais bien voir leur code à ceux-là, je suis sûr qu’il ne leur est jamais arrivé de s’arracher les cheveux parce que js est mal-foutu. Ça ne veut pas dire qu’on ne peut rien faire avec. On peut bien creuser sa tombe avec une fourche.



J’aime bien le côté web pour son accessibilité, écrire un petit script et l’exécuter directement dans le navigateur, je trouve ça top. Comme l’admet sr17, les scripts c’est très bien pour avoir rapidement un petit proto.

C’est dans ces conditions et, à mon sens, uniquement dans ces conditions, que le typage faible (peu éviter de restructurer du code si on s’aperçoit que des mauvais choix ont été pris initialement) ou le typage dynamique (= boucher un trou sur une chambre à air avec un chewing-gum) peuvent avoir du sens. Et même dans ce cas d’utilisation je préfère le python (quoiqu’avec des réserves sur les indentations).



&nbsp;Comme youtpout, je n’arrive pas à ne pas voir dans le projet WebAssembly une envie de pouvoir se passer de JS. Moi aussi je suis bien curieux de savoir ce que ça donnera.



brazomyna
Le 02/05/2016 à 11h 50

Je ne vais pas répéter ce que j’ai déjà expliqué dans le détail dans les news précédentes (cf. mon historique de posts). Mais: 




  1) le JS n'est pas un langage OO classique qui serait mal foutu. C'est autre chose (prototypal) ; et quand on a enfin compris et intégré cette approche différente, ses principes et bonnes pratiques liés, on arrête de le comparer à ce qu'il n'a pas vocation à être.        







  2) le mouvement 'nodeJS' c'est tout l'inverse de trois noob qui refont les conneries du passé ; le mouvement est désormais porté essentiellement par des dev. reconnus mondialement qui n'ont plus grand chose à prouver dans ce langage comme dans d'autres.        


  &nbsp;        


  3) JS n'est pas parfait. Comme tous les autres langages (à moins que le void* en C/C++ soit l'alpha et l'omega du bons code) ; mais en utilisant à bon escient ses bons aspects, on libère énormément d'énergie pour le dév. expérimenté. Cf. les bouquins de D.Crockford par exemple.       







  4) le typage fort et autres carcans artificiels ne sont pas l'alpha et l'omega d'un 'bon' code. On peut tout autant faire de la m*** en C++ que du code magnifique en JS. D'une façon générale, la qualité et la maintenabilité d'un projet est beaucoup moins fonction des qualités techniques d'un langage que d'autres paramètres ayant trait à la gestion de projet (CI, TDD, ...) et la qualité des développeurs (patterns, ...).        


  &nbsp;

Overnumerousness
Le 02/05/2016 à 12h 18







brazomyna a écrit :





  1. le JS n’est pas un langage OO classique qui serait mal foutu.





    Ah mais ce n’est pas ce que je dis : je dis que JS est un langage mal foutu sur un paradigme mal utilisé. C’est différent !







    brazomyna a écrit :



  2. JS n’est pas parfait. Comme tous

    les autres langages (à moins que le void* en C/C++ soit l’alpha et

    l’omega du bons code) ; mais en utilisant à bon escient ses bons

    aspects, on libère énormément d’énergie pour le dév. expérimenté. Cf.

    les bouquins de D.Crockford par exemple.





    C’est un peu le discours relativiste « il n’y a pas de mauvais langages, il n’y a que de mauvais usages », mais je n’y adhère pas. Je suis convaincu qu’à usages égaux, on pouvait faire bien mieux que JS.









    brazomyna a écrit :



  3. le typage fort et autres carcans artificiels ne sont pas l’alpha et

    l’omega d’un ‘bon’ code. On peut tout autant faire de la m* en C++ que

    du code magnifique en JS. D’une façon générale, la qualité et la

    maintenabilité d’un projet est beaucoup moins fonction des qualités

    techniques d’un langage que d’autres paramètres ayant trait à la gestion

    de projet (CI, TDD, …) et la qualité des développeurs (patterns,

    …).

    &nbsp;





    Le code magnifique en JS, je demande à voir. La merde en C++ en revanche, ça ira ^^



    L’un des problèmes de JS c’est que tu peux faire beaucoup de choses, tu peux faire trop de choses.

    Je préfère un langage avec « carcans » comme tu dis dès le début, plutôt que de devoir attendre quelques années qu’un ensemble de « bonnes pratiques » émergent, qu’il faudra apprendre (et donc en revenir à se mettre soi-même des carcans, sauf que ce n’est plus ton compilateur qui te garantie les bonnes pratiques, mais un énième framework).



Munsh
Le 02/05/2016 à 12h 31







tnetennba a écrit :



C’est un peu le discours relativiste « il n’y a pas de mauvais langages, il n’y a que de mauvais usages », mais je n’y adhère pas. Je suis convaincu qu’à usages égaux, on pouvait faire bien mieux que JS.



&nbsp;



Un langage n’est pas voué à être statique, mais évolue. Le js d’aujourd’hui n’est pas celui d’hier. Le faire mieux, ça fait des années qu’ils sont dessus :)



Et pour autant, s’il y’a multitudes de langages, c’est qu’il y a multitudes d’usages, mais ça veut surtout dire que ça laisse de la place pour tout le monde, y compris JS.&nbsp;

&nbsp;&nbsp;

Et puis, c’est pas tellement comme s’il y avait matière à débat, la preuve a été faite moults fois, les applis tournent, les projets en sont satisfaits, et pas des moindres projets… Qu’on puisse à titre personnel trouver le langage dégueulasse, ça passe, discuté sa viabilité par contre c’est complètement absurde.

&nbsp;



tnetennba a écrit :



Le code magnifique en JS, je demande à voir. La merde en C++ en revanche, ça ira ^^&nbsp;&nbsp;



&nbsp;



L’élégance n’est pas question de syntaxe ^^. Même si je suis parmi les premiers à bouder celle de JS, tu es bien obligé d’admettre quand un code est bien conçu, propre et intelligent qu’il est bôwh :3.&nbsp;



vloz
Le 02/05/2016 à 12h 40

mdr t tro intelijan


Overnumerousness
Le 02/05/2016 à 12h 57







Munsh a écrit :



&nbsp;



Un langage n’est pas voué à être statique, mais évolue. Le js

d’aujourd’hui n’est pas celui d’hier. Le faire mieux, ça fait des années

qu’ils sont dessus :)





Et je veux bien croire qu’il y a eu des progrès, mais à moins de vouloir perdre toute rétrocompatibilité en changeant de version de ton langage, tu as des contraintes très fortes qui t’empêchent de corriger de mauvais choix initiaux. Ça fait partie de ce qui me gêne avec JS, j’ai le sentiment qu’on devra se trimbaler de mauvaises spécifications jusqu’à sa mort (qui n’est pas prête d’arriver).







Munsh a écrit :



Et pour autant, s’il y’a multitudes de

langages, c’est qu’il y a multitudes d’usages, mais ça veut surtout

dire que ça laisse de la place pour tout le monde, y compris JS.&nbsp;





Le problème est surtout que JS est utilisé pour de plus en plus d’usages. Là où il devrait se contenter d’être un langage pour faire des protos, il devient omniprésent. Il y a une sorte de bulle autour du web : on finit par faire du client léger parce que le client a entendu que c’était à la mode, alors que son besoin c’est du client lourd — après c’est son argent hein, c’est lui qui décide, mais comme disait sr17 ce n’est pas un choix basé sur des considérations techniques.

&nbsp; |Munsh a écrit : | &nbsp;&nbsp;

|Et puis, c’est pas tellement comme s’il y avait matière à débat, la

preuve a été faite moults fois, les |applis tournent, les projets en sont

satisfaits, et pas des moindres projets… Qu’on puisse à titre

|personnel trouver le langage dégueulasse, ça passe, discuté sa viabilité

par contre c’est complètement |absurde.

&nbsp;

Je répète : on tout faire en js. On peut creuser sa tombe avec une fourche. Mais même si Pierre, Paul et Jacques sont contents de leur fourche, je peux bien râler parce qu’une pelle me conviendrait mieux, non ?











Munsh a écrit :



&nbsp;

L’élégance

n’est pas question de syntaxe ^^. Même si je suis parmi les premiers à

bouder celle de JS, tu es bien obligé d’admettre quand un code est bien

conçu, propre et intelligent qu’il est bôwh :3.&nbsp;





Tout à fait :) D’ailleurs la syntaxe js est pas si mal je trouve, en dehors de ce triple égal que je trouve fort inconvenant.



C’est justement ce que j’aimerais voir, un exemple de code bien conçu, propre et intelligent, exploitant les spécificités js et ne pouvant trouver d’égal (c’est-à-dire de code aussi propre et intelligent) du côté de Java/C# ou Scala (je ne suis pas vraiment fan du C/C++, même si je respecte pas mal leurs capacités) ;)

&nbsp;&nbsp;



Munsh
Le 02/05/2016 à 13h 26

J’vais répondre en bloc pour gagner quelques temps :).



Pour l’opposition considérations techniques / choix arbitraire (mode, marketing, etc) : je l’exclus de fait du propos, honnêtement c’est pas parce que certains font de mauvais choix que l’outil est mauvais en soi.



Dans le même genre d’idée, je crois qu’on est quelque part sur une longueur d’onde pas si éloignée sur l’histoire de la fourche et de la pelle. Il y’a des exemples ou JS est la petite fourchette en plastique qu’on te refourgue au class croute, et d’autres où clairement JS est la pelle en adamantium ? On est tout à fait conscient que ça n’est pas l’outil le plus adéquate pour telle situation X ou Y. On dit juste que pour Z, ça fonctionne très bien, d’ailleurs de nombreux projets le plébiscite.



Quant à la syntaxe, je sais pas moi je la supporte vraiment moyen. Mais je code bien plus souvent en Haxe (ou en F) qu’en JS, donc je survis ^^.



&nbsp;Pour ton second point, je crois me souvenir que Douglas Crockford a été mentionné plus haut, je suis sur que tu devrais pouvoir trouver des exemples sur son site :3. (Moi, la flemme de chercher ? Pas du tout ^^)


sr17
Le 02/05/2016 à 22h 25







brazomyna a écrit :



Je ne vais pas répéter ce que j’ai déjà expliqué dans le détail dans les news précédentes (cf. mon historique de posts). Mais: 




  1) le JS n'est pas un langage OO classique qui serait mal foutu. C'est autre chose (prototypal) ; et quand on a enfin compris et intégré cette approche différente, ses principes et bonnes pratiques liés, on arrête de le comparer à ce qu'il n'a pas vocation à être.








On sent que vous partez du principe que ce serait nouveau et inconnu.



Mais ce que vous devriez savoir, c’est que les langages dynamiques et le typage faible, ça existe depuis vraiment TRES longtemps…



C’est en étudiant l’histoire des langages de programmation et leur fonctionnement que l’on comprends les raisons pour lesquelles les programmeurs se sont détournés des langages dynamiques et du typage faible.







  1. le mouvement ‘nodeJS’ c’est tout l’inverse de trois noob qui refont les conneries du passé ; le mouvement est désormais porté essentiellement par des dev. reconnus mondialement qui n’ont plus grand chose à prouver dans ce langage comme dans d’autres.





    Sauf que c’est toujours le même cirque à chaque mode qui passe.



    L’avantage d’avoir vu 95% de ces modes passer (et trépasser), c’est qu’on ne se laisse plus impressionner par tout ce cinéma, on regarde plutôt ce que les techno ont vraiment dans le ventre. <img data-src=" />





  2. JS n’est pas parfait. Comme tous les autres langages (à moins que le void* en C/C++ soit l’alpha et l’omega du bons code) ;





    Et depuis quand l’usage du void * serait une pratique de programmation recommandée en C/C++ ?





    mais en utilisant à bon escient ses bons aspects, on libère énormément d’énergie pour le dév. expérimenté. Cf. les bouquins de D.Crockford par exemple.





    J’ai du entendre ça un nombre incalculable de fois au sujet des langages.



    Un jour vous comprendrez qu’en programmation, c’est comme en politique. Il faut se méfier comme de la peste de tout ces jolis concepts aguicheurs qui paraissent si séduisants sur le papier mais qui le sont beaucoup moins dans la vraie pratique que ce que leurs fans essayent de faire croire.





  3. le typage fort et autres carcans artificiels ne sont pas l’alpha et l’omega d’un ‘bon’ code. On peut tout autant faire de la m* en C++ que du code magnifique en JS.





    Le problème, c’est juste qu’il n’est pas possible d’écrire du bon code en Js ou en PHP <img data-src=" /> (J’assume le côté provoc de cette phrase)



    Parce que le bon code, ça ne s’arrête pas juste a ce que tu écrit, c’est aussi (et surtout) ce que le processeur exécute. <img data-src=" />



    Or, l’une des raisons d’être du typage fort, c’est de permettre au compilateur d’optimiser beaucoup mieux le code résultant.



    D’ailleurs, ceux qui se sont demandé comment écrire le mieux possible en PHP et Javascript savent que dans ces langages mal optimisés, le cout de l’abstraction est élevé. Donc écrire du code optimisé en terme de vitesse d’exécution ne va pas toujours de paire avec un découpage optimal de la structure.





    le typage fort et autres carcans artificiels





    Sauf que le typage fort en programmation n’a jamais été un carcan.



    Malgré leur typage faible, Javascript et PHP sont très éloignés de la souplesse, de la puissance de manipulation des données et de la diversité des types permises par C/C++.



    Un langage comme C/C++ peut faire absolument tout ce qu’on veut, y compris même implémenter du typage faible : Si cela n’était pas vrai, PHP et Javascript n’auraient pas pu été implémentées en C.



    Contrairement à ce que vous pensez, fixer le type d’une variable n’est pas un carcan. C’est au contraire une aide précieuse qui permet de se simplifier la vie en gagnant beaucoup de temps en plus d’éviter quantités de problèmes par la suite, d’éviter bon nombre d’effets de bord sur des erreurs de type, de documenter son code et d’optimiser le binaire résultant.



    D’ailleurs, ceux qui nous vantent la soit disant simplicité de certains langages devraient vraiment se demander si l’existence d’un opérateur aussi capillotracté que === est vraiment une preuve de simplicité.





    D’une façon générale, la qualité et la maintenabilité d’un projet est beaucoup moins fonction des qualités techniques d’un langage que d’autres paramètres ayant trait à la gestion de projet (CI, TDD, …) et la qualité des développeurs (patterns, …).





    Sauf que dans la vraie réalité, il est beaucoup plus simple d’arriver à déstructurer un projet avec certains langages qu’avec d’autres.



    Mais c’est bien connu, dans les SS2I, personne n’utilise jamais de stagiaires <img data-src=" />



brazomyna
Le 02/05/2016 à 22h 59

Mais oui sr17, tu as entièrement raison, comme toujours d’ailleurs.

Et sache que tu n’es pas seul: chacun de nous prie chaque soir en espérant que demain encore ton aura magnifique pourra à nouveau nous éclairer de ta sagesse infinie. :oui:


Munsh
Le 03/05/2016 à 07h 56

Quel est le rapport avec les SS2I ? Au bout d’un temps vouloir avoir absolument raison, ça aboutit à ce genre d’argument hors sujet.



Sans parler de vitesse d’exécution / structure &nbsp;optimal… &nbsp;JS n’est pas C. Si tu ne peux pas comprendre qu’on ne cherche pas à faire du C en JS, lâche l’affaire :/


youtpout978
Le 03/05/2016 à 09h 22

Le JS est tellement poussé de partout qu’on commence à avoir des applis bureau en JS, exemple le plus parlant Visual Studio code de Microsoft (c’est réalisé en TypeScript par contre).


sr17
Le 03/05/2016 à 16h 58







Munsh a écrit :



Quel est le rapport avec les SS2I ? Au bout d’un temps vouloir avoir absolument raison, ça aboutit à ce genre d’argument hors sujet.







Entre nous, tu sais très bien que j’ai raison <img data-src=" />



Tous les programmeurs se prennent pour des cadors. Sauf que dans la vraie réalité, l’usage d’un langage fortement typé qui pousse à un minimum de rigueur, ça n’est vraiment pas du luxe pour aider à garder la structuration des projets.





Sans parler de vitesse d’exécution / structure  optimal…  JS n’est pas C. Si tu ne peux pas comprendre qu’on ne cherche pas à faire du C en JS, lâche l’affaire :/





Sauf que c’est justement ce que beaucoup ne comprennent pas.



Si je fais la comparaison entre Javascript et les vrais langages de programmation, c’est précisément parce qu’aujourd’hui, certains veulent nous refourguer Javascript pour tous les usages possibles et imaginables.