Node.js passe la sixième vitesse

Posté par  (site web personnel) . Édité par M5oul, Florent Zara, palm123 et Benoît Sibaud. Modéré par Florent Zara. Licence CC By‑SA.
Étiquettes :
37
12
mai
2016
JavaScript

Node.js est la principale implémentation du langage JavaScript côté serveur. Elle utilise V8, le moteur JavaScript de Google Chrome, et vient d’atteindre la version 6.0.0 le 26 avril 2016.

Logo Node.js

La montée de version de V8 vers la version 5.0 a d'ailleurs permis une meilleure prise en charge d'ES6, avec 93 % des fonctionnalités couvertes. Parmi les autres nouveautés, on trouve des performances accrues (notamment pour le chargement des modules), une meilleure stabilité et utilisabilité des API JavaScript (notamment Buffer et File System).

Peu de temps après la sortie de la version 6.0.0, des failles OpenSSL ont été annoncées, ce qui a conduit à la sortie d'une version 6.1.0.

Les différentes versions

Ce n'est pas facile de suivre les différentes branches de node.js suite au fork io.js, qui a ensuite refusionné avec node.js. Toutefois, la situation n'est que temporaire et on devrait y voir plus clair d'ici la fin de l'année. En attendant, voici un petit résumé :

  • node.js 0.10 : une vieille version, qui est toujours celle packagée par Debian notamment, est en phase de maintenance jusqu'à octobre 2016 (ensuite, ce sera les oubliettes)
  • node.js 0.12 : pareil, mais la phase de maintenance durera jusque décembre 2016
  • node.js 4 : c'est la version LTS actuelle. Elle sera en LTS Active jusqu'avril 2017, puis passera en phase de maintenance pour une année supplémentaire
  • node.js 5 : c'est juste une version de développement et elle s'arrêtera dans 2 mois
  • node.js 6 : c'est également une version de développement (current) et deviendra une version LTS en octobre 2016. D'ici là, il pourra encore y avoir des changements assez conséquents (montée de version de V8 notamment).

Donc, pour le moment, il est recommandé d'utiliser node.js 4 en production et de commencer à faire tourner des tests avec node.js 6 dans les environnements d'intégration continue pour détecter les régressions. À noter que pas mal de modules npm compilés sont en train d'être corrigés pour node.js 6.

Npm3

Node.js 5 et 6 viennent avec npm3 et non plus npm2. Ce changement est majeur.

Avec npm2, les dépendances d'une dépendance s'installaient dans le répertoire node_modules de la dépendance. Et donc, on pouvait avoir un même module avec deux versions différentes au sein d'un même projet, si deux dépendances incluaient ce module dans des versions différentes. Avec npm3, ce n'est plus le cas. Toutes les dépendances (directes et indirectes) sont installées dans le node_modules du projet.

Ce changement a permis de régler pas mal de problèmes sous Windows, où les dépendances de dépendances de dépendances de… (vous voyez l'idée) avaient des chemins très longs, trop longs pour Windows. Il permet également de s'assurer qu'un module n'est installé qu'une seule fois par projet, ce qui est très utile pour les projets front-end qui utilisent npm.

Par contre, le passage à npm3 n'a pas que des bons côtés. Ce changement a introduit pas mal de régressions et la situation commence juste à se stabiliser. Npm3 est également de façon notoire bien plus lent que npm2.

ES6, ES7 et la suite

ES6, ou ES2015, la version actuelle du standard qui décrit le langage JavaScript est le fruit d'un long travail et les implémentations des moteurs JavaScript supportent la plupart des fonctionnalités. Que ce soit chez Google, Mozilla, Microsoft ou Apple, on est proche des 100 %, avec jusque quelques bugs sur des cas très particuliers ou la volonté de ne pas implémenter les Tail Calls Optimisation (car ils posent des problèmes).

Pour autant, tout n'est pas rose. Les nouvelles fonctionnalités ne sont pas aussi optimisées que le reste. Les benchmarks montrent qu'il est fréquent que du code ES6 soit entre un et trois ordres de grandeur plus lent que son équivalent en ES5. Les moteurs vont combler ces différences mais cela risque de prendre encore quelques mois ou années.

Autre point noir : les modules d'ES6. L'équipe derrière node.js a fait une proposition pour prendre en charge les modules d'ES6 (en disant que s'ils vont faire les modules d'ES6, ce sera de cette façon, mais il se peut aussi qu'ils ne fassent rien car ils considèrent que les modules d'ES6 sont une mauvaise chose et que le standard devrait étudier à nouveau cette question). Cette proposition n'a pas plu à une partie de la communauté car elle introduit l'extension .mjs, ce qui va poser problème pour les modules qui seront utilisables à la fois par node.js et les navigateurs. On a donc eu le droit à une contre-proposition et les noms d'oiseau ont volé une nouvelle fois sur Twitter. La situation semble enlisée pour le moment.

ES7, ou ES2016, est beaucoup plus léger. C'est principalement l'arrivée de l'opérateur ** pour calculer des puissances et de Array.prototype.includes pour savoir si un élément fait partie d'un tableau.

Par contre, on attend toujours async/await. Cette solution devrait permettre d'écrire du code asynchrone de manière beaucoup plus propre et est même décrite comme la solution miracle depuis plusieurs années. Seul problème, aucun moteur JS ne l'a implémentée pour le moment.

Aller plus loin

  • # Le javascript

    Posté par  (site web personnel) . Évalué à 10.

    Tout d'abord, merci pour cette dépêche.
    Pas facile de s'y retrouver dans cet écosystème Javascript avec tout qui évolue à une vitesse sans précédent.
    De mon coté, après avoir regardé de prêt AngularJS et MEAN (MongoDB, Express, Angularjs, Node.js), je suis passé vers meteor/Blaze à la mise à mort d'AngularJS V1.
    Meteor est un très bel outil, simple à prendre en main, mais il est dépendant de tout l'écosystème Javascript et suis donc le mouvement. Il est donc maintenant conseillé d'utiliser React.js à la place de Blaze. Ca me va bien, mais, en même temps, avec la version 1.3, ils ont pris en charge ES6.
    Donc, tous les exemples Meteor-React sont en ES6, mais, pour apprendre React, les tuto du site React sont en ES5, même si l'équipe même de React conseille d'utiliser ES6.
    Je ne parle pas de la gestion native des package npm en plus de ceux de meteor lui-même.
    Bref, d'un truc simple à utiliser (meteor 1.0), on passe à un truc bien plus compliqué du fait que toutes les briques évoluent à grande vitesse en n'hésitant pas à repartir d'un tableau blanc.
    Quand on est en bas de l'échelle, il faut suivre :)

    • [^] # Re: Le javascript

      Posté par  (Mastodon) . Évalué à 10.

      Et encore, t'as l'air de pas trop mal suivre.

      Moi j'en suis au niveau où je ne vois pas vraiment ce que c'est Node.js… en concurrence de quelle techno ça vient ?
      Javascript côté serveur, ça veut dire quoi ? C'est tout simplement pour faire en javascript ce qu'on pourrait faire en perl/ruby/langage-qu-on-veut-en-CGI ?

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Re: Le javascript

        Posté par  (site web personnel) . Évalué à 6.

        C'est tout simplement pour faire en javascript ce qu'on pourrait faire en perl/ruby/langage-qu-on-veut-en-CGI ?

        C'est ça. Et un des avantages affichés du projet, c'est pour une équipe de développeurs de pouvoir simplement passer du frontend au backend sans avoir à nécessairement maîtriser d'autres langages.

        • [^] # Re: Le javascript

          Posté par  (site web personnel) . Évalué à 4.

          Pour comprendre encore mieux, un exemple de serveur web en node js :

          var http = require('http');
var handleRequest = function(request, response) {
  response.writeHead(200);
  response.end("Bonjour le monde!");
}
var www = http.createServer(handleRequest);
www.listen(80);

          Et pour le lancer :

          $ node server.js

          • [^] # Re: Le javascript

            Posté par  . Évalué à 5.

            Je n'ai pas encore compris l'utilité d'avoir un serveur web de ce style alors que le premier Apache venu l'explose en performances : pus rapide, moins de CPU, moins de mémoire, etc.
            Les quelques logiciels que j'ai testé ayant ce genre de serveur commencent à ramer dès qu'on se connecte avec 4 clients. De mémoire il y en avait un en Ruby, les autres je ne sais plus.

            Si c'est utilisé, il doit bien y avoir une raison. Ou même plusieurs.
            Question : à quoi ça sert ?

            • [^] # Re: Le javascript

              Posté par  (site web personnel) . Évalué à 8.

              Question : à quoi ça sert ?

              Probablement parce que les applications nodejs ne sont pas là majoritairement pour faire serveur de fichiers statiques mais surtout pour offrir une plateforme applicative complète, et que servir des fichiers statiques n'est probablement pas un truc assez critique dans la plupart des cas.

              Je pense par exemple à des applications qui tournent sur des appliances, accessibles par une dizaine d'administrateurs maxi qui ont juste besoin de downloader le front et de passer quelques requêtes REST par ci par là et recevoir quelques notifications websockets de temps en temps.

              Ca serait en effet idiot d'utiliser nodejs juste pour servir les pages d'un magasin en ligne…

              Après, je suis persuadé qu'un backend en Ruby, en Go, en Rust est probablement plus performant, mais comme je le disais plus haut, le gros avantage de nodejs, c'est que c'est du JavaScript, et beaucoup d'applications s'orientent maintenant vers un partage de code entre le backend et le frontend, sans parler des app "isomorphiques".

            • [^] # Re: Le javascript

              Posté par  . Évalué à 10.

              Pour la plupart, à pas grand chose a part l'effet de mode.
              Node est bon dans des cas où l'i/o est très grand face au cpu, étant base sur un modèle de non blocking i/o, ça permet de maintenir un très grand nombre de connexions clientes ouvertes.
              L'exemple de base, c'est une appli de chat.

              Le problème, c'est que tu te tapes un écosystème jeune, un gestionnaire de dépendance qui a défrayé la chronique récemment, et pas qu'un peu, et un langage franchement bof.
              Et dès que tu devient cpu bound, tu bloques l'event loop, et c'est une réelle catastrophe.

              Disons que l'async io et l'event loop single threade, c'est pas forcément trivial à coder, le langage se trimballe des tares, et dans la plupart des cas où je l'ai vu utilisé, un modèle threade aurait tres largement tenu la charge, tout en évitant la complexité de l'async.

              Bref, c'est une techno qui a du bon, mais tres souvent utilisée dans des cas pas adapté du tout.

              Linuxfr, le portail francais du logiciel libre et du neo nazisme.

      • [^] # Re: Le javascript

        Posté par  . Évalué à 8.

        Node.js c'est un packaging du moteur javascript V8. À la base c'est pour faire un serveur web pour javascript (comme tu le dirais pour tomcat avec java ou wsgi pour python ou plank pour perl…). Ça n'utilise pas (Fast)CGI. Mais comme ça fonctionne assez bien, c'est devenu la base pour faire du js hors du navigateur. Globalement ça permet d'écrire du js avec des API pour faire véritablement tout ce que tu veux (comme Atom par exemple).

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Le javascript

        Posté par  . Évalué à 4. Dernière modification le 12 mai 2016 à 14:52.

        Moi j'en suis au niveau où je ne vois pas vraiment ce que c'est Node.js… en concurrence de quelle techno ça vient ?

        Ca permet "simplement" d'utiliser javascript sur autre chose que des pages web :) Et comme ça utilise un moteur provenant de chez Google (Chrome), on peut s'attendre a se que ce moteur évolue fortement.

        S.a.r.a.h utilise NodeJS il me semble

        Quand il sera aussi polyvalent que ses congénères, il sera une digne alternative à Python par exemple :)

        Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

    • [^] # Re: Le javascript

      Posté par  . Évalué à 10.

      Je commence, vraiment tout doucement, à me mettre au Web et ça fait un moment que Meteor me faisait de l'oeil. J'en tenté un premier tuto. Je me suis retrouvé avec un fichier HTML quasi vide qui intégrait une bonne trentaine de Js. Ca fait peur quand même.

      Je me demande si c'est vraiment la voie à suivre pour un truc optimisé.

      • [^] # Re: Le javascript

        Posté par  . Évalué à 8.

        Ben, t'as reçu pour ta peine du code javascript de la taille d'un météore.

        De quoi tu te plains ?

        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

      • [^] # Re: Le javascript

        Posté par  . Évalué à 4.

        Ensuite pour avoir un truc optimisé tu va utiliser un truc comme gulp, grunt ou webpack qui vont prendre tes sources et les concaténer (avec plus ou moins d'optimisation) ou utilise les CDN pour tes dépendances, comme ça le navigateur ne les téléchargera pas.

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Le javascript

        Posté par  (site web personnel) . Évalué à 1.

        Si tu débutes dans le web, je pense que c'est vraiment une bonne idée de partir avec Meteor + React. Ca évite d'avoir à apprendre tout un tas de trucs et de les mettre dans 15 fichiers différents.
        Je t'encourage donc à aller plus loin et de tenter le tuto Meteor + React : https://www.meteor.com/tutorials/react/creating-an-app
        Après, au niveau du déploiement et des perfs, je ne sais pas si c'est un point fort de Meteor, mais, en tous les cas, je n'ai jamais constaté ni lu que c'était son point faible…

    • [^] # Re: Le javascript

      Posté par  (site web personnel) . Évalué à 7.

      Donc, tous les exemples Meteor-React sont en ES6, mais, pour apprendre React, les tuto du site React sont en ES5, même si l'équipe même de React conseille d'utiliser ES6.

      Facebook, qui développe React, a embauché le développeur de babel il y a quelques temps. Donc, ce n'est pas étonnant qu'ils poussent pour ES6 (babel fait de la transpilation ES6, 7 et + vers ES5).

      Sinon, on commence à voir la montée en puissance de TypeScript, et dans une moindre mesure de Flow. Ces 2 outils servent à ajouter du typage statique. Est-ce que c'est quelque chose que l'on voit aussi dans la communauté Meteor ?

      • [^] # Re: Le javascript

        Posté par  (site web personnel) . Évalué à 1.

        Je n'en ai pas entendu parler, mais en cherchant à répondre à ta question, il semblerait que ca soit dans les cartons : https://atmospherejs.com/meteortypescript/typescript-libs
        Pour React, je ne savais pas qu'ils avaient embauchée le jeune développeur de babel. C'est donc d'autant plus surprenant que le site React continue d'utiliser les createClass dans ses exemples.

      • [^] # Re: Le javascript

        Posté par  . Évalué à 7.

        C'est amusant, on veut ajouter de l'heritage, du typage fort, des classes. En fait, on veut transformer javascript en java…

        • [^] # Re: Le javascript

          Posté par  (site web personnel) . Évalué à 7.

          Contrairement à la légende, Java propose de vraies solutions, pas seulement des ProblemFactory.

          Beaucoup de concepts (modèle objet, typage statique, injection de dépendance) et outils (gestion de dépendance, chaîne de compilation) arrivés "récemment" ou prévus dans les écosystèmes javascript et PHP ces dernières années sont déjà mature dans le monde Java.

          Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

      • [^] # Re: Le javascript

        Posté par  . Évalué à 1.

        Meteor est assez mouvant en ce moment.
        Ils concentrent pas mal de ressources sur le projet Apollo (du graphql réactif) et ils sont partis sur du typescript. On devrait donc voir arriver pas mal de tooling autour de Meteor/typescript prochainement.
        Blog post sur Apollo et Typescript

        • [^] # Re: Le javascript

          Posté par  (site web personnel) . Évalué à 1.

          Je ne savais pas ! Merci pour l'info !
          En même temps, je trouve que c'est un peu le but de l'outil : packager le maximum de choses et faire des choix pour simplifier la vie de l'utilisateur final.
          Donc, donner le choix entre Blaze / React / Angular, je pense que ce n'est pas bon, il faut trancher et éventuellement laisser les autres solutions à la communauté.

  • # TCO

    Posté par  . Évalué à 4.

    la volonté de ne pas implémenter les Tail Calls Optimisation (car ils posent des problèmes).
    Est-ce que tu aurais des pointeurs sur la chose ?

    Merci pour ce journal sinon, évidemment !

    • [^] # Re: TCO

      Posté par  (site web personnel) . Évalué à 4.

      Oui, sur le blog de V8 : http://v8project.blogspot.fr/2016/04/es6-es7-and-beyond.html et les premiers commentaires sur Hacker News : https://news.ycombinator.com/item?id=11598245.

      • [^] # Re: TCO

        Posté par  . Évalué à 4.

        encore merci Michel !

        Pour ceux que ça intéresse, j'essaye de résumer :

        Dans ES6 :

        • aucune syntaxe spéciale n'est à rajouter par le développeur qui veut utiliser de la récursivité terminale. Corollaire : celui qui veut le faire ne peut pas savoir s'il le fait bien.
        • l'implémentation oblige à patcher la pile d'appel des fonctions, ce qui fait perdre de l'information de debuggage.

        Les gens derrière V8 poussent donc plutôt pour rajouter de la syntaxe signalant que le développeur souhaite une récursivité terminale.

        Personnellement, je ne suis pas convaincu par l'argument :-(

  • # npm3

    Posté par  . Évalué à 10.

    Npm3 est également de façon notoire bien plus lent que npm2.

    Ben ça fait rêver… (surtout quand on se souviens de ce qu'on disait sur maven il y a des années)

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # javascript ?

    Posté par  . Évalué à 10.

    J'ai un problème. Un gros problème.

    Les technos web m'ont toujours assez peu intéressé. Et donc je n'ai découvert javascript que très récemment. Et franchement ça m'a eu l'air d'un langage conçu par des crétins des Alpes.

    Mais voilà, je ne suis pas obtus, tout le monde l'utilise, on fait des framework avec, on le met côté serveur, donc, clairement, et même si ça m'escagasse de l'admettre, ça doit être moi le crétin des Alpes sur ce coup là. C'est d'autant plus probable que je n'ai pas de formation théorique me permettant de goûter le sel des langages exotiques.

    Donc, et c'est une vraie question je ne fais pas le malin, quelqu'un serait-il assez aimable pour me donner un pointeur vers une bonne ressource pour que je reformate mon rapport à javascript en réapprenant tout ?

    D'avance merci.

    La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".

    • [^] # Re: javascript ?

      Posté par  (site web personnel) . Évalué à 8.

      Je suis vraiment pareil que toi… J'ai pourtant quelques centaines de lignes de javascript au compteur, j'ai lu quelques livres (dont celui-ci : https://www.amazon.fr/Javascript-bons-%C3%A9l%C3%A9ments-Douglas-Crockford/dp/2744025828). Et bien non, lorsque je dois faire quelque chose, il me faut un exemple de syntaxe.
      Je n'ai pas du tout l'impression d'utiliser le même langage lorsque je fait du jQuery que lorsque je fais du Meteor ou que je faisais du AngularJS. Et maintenant il y a ES6 qui rebat toutes les cartes :) (Pour ES6, les articles qui m'ont le plus aidé, c'est ceux de ce site : http://putaindecode.io/)
      Donc, merci d'avoir posé la question, j'attends vraiment une réponse :)

    • [^] # Re: javascript ?

      Posté par  . Évalué à 4.

      Je n’ai pas de bon livre sur JavaScript à conseiller.

      En ligne, la ressource principale, la référence, qui est plutôt pas mal, c’est celle de Mozilla :
      https://developer.mozilla.org/fr/docs/Web/JavaScript
      Si tu veux manipuler le DOM, il faut aussi se référer à :
      https://developer.mozilla.org/fr/docs/Web/API/Document
      https://developer.mozilla.org/fr/docs/Web/API/Element

      Il y a pas mal d’autres pages utiles. Ce wiki, c’est un peu le bordel, mais on y trouve beaucoup de choses.

      L’an dernier, la communauté de Mozilla a traduit une série d’articles sur ES6 (la nouvelle, et indispensable, syntaxe) :
      https://tech.mozfr.org/tag/ES6%20en%20d%C3%A9tails
      (J’avais fait un PDF de ces articles pour mon propre usage, mais je ne sais pas si je peux le diffuser, attendu qu’il n’y a pas de licence mentionnée.)

    • [^] # Re: javascript ?

      Posté par  . Évalué à 3.

      Alors moi je suis comme toi, et tous les autres qui suivent. Alors, j'ai lu un peu (et je lis toujours), et puis j'ai commencé un truc que j'ai appéle : Very first Js starter kit. Ca me sert de bloc notes pour les trucs vraiment importants du langage comme l'orientation objets, les modules, etc. C'est volontairement orienté Node (donc côté serveur).

      Vient qui veut, et avec plaisir.

    • [^] # Re: javascript ?

      Posté par  . Évalué à 3.

      En vidéos il y a aussi GraphikArt qui explique pas mal de truc sur JavaScript, ses frameworks ainsi que les techno web :)

      Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

    • [^] # Re: javascript ?

      Posté par  . Évalué à 3.

      Cela semble correspondre à ce que tu recherches :

      https://github.com/getify/You-Dont-Know-JS

      • [^] # Re: javascript ?

        Posté par  . Évalué à 3.

        On peut aussi citer cette excellente ressource gratuite pour reprendre les bases:
        http://eloquentjavascript.net/
        avec les sources:
        https://github.com/marijnh/Eloquent-JavaScript

        et la version française (1ere edition):
        http://fr.eloquentjavascript.net/

        • [^] # Re: javascript ?

          Posté par  . Évalué à 2.

          Cette suggestion répond très bien à la demande initiale de fasthm :

          un pointeur vers une bonne ressource pour que je reformate mon rapport à javascript en réapprenant tout ?

          Le titre complet est : Eloquent JavaScript, a modern introduction to programming. Il est paru fin 2014.

          Tu peux le trouver sous forme imprimée, ou bien en ligne avec un chapitre en moins.

          C’est un livre vraiment bien écrit. Les explications reposent toutes sur des exemples. Il y a des exercices à la fin de chaque chapitre, avec des indications (et il y a aussi les solutions sur le site). Cinq projets sont complètement détaillés : un chapitre est dédié à chacun.

          Dans ce livre, c’est ES5 qui est utilisé. Ce n’est pas un problème. ES6 enrichit la syntaxe du langage de manière très conséquente ; il faut prendre le temps de s’y habituer et aussi de juger quelles sont les fonctionnalités et les constructions intéressantes. C’est le grand principe de Douglas Crockford : ce n’est pas parce qu’une fonctionnalité existe dans un langage qu’on est obligé de l’utiliser ; il vaut mieux se restreindre à un bon sous-ensemble.

          Concernant ES6, regarde dans un second temps :

          Pour finir, il y a un site qui recense les sources intéressantes pour apprendre JavaScript : http://jstherightway.org.

    • [^] # Re: javascript ?

      Posté par  . Évalué à 6.

      Pour réapprendre proprement le langage, j'étais tombé sur un tuto interactif avec uniquement des code à modifier: http://ejohn.org/apps/learn/

      Ça ne concerne ni NodeJs, ni les nouveautés apportées par ES6, mais c'est excellent pour comprendre les spécificités de Javascript, notamment le fonctionnement des closures, le comportement de this et l'orienté objet par prototype.
      Apparemment, ce serait une partie et/ou les exemples du livre Secrets of the JavaScript Ninja de John Resig, le créateur de jQuery.

      Je n'ai pas de lien global pour apprendre le js "moderne", mais pour donner quelques orientations:

      • La norme ECMAScript 6, aussi appelée ES6 ou ECMAScript 2015, est finalisée depuis juin 2015. Tout les navigateurs ne supportent pas encore toutes les nouveautés, loin de là, mais ça arrive vite, et il existe des outils pour pour utiliser ES6 en gardant la compatibilité avec tout le monde.
        Il y a de la doc très détaillée sur le site de doc de mozilla, et on peut avoir un aperçu avec exemple de code de chaque nouveauté sur cette page github.
        En résumé, beaucoup de nouvelles fonctions/méthodes dans la lib standard qui auraient dues être là depuis des années, pas mal de sucre syntaxique, et quelques fonctionnalités qui permettent de gérer beaucoup plus facilement le code asynchrone.
        Avec ca, je trouve que le langage ressemble de plus en plus à Python (mais ne le dites surtout pas à un dev Python, il le prendrait très mal ;) ).
        Je suis également le blog ②ality (en) qui propose des articles vraiment détaillés sur chaque point d'ES6 et explore tout les cas tordus. Une mine d'or.

      • Ensuite, on a NodeJs.
        C'est "juste" un interpréteur javascript, avec une lib pour communiquer avec l'OS (filesystem, réseau). En pratique, l'API de NodeJS est clairement orientée serveur, et repose beaucoup sur l'asynchrone. Sa doc est assez lisible pour trouver ce que l'on veut, et on monter un serveur HTTP ou faire un petit exécutable CLI en quelques lignes. Le cas d'utilisateur le plus courant de NodeJs, c'est un site web basé sur un framework web minimaliste tel que ExpressJS.
        C'est très, très simple de monter un site web et d'avoir un visuel en 5 minutes, mais on peut facilement s'y perdre si on ne maîtrise pas la notion de scope en Javascript.
        Le code asynchrone est énormément utilisé par NodeJs et son écosystème. Comme en js, il est très facile de créer des fonctions lambda, les callbacks sont énormément utilisées.
        Sauf que l'asynchrone apporte forcément une dose de complexité, et qu'il est très facile de s'y perdre et de produire du code dégueulasse (callback-hell). Face à ça, des conventions et des design patterns ont émergés. On trouve énormément d'articles sur le sujet en cherchant les notions d'error-first callback, de thunk et de Promise.

    • [^] # Re: javascript ?

      Posté par  . Évalué à 8.

      J'avais aussi un gros problème avec Javascript, jusqu'à ce que je découvre TypeScript !

      Je vais peut-être me faire lyncher, TypeScript est un langage développé par MS, c'est une surcouche de Javascript, avec l'introduction de fonctionnalités qui devraient être introduites dans ES6 ou ES7 ou suivants…

      Les apports les plus intéressants pour moi et qui font revenir le *Script dans mon cœur sont l'ajout de classes et du typage. Évidemment on n'est pas obligé d'utiliser des classes et de typer toutes les variables (la variable any étant un type passe-partout), mais si on s'y tient, on arrive à commencer à programmer proprement et clairement…

      Il faut savoir que TypeScript est devenu le langage officiel pour Angular2, et [mode lynchage]l'IDE largement utilisé pour éditer du TypeScript est VSCode, du même MS[/mode lynchage].

      Voici 3 speechs du dernier ng-conf qui pourraient te donner envie de t'y mettre :

      https://www.youtube.com/watch?v=WAPQF_GA7Qg
      https://www.youtube.com/watch?v=dzPjBWLdGz0
      https://www.youtube.com/watch?v=e3djIqAGqZo

      • [^] # Re: javascript ?

        Posté par  . Évalué à -9.

        Moi pendant ce temps je me demande pourquoi on parle d'angular sur un post au sujet de nodejs.

        Et par ailleurs, pourquoi utiliserais je typescript pour écrire du code avec nodejs, puisqu'en ayant choisi ce langage, et cette plateforme, c'était en connaissance de cause, en fait par désir, de virer la contrainte du typage.

        • [^] # Re: javascript ?

          Posté par  . Évalué à 4.

          Damn, je savais même pas qu'on pouvait être à -6 avant le moindre vote.

        • [^] # Re: javascript ?

          Posté par  . Évalué à 5.

          Et par ailleurs, pourquoi utiliserais je typescript pour écrire du code avec nodejs, puisqu'en ayant choisi ce langage, et cette plateforme, c'était en connaissance de cause, en fait par désir, de virer la contrainte du typage.

          Envie suicidaire, donc.

          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

          • [^] # Re: javascript ?

            Posté par  . Évalué à 4.

            Ben non, ils veulent gagner du temps lors de l'écriture du code.
            Ils virent également les tests unitaires et l'utilisation du CVS. Ça en économise de temps (lors de l'écriture initiale).
            J'oubliais : ils n'écrivent pas non plus les commentaires pour gagner encore un temps précieux.

            Plus sérieusement : quelles motivations pour se passer des « contraintes » de typage ? Pour moi c'est juste un truc indispensable.

            • [^] # Re: javascript ?

              Posté par  (site web personnel) . Évalué à 4.

              Plus sérieusement : quelles motivations pour se passer des « contraintes » de typage ? Pour moi c'est juste un truc indispensable.

              Avoir un système de types souples a plusieurs applications. Les trois plus importantes sont sûrement:

              • L'implémentation de fonctions polymorphes, qui peuvent travailler sur plusieurs types de données ou représentation. Cela permet de faire de la surcharge (style C++).

              • L'implémentation de fonctions extensibles, qui peuvent travailler sur un type de données lui-même extensible. (Les exemples que je connais sont pour le calcul algébrique.)

              • Une gestion plus souple des évolutions de protocole.

              Toutes ces techniques sont relativement avancées, dans le sens où elles ne sont pas faciles à exploiter de façon habile et utile (sans se tirer une balle dans le pied et en apportant un vrai service).

      • [^] # Re: javascript ?

        Posté par  (site web personnel, Mastodon) . Évalué à 2.

        Les apports les plus intéressants pour moi et qui font revenir le *Script dans mon cœur sont l'ajout de classes

        Ça tombe bien, dans les derniers Chrome, Firefox et Nodejs, tu peux utiliser les classes sans faire du typescript ;-)

  • # d'ailleurs

    Posté par  . Évalué à -3.

    La montée de version de V8 vers la version 5.0 a d'ailleurs permis une meilleure prise en charge d'ES6,

    Pourquoi "d'ailleurs" alors que c'est la version 6.0.0 qui était évoquée dans la phrase précédente ? Ce mot fait un peu tache, ou est mal utilisé à cet endroit.

    • [^] # Re: d'ailleurs

      Posté par  (site web personnel) . Évalué à 3.

      La version 6.0.0 est pour node.js. Node.js 5 utilisait le moteur V8 en version 4.6 et Node.js 6.0.0 est passé à V8 en version 5.0, ce qui a permis une meilleure prise en charge d'ES6.

  • # Stack traces...

    Posté par  (site web personnel) . Évalué à 5. Dernière modification le 13 mai 2016 à 11:40.

    Bon, par contre, pour les stack traces, il y a encore des progrès à faire. J'ai rencontré un bug sur cozy-desktop, le futur logiciel de synchronisation entre son ordinateur personnel et son cloud personnel. Et je peux vous dire qu'avoir une stack trace qui ne fait référence à aucun fichier du projet, ça n'aide pas à débugger.

    Pour reproduire, il suffit de prendre ce bout de code simplifié :

    // err.js
const async  = require('async')
const fs     = require('fs')
const stream = require('stream')

let source

async.waterfall([
  (next) => {
    const stream = fs.createReadStream('.npmignore')
    next(null, stream)
  },
  (stream, next) => {
    source = stream
    source.on('error', (err) => {
      console.log('Error on source', err)
    })
    const target = fs.createWriteStream('.npmignore.old')
    next(null, target)
  },
  (target, next) => {
    target.on('error', (err) => {
      console.log('Error on target', err)
    })
    source.pipe(target)
    target.on('finish', next)
  }
], (err) => {
  console.log('Done', err)
})

    et de le lancer :

    $ node -v
v6.1.0
$ npm init
$ npm install async
$ node err.js
Error on source { Error: ENOENT: no such file or directory, open '.npmignore'
    at Error (native) errno: -2, code: 'ENOENT', syscall: 'open', path: '.npmignore' }

    Alors, ici, le code paraît bizarre parce que j'ai essayé de reproduire l'exemple de cozy-desktop en le simplifiant beaucoup. Dans cozy-desktop, quand on ajoute un fichier en local qui vient du serveur cozy, on fait d'autres étapes comme s'assurer que le répertoire dans lequel on va écrire le fichier existe. La création du stream source est également plus compliqué : si on a déjà une copie du fichier en local, on va utiliser cette copie, sinon on va passer par le réseau pour récupérer le fichier depuis le serveur. Etc.

    • [^] # Re: Stack traces...

      Posté par  . Évalué à -6. Dernière modification le 13 mai 2016 à 10:41. 

        console.error(err.stack)

      https://nodejs.org/api/errors.html
      http://stackoverflow.com/questions/2923858/how-to-print-a-stack-trace-in-node-js

      amha fs.createWriteStream('.npmignore.old').on('close') et non fs.createWriteStream('.npmignore.old').on('finish')

      • [^] # Re: Stack traces...

        Posté par  . Évalué à -6.

        Par ailleurs,

        La création du stream source est également plus compliqué : si on a déjà une copie du fichier en local, on va utiliser cette copie, sinon on va passer par le réseau pour récupérer le fichier depuis le serveur. Etc.

        Pourquoi tu n'enrobes pas cette logique dans un readable ? Comme cela que le fichier existe, ou pas, tu pourrais faire tonStream('lefichier').pipe(…)

        Tu pourrais réduire un peu toute cette complexité avec le async.

        cf noms, ou mississippi, pour faire un readable rapidement.

        • [^] # Re: Stack traces...

          Posté par  (site web personnel) . Évalué à 3.

          Pourquoi tu n'enrobes pas cette logique dans un readable ?

          Tu parles des readable streams ? C'est déjà le cas dans l'exemple ci-dessus (fs.createReadableStream crée bien un readable stream) et dans cozy-desktop. C'est juste que pour cozy-desktop, il y a plus d'étapes dans le async.waterfall et l'étape pour créer le readable stream comporte un if pour choisir si on le crée depuis un fichier local ou une URL distante.

          Tu pourrais réduire un peu toute cette complexité avec le async.

          C'est-à-dire ? J'ai utilisé le module async dans l'exemple. Ou tu parles de async/await ? Async/await n'est pas supporté pas node 6.

          • [^] # Re: Stack traces...

            Posté par  . Évalué à -6.

            async/await ? Très peu pour moi ! Oui je parlais du module async.

            si on a déjà une copie du fichier en local, on va utiliser cette copie, sinon on va passer par le réseau pour récupérer le fichier depuis le serveur.

            En fait ce sera plus simple avec un through.

            function streamDuFichierParIciOuLaBas(string) {
  var stream = miss.through();
  stream.pause();
  // fais des trucs async ici pour trouver le fichier
  // a un moment dans un callback
  fn cb (){
    srcStream.pipe(stream).resume();
  }
  // ou srcStream sera fs.readdable ou net.socket j'imagine.
  return stream;
}
streamDuFichierParIciOuLaBas(string).pipe(streamDst);

            Par contre, comme c'est un through et non un readable tu perds l'évènement close, tu n'auras plus que le 'end'

      • [^] # Re: Stack traces...

        Posté par  (site web personnel) . Évalué à 3.

        Je peux utiliser :

        process.on('uncaughtException', (err) => {
  console.log(err.stack);
});

        mais ça ne change rien, ça affiche toujours :

        Error on source { Error: ENOENT: no such file or directory, open '.npmignore'
    at Error (native) errno: -2, code: 'ENOENT', syscall: 'open', path: '.npmignore' }

        Pour le on('close') vs on('finish'), les deux donnent le même résultat ici. Ils ont une légère différence de signification, mais ce n'est pas important ici. Pour cozy-desktop, la sémantique de finish me convenait mieux.

        • [^] # Re: Stack traces...

          Posté par  . Évalué à -5.

          Ton exception n'est pas 'uncaught' puisque tu as abonné l'évènement 'error' du stream dans

              source.on('error', (err) => {
      console.log('Error on source', err)
    })

          C'est plutôt

              source.on('error', (err) => {
      console.log('Error on source', err.stack)
    })

          Et quand t'en auras marre d'écrire trois lignes pour binder error, tu feras comme moi https://github.com/mh-cbon/cpkaaot/blob/master/lib/error-debug.js

          Pour le on('close') vs on('finish'), les deux donnent le même résultat ici. Ils ont une légère différence de signification, mais ce n'est pas important ici. Pour cozy-desktop, la sémantique de finish me convenait mieux.

          J'avoue appliquer la chose bêtement. Si je veux savoir quand le fichier est écrit => close

          • [^] # Re: Stack traces...

            Posté par  (site web personnel) . Évalué à 4.

            Oui, c'est dans le source.on('error') qu'il faut afficher err.stack, mais ça me donne juste :

            Error: ENOENT: no such file or directory, open '.npmignore'
    at Error (native)

            La stack trace de node 6 est juste pourrie.

            • [^] # Re: Stack traces...

              Posté par  . Évalué à -5.

              oui c'est dégueulasse.

              nvm ls
       v0.12.13
         v4.0.0
         v5.0.0
         v5.7.1
->       v6.0.0
         v6.1.0
         system
default -> 5.0 (-> v5.0.0)
node -> stable (-> v6.1.0) (default)
stable -> 6.1 (-> v6.1.0) (default)
iojs -> N/A (default)
[mh-cbon@pc15-home nsi-pl] $ nvm use 5.7.1
Now using node v5.7.1 (npm v3.6.0)
[mh-cbon@pc15-home nsi-pl] $ node err.js
Error: ENOENT: no such file or directory, open '.npmignore'
    at Error (native)
[mh-cbon@pc15-home nsi-pl] $ nvm use 4.0.0
Now using node v4.0.0 (npm v2.14.2)
[mh-cbon@pc15-home nsi-pl] $ node err.js
Error: ENOENT: no such file or directory, open '.npmignore'
    at Error (native)
[mh-cbon@pc15-home nsi-pl] $ node err.js
Error: ENOENT: no such file or directory, open '.npmignore'
    at Error (native)
{ [Error: ENOENT: no such file or directory, open '.npmignore'] errno: -2, code: 'ENOENT', syscall: 'open', path: '.npmignore' }
[mh-cbon@pc15-home nsi-pl] $ node err.js
Error: ENOENT: no such file or directory, open '.npmignore'
    at Error (native)
{ [Error: ENOENT: no such file or directory, open '.npmignore'] errno: -2, code: 'ENOENT', syscall: 'open', path: '.npmignore' }
/home/mh-cbon/projects/nsi-pl/err.js:10
    throw err
    ^

Error: ENOENT: no such file or directory, open '.npmignore'
    at Error (native)
[mh-cbon@pc15-home nsi-pl] $ 


              var async  = require('async')
var fs     = require('fs')
var stream = require('stream')

var source

  var stream = fs.createReadStream('.npmignore').on('error', function (err) {
    console.log(err.stack)
    console.log(err)
    throw err
  })

              • [^] # Re: Stack traces...

                Posté par  . Évalué à -6.

                A défaut, mais c'est moche en effet.

                console.log(new Error().stack)

          • [^] # Re: Stack traces...

            Posté par  (site web personnel) . Évalué à 4.

            Pour préciser, j'avais parlé d'exception 'uncaught', car c'est ce qui arrive avec async@1.5.2. Là, avec async@2.0.0-rc4, le comportement a changé et on passe dans le on('error'). Oui, node.js est vraiment un endroit très piégé !

            • [^] # Re: Stack traces...

              Posté par  . Évalué à -6.

              Oui, node.js est vraiment un endroit très piégé !

              Je confirmes. Même si j'aurais plutôt dit qu'avec de grands pouvoirs viennent de grandes responsabilitées !

              Ceci dit avec async j'ai l'habitude d'avoir un callback de fin pour rattraper l'exception. Ceci dit je n'utilise pas waterfall.

              async.series([], fn(err){});

              Plus simplement si je dois binder uncaughtException, c'est que le code est mauvais.

              • [^] # Re: Stack traces...

                Posté par  (site web personnel) . Évalué à 4.

                Même si j'aurais plutôt dit qu'avec de grands pouvoirs viennent de grandes responsabilitées !

                Je n'ai vraiment pas l'impression d'avoir de grands pouvoirs avec Node.js, en tout cas, beaucoup moins que dans d'autres langages comme Ruby ou Elixir.

                Ceci dit avec async j'ai l'habitude d'avoir un callback de fin pour rattraper l'exception.

                Il y a un callback de fin dans mon exemple. Mais le callback de fin d'async n'attrape pas les exceptions, juste les erreurs passés en premier paramètre d'un callback. Et avec les streams, ça se combine très mal.

                • [^] # Re: Stack traces...

                  Posté par  . Évalué à -5.

                  et bien, pourquoi ne fais tu pas du ruby ou de l'elixir alors ? Le but c'est de rendre un service, pas de s'obstiner à utiliser une techno, non ?

                  Et avec les streams, ça se combine très mal.

                  Oui tu devrais essayer comme je t'ai montré ici http://linuxfr.org/nodes/108933/comments/1656878

                  • [^] # Re: Stack traces...

                    Posté par  (site web personnel) . Évalué à 4.

                    et bien, pourquoi ne fais tu pas du ruby ou de l'elixir alors ?

                    Parce que ce n'est pas moi qui ait choisi ;-)

                    Il y a plusieurs raisons en fait :

                    • Je travaille en équipe et je ne peux pas choisir ça tout seul dans mon coin. D'autres personnes vont intervenir et elles ne connaissent pas Ruby et encore moins Elixir.

                    • Le projet était déjà commencé quand je suis arrivé et je l'ai repris. C'est compliqué de changer de langage en cours de route.

                    • Le développement de Cozy-desktop est pas mal aidé par une bibliothèque, PouchDB. Ce n'est pas facile de lui trouver un équivalent en Ruby.

                    Oui tu devrais essayer comme je t'ai montré ici http://linuxfr.org/nodes/108933/comments/1656878

                    Je regarde mais ça n'a pas l'air de trop m'aider pour la gestion des erreurs. Je me retrouve toujours avec du code spaghetti.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.