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.
- Liste complète des nouveautés
- Télécharger Node.js 6.0 (Current)
- Télécharger Node.js 4.4.3 (Stable)
Commentaires (115)
#1
Nodejs le cauchemar des sysadmin.
#2
Aussi celui des dévs " />
#3
On ne peut toujours pas faire des imports?
#4
#5
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…
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.
#6
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.
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.
#7
Jamais été tenté par TypeScript avec ton passif JS et c# ?
#8
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 ?
#9
#10
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.
Aujourd’hui plus que jamais, l’intérêt d’être développeur c’est associer le meilleur de tous les mondes …
#11
#12
#13
J’ai horreur de node.js mais heureusement qu’il y a des frameworks haut niveau pour manipuler cet api " />
#14
Mais de manière générale, dans une même journée, passer du C# au JS, ça fait mal …
#15
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.
#16
#17
@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à.
#18
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 à Munsh )
#19
Et la version 5 ?
#20
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 :)
#21
#22
#23
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.
Pire, que ceux-ci aient pensé que ce serait une bonne idée. Et de le proposer au reste du monde avec le sourire.
#24
C’est assez aisé à comprendre pourtant : c’est le langage phare des navigateurs ;)
#25
#26
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 http://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… 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.
#27
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 " />
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 " />
#28
Ah, quand même. Que dire de plus ?
#29
#30
#31
Cool ton avis, il me semble quand même que tu as oublié d’y glisser des faits concrets ou des arguments valables 🙃
#32
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.
#33
#34
#35
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 ;)
#36
#37
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.
#38
#39
#40
#41
#42
#43
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.
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”
#44
#45
SAY MARKÉ MICROSOFT SUR LA BOITE.
#46
#47
Ahh NodeJS.
Quelle merde à foutre en prod!
Heureusement que la 6 n’est pas stable, sinon ce bouzin aurait changé de nom.
#48
#49
#50
#51
Donc tu as commencé par bosser en 2011 sur des projets bâti sur des technos/concepts de 2004.
#52
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.
#53
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. " />
#54
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 ?
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.
Pour tout ce qui est doc et test, les outils sont là. Le problème vient des dev =).
#55
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 …
#56
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.
#57
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?
#58
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 " /> (semi-troll)
#59
Je sais pa trop si le problème vient de PHP ou de Symfony2 " />
#60
#61
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 ?
#62
#63
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.
#64
#65
#66
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 …
#67
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. 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.
#68
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!
#69
Don’t feed the troll.
#70
#71
#72
#73
#74
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 😂
#75
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 😂
#76
#77
#78
#79
#80
Ca sert à quoi encore NodeJS ?
->[]
#81
#82
Toute façon quand ça parle de JS ça finit toujours en clash …
#83
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 ?
#84
#85
#86
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 ;)
#87
#88
#89
@sr17 Et l’overhead lié a la vtable, ca te fait pas faire des cauchemars ?
#90
#91