Pour bien comprendre ce qu'est Node.js, je vous propose le cheminement suivant. Partons de V8, la machine virtuelle développée par Google qui permet d'interpréter du javascript. Ajoutons un modèle événementiel, similaire à EventMachine en Ruby ou à Twisted en Python. Cela tombe bien, en javascript, c'est assez naturel de procéder de cette manière : le javascript dans les navigateurs utilise déjà un modèle événementiel (les événements sont 'DOM chargé', 'touche pressée' ou encore 'clic de la souris'). C'est un bon début, mais le javascript ne possède pas de bibliothèque standard pour manipuler des fichiers ou faire des opérations réseau. Utilisons donc notre modèle événementiel pour ajouter des API qui permettent de faire ça de manière asynchrone. Une autre lacune de javascript est l'absence de moyen de charger une bibliothèque depuis un script, et comme on n'a pas spécialement envie de tout écrire dans un seul fichier, rajoutons donc une fonction require pour charger un autre script. Enfin, saupoudrons le tout avec quelques API utilitaires, un interpréteur interactif, et vous obtiendrez une bonne idée de la composition de Node.js.
Node.js permet ainsi de développer simplement des applications en javascript que l'on peut qualifier de server-side. Voici quelques exemples de ce que l'on peut faire avec Node.js :
- Node.js ircd, un serveur IRC ;
- How To Node, un blog parlant de Node.js ;
- Vows, un framework BDD ;
- Express, un framework web qui utilise les middlewares Connect.
La version 0.2.0 est sortie le 20 août et marque une première stabilisation du projet. Jusqu'à maintenant, les versions s'enchaînaient à un rythme soutenu (2 à 3 par mois), avec souvent des changements d'API et des problèmes de compatibilité divers et variés. Il est donc difficile pour les développeurs de bibliothèques de les maintenir, et pour les développeurs d'applications, de trouver les bonnes bibliothèques qui fonctionne avec la dernière version de Node.js. Cela devrait maintenant changer : Ryan Dahl a promis d'assurer la compatibilité de l'API pour les versions 0.2.x. Si vous souhaitez essayer Node.js, c'est donc le bon moment pour vous lancer ! Pour montrer la simplicité de Node.js, nous allons voir comment écrire un Hello World sous forme de serveur web.
Commençons par installer Node.js. Cela se fait simplement sur tous les UNIX (Linux, BSD, OSX...) mais nécessite de passer par Cygwin pour windows. Vous aurez besoin des outils classiques de compilation, ainsi que d'OpenSSL. Après avoir téléchargé et décompressé les sources de Node.js, il ne vous reste plus à qu'à taper la classique ligne de commande suivante :
./configure && make && make install
Nous pouvons maintenant écrire le code de notre Hello World. C'est du javascript, nous allons donc le placer dans un fichier hello.js. Voici le code en question :
var http = require('http');
http.createServer(function (req, res) {
res.writeHead(200, {'Content-Type': 'text/plain'});
res.end('Hello World\n');
}).listen(8000, "127.0.0.1");
console.log('Server running at http://127.0.0.1:8000/');
La première ligne charge le module http et le rend accessible grâce à la variable du même nom. Node.js respecte la spécification Modules de CommonJS. Ainsi, un module peut exposer un objet en l'assignant à la variable exports, et cet objet sera renvoyé par require.
À la seconde ligne, nous pouvons maintenant utiliser notre objet http pour créer un serveur. Pour cela, nous utilisons la méthode createServer, en lui passant en paramètre une fonction anonyme. Cette fonction sera appelée à chaque fois qu'un client se connectera au serveur. 2 paramètres seront passés à la requête : req, qui représente la requête du client, et res, qui va servir à construire la réponse au client.
Ici, la fonction pour répondre à un client est très simple. Nous commençons par renvoyer le code HTTP 200 - OK, avec un entête pour préciser que la réponse sera du texte brut (ligne 3). Puis, nous envoyons la réponse elle-même, à savoir le Hello World (ligne 4). Comme nous avons utilisé la méthode end plutôt que write, Node.js sait que la réponse est complète. Il pourra donc fermer la connexion HTTP quand toutes les données auront été envoyées.
À la ligne 5, nous indiquons à Node.js que notre serveur va écouter sur le port 8000 en local (127.0.0.1 est l'adresse IP locale). Enfin, à la dernière ligne, nous affichons un message sur la sortie standard pour indiquer que notre serveur tourne bien.
Nous pouvons maintenant lancer notre script :
node hello.js
Node.js va exécuter notre script. Il va arriver très vite à la fin du script, et là, contrairement à ce que l'on pourrait penser, il ne va pas quitter. À la place, il va entrer dans un mode où il va attendre des événements (avec epoll, kqueue ou select), et quand un de ces événements se produit, il exécute la fonction associée. Dans notre cas, les événements seront des clients qui se connecteront à notre serveur.
Nous pouvons maintenant taper http://127.0.0.1:8000/ dans la barre d'adresse de notre navigateur et voir notre Hello World s'afficher.
Normalement, node.js finit de s'exécuter quand il n'a plus d'événements à écouter. Dans notre cas, cela ne se produira jamais car nous ne fermons notre serveur nulle part. Pour quitter, nous allons donc devoir y aller de manière un peu brutale avec un CTRL-C.
Aller plus loin
- Node.js, le site officiel (20 clics)
- Annonce de la sortie de la version 0.2.0 (8 clics)
- Le code de Node.js sur github (9 clics)
- La liste des modules pour Node.js (13 clics)
- La documentation de l'API (7 clics)
- Node.js v0.2.0 sur le devblog af83 (38 clics)
# HTML 5 et P2P
Posté par kalki . Évalué à 2.
[^] # Re: HTML 5 et P2P
Posté par davandg . Évalué à 2.
Un autre problème : comment initialisé la connexion ?
[^] # Re: HTML 5 et P2P
Posté par webdev . Évalué à 2.
[^] # Re: HTML 5 et P2P
Posté par kalki . Évalué à 1.
http://fr.wikipedia.org/wiki/HTTP%28P2P%29
# V8
Posté par barmic . Évalué à 4.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: V8
Posté par mister popo ポポ (site web personnel) . Évalué à 0.
[^] # Re: V8
Posté par yellowiscool . Évalué à 2.
Envoyé depuis mon lapin.
[^] # Re: V8
Posté par mister popo ポポ (site web personnel) . Évalué à 1.
[^] # Re: V8
Posté par barmic . Évalué à 4.
Après je connais très mal le sujet.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: V8
Posté par mister popo ポポ (site web personnel) . Évalué à 5.
Dans tous les cas, la vrai différence entre les navigateurs webs, ce n'est pas la couche basse de javascript, mais le DOM et les APIs qui vont dessus. Perso, je fait du nodejs avec la doc mozilla, et je n'ai pas encore eut de soucis.
Il existe des projets node qui tournent aussi dans un browser, mais bon, le but d'un code fait pour node est de tourner avec node.
# scalabilité
Posté par Artefact2 (site web personnel) . Évalué à 3.
[^] # Re: scalabilité
Posté par Jean B . Évalué à 6.
[^] # Re: scalabilité
Posté par Sylvain Sauvage . Évalué à 3.
Motif de conception marche aussi.
[^] # Re: scalabilité
Posté par psychoslave__ (site web personnel) . Évalué à 3.
Ainsi Node.js a pour but d'offrir un moyen simple d'écrire des applications réseau gérant la mise à l'échelle.
[^] # Re: scalabilité
Posté par reno . Évalué à 2.
Pour aller au grenier?
Bon, plus sérieusement, c'est compliqué de traduire le concept de scalabilité, ce serait quelque-chose comme:
"ne pas empecher de supporter un grand nombre d'utilisateur|de connections|de transactions."
Autant utiliser le terme Franglais, c'est plus concis!
[^] # Re: scalabilité
Posté par gilgam . Évalué à 1.
Pour aller au grenier?
Bon, plus sérieusement, c'est compliqué de traduire le concept de scalabilité, ce serait quelque-chose comme:
"ne pas empecher de supporter un grand nombre d'utilisateur|de connections|de transactions."
>>>>>>
"possibilité de montée en puissance" ?
[^] # Re: scalabilité
Posté par Moonz . Évalué à 3.
[^] # Re: scalabilité
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
[^] # Re: scalabilité
Posté par psychoslave__ (site web personnel) . Évalué à 3.
[^] # Re: scalabilité
Posté par mister popo ポポ (site web personnel) . Évalué à 2.
Pour arriver à gérer tout ça sans s'emmêler les pinceaux, il y a les callbacks : les fonctions anonymes que javascript aime tant, et les events. On se retrouve à faire de la programmation fonctionnelle, avec des fonctions en cascade, et non plus de la programmation linéaire.
[^] # Re: scalabilité
Posté par auve . Évalué à 4.
Saint Plex, priez pour nous !
# Lacune??
Posté par suJeSelS . Évalué à 2.
[...]
Une autre lacune de javascript est l'absence de moyen de charger une bibliothèque depuis un script
Javascript est très majoritairement utilisé du côté client, heureusement que ces fonctionnalités n'existent pas d'origine.
[^] # Re: Lacune??
Posté par Sylvain Sauvage . Évalué à 1.
# typeof NaN
Posté par rhizome . Évalué à 1.
- - - - - > [ ]
[^] # Re: typeof NaN
Posté par pini . Évalué à 3.
[^] # Re: typeof NaN
Posté par Gniarf . Évalué à 3.
[^] # Re: typeof NaN
Posté par Guillaume Denry (site web personnel) . Évalué à 10.
Puis au bout d'un moment, on commence à se rendre compte de la puissance de certains concepts, on se surprend à prendre plaisir à utiliser les closures à tire larigot, à ne plus typer ses variables, à manipuler des fonctions comme n'importe quel autre objet littéral, à construire des paradigmes (comme de la POO) comme quand on jouait aux légos, à apprécier le JSON, la sérialisation "naturelle", le passage de paramètres par table de hachage, et surtout la grande expressivité que permet ce langage.
Alors bien sûr, ces quelques concepts se retrouvent tous dans des langages réputés plus puissants et "propres" (comme Haskell, Python, Lisp, etc), mais c'est juste pour dire que javascript, c'est franchement pas si pourri que cela.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.