- 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.
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.
Aller plus loin
- Site officiel de Node.js (122 clics)
- Annonce de la version v0.4 de Node.js (17 clics)
- DLFP : Sortie de Node.js v0.2.0 (44 clics)
- npm, le gestionnaire de paquets (18 clics)
- Testez votre code Node.js avec Vows (86 clics)
# Merci
Posté par freeflight00 . Évalué à 8.
Un petit lien supplémentaire pour mieux comprendre : http://howtonode.org/
[^] # Re: Merci
Posté par Frederic Cambus (site web personnel) . Évalué à 3.
# NPM?
Posté par djano . Évalué à 3.
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 highleaf . Évalué à 2.
[^] # Re: Javascript powa
Posté par Michel Petit (site web personnel) . Évalué à 4.
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 lolop (site web personnel) . Évalué à 3.
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.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Javascript powa
Posté par Pandark (site web personnel) . Évalué à 0.
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.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.