Sortie de Node.js 0.4.0

Posté par (page perso) . Modéré par patrick_g.
16
12
fév.
2011
JavaScript
Node.js est un environnement JavaScript côté serveur, sous licence MIT. Sa particularité est son approche asynchrone pour faciliter la montée en puissance dans des contextes avec beaucoup d'entrées-sorties, notamment réseau. En pratique, il se compose :
  • d'un interpréteur JavaScript, à savoir V8 ;
  • de require(), un chargeur de modules compatible CommonJS ;
  • d'une bibliothèque standard, volontairement restreinte (une sorte de libc JavaScript où tous les appels sont asynchrones) ;
  • d'un ensemble de conventions : par exemple, les fonctions de retours indiquent toujours en premier paramètre si l'appel s'est bien passé et dans le cas contraire, quelle a été l'erreur ;
  • et d'un exécutable, node pour lancer tout ça.

La version 0.4.0 sortie cette semaine est la deuxième stable (c'est comme pour l'ancien mode de développement du noyau Linux : le numéro mineur est pair pour les versions stables et impair pour les versions de développement). Les principaux changements depuis la version stable précédente (la version 0.2, pour ceux qui suivent) sont les suivants :
  • nouveau client HTTP, avec une API plus simple et la gestion d'un réserve (pool) de connexions ;
  • refonte du module TLS/SSL ;
  • augmentation des performances, grâce à l'allocation plus rapide des tampons mémoire (Buffer) ;
  • meilleure prise en charge des gestionnaires de paquets comme npm, grâce à l'amélioration de require() ;
  • une mise à jour de V8 pour la version 3.1.2 ;
  • un débogueur fonctionnel, mais encore très limité pour le moment ;
  • un module os qui expose des informations sur le système ;
  • et, bien sûr, plein de corrections de bogues.
Pour mieux comprendre le fonctionnement de Node.js, je vous propose un petit exemple :

var dns = require('dns');
dns.resolve4('www.google.com', function (err, addresses) {
    if (err) {
        console.log(err);
    } else {
        console.log('addresses: ' + JSON.stringify(addresses));
    }
});
console.log("Nous allons resoudre www.google.com :");


À la première ligne, nous chargeons le module dns. C'est un objet avec des méthodes associées, comme resolve4, et nous l'enregistrons dans la variable dns.

Ensuite, nous faisons appel à cet objet pour résoudre « www.google.com ». Nous passons deux paramètres à resolve4 : le premier est la chaîne de caractères "www.google.com" et le second est la fonction de rappel (le callback). De cette façon, nous disons à Node que nous souhaitons qu'il s'occupe de la résolution DNS de « www.google.com », et quand il l'aura faite (ou en cas d'erreur), il devra appeler la fonction qu'on lui a passée.

Et là, Node va s'empresser de... ne rien faire et nous rendre la main. Nous exécutons donc la ligne suivante, qui affiche juste le message « Nous allons résoudre www.google.com : » sur la sortie standard.

Nous arrivons alors à la fin du script et nous n'avons donc plus aucune instruction à exécuter. Node.js peut alors reprendre la main et faire tous les traitements. Ici, il va s'occuper de lancer la requête DNS. Puis, il va écouter sa boucle événementielle. Au bout d'un moment, la réponse à notre requête va arriver et alors Node va appeler la fonction que l'on avait associée à cet événement. Si l'appel s'est bien passé, err vaudra null et addresses contiendra un tableau des adresses IP retournées. On affichera alors ce tableau, après l'avoir transformé en une chaîne de caractères joliment formatée par JSON.stringify.
  • # Merci

    Posté par . Évalué à 8.

    Merci bien pour cette dépêche de qualité sur node.js.

    Un petit lien supplémentaire pour mieux comprendre : http://howtonode.org/
  • # NPM?

    Posté par . Évalué à 3.

    meilleure prise en charge des gestionnaires de paquets comme npm, grâce à l'amélioration de require() ;
    Si comme moi vous avez tiqué sur cette phrase (NPM? ils ont surement voulu écrire RPM?), et bien sachez que NPM est le Node Packqge Manager, un gestionnaire de paquet spécialisé pour Node: [http://npmjs.org/].

    J'imagine que c'est un peu comme CPAN, PEAR, easy_install, rubygems, etc. (selon votre religion ;) )
  • # Javascript powa

    Posté par . Évalué à 2.

    Déjà le Javascript sur le client ça me saoule alors côté serveur, je ne veux même pas y penser, vous me direz côté serveur, ce sera peut-être moins le bordel que sur le client.
    • [^] # Re: Javascript powa

      Posté par (page perso) . Évalué à 4.

      Côté serveur, on maîtrise mieux l’environnement d’exécution, on sait qu’on utilise que le moteur v8, et non pas ceux des différents navigateurs quand on est côté client.

      Par ailleurs, le « bordel » dont tu parles est plus lié aux difficultés d’intégration qu’au langage lui-même.

      Donc je trouve qu’au contraire, c’est bien plus intéressant d’utiliser JS côté serveur :)

      En plus ça manque un peu d’argumentation ton propos :)
      • [^] # Re: Javascript powa

        Posté par (page perso) . Évalué à 3.

        JS côté client a un gros intérêt: il est très généralement disponible -dans toute sa diversité- et il n'y a pas à l'installer.

        Côté serveur, il faut installer un moteur de son choix - ça permet de choisir celui que l'on considère comme le plus adapté / mature / performant et de choisir les versions des librairies que l'on veur utiliser, etc. Mais, quitte à installer des outils côté serveur, alors pourquoi du JavaScript ?

        Pour certains développeurs qui sont habitués au côté client, il y a une expérience certaine sur le langage JavaScript ; mais pour les autres, il existe des tas d'outils dans de nombreux langages. Si on retire le fait d'avoir le même langage sur client et serveur, les arguments pour JavaScript ne sont pas évidents. Bref, ça serait plutôt aux tenants du JavaScript côté serveur d'indiquer les avantages que cela apporte vs les autres langages avec leurs outils.

        Bon, ça risque de tourner en troll... pour/contre truc/machin et guerre de chapelle à la emacs/vim.
        • [^] # Re: Javascript powa

          Posté par (page perso) . Évalué à 0.

          pourquoi du JavaScript

          Comme dit dans la dépêche, sa particularité est son approche asynchrone (native, et non ajoutée par la suite via, par exemple Twisted pour Python ou EventMachine pour Ruby). La syntaxe est faite pour ça et tout est fait dans une optique d'asynchronisme. Du coup, ça va plus vite et ça accepte plus de connexions simultanées.

          Déjà le Javascript sur le client ça me saoule alors côté serveur, je ne veux même pas y penser, vous me direz côté serveur, ce sera peut-être moins le bordel que sur le client.

          Côté serveur, il n'y a pas de DOM, ce qui supprime déjà une bonne partie des problèmes.

Suivre le flux des commentaires

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