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

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.

Commentaires (115)


Nodejs le cauchemar des sysadmin.


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


On ne peut toujours pas faire des imports?








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…



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.


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.


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


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 ?








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…



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 …








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.









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=" />



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


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


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









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.



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


&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;)


Et la version 5 ?


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 :)








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;









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.


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










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.




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.






  • 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=" />


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








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.









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…



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


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.








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









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…



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 ;)








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…



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.








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.









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;








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;









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.









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.



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;








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… :/



SAY MARKÉ MICROSOFT SUR LA BOITE.








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.



Ahh NodeJS.

Quelle merde à foutre en prod!



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



&nbsp;



&nbsp;








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=" />









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









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)



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;

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.


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=" />


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


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 …


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.


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?


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)


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








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.




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 ?








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.




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.








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…










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…



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 …


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.


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!


Don’t feed the troll.








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.








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.









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.









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…



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 😂


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 😂








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.









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=" />










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;









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.



Ca sert à quoi encore NodeJS ?



-&gt;[]








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



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


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 ?








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…









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=" />



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 ;)








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.










Gundar a écrit :



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







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



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








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 ?









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.