Faisons le point sur ce qu’est Node pour mieux comprendre les discussions qui animent la communauté et d’où vient cette plate-forme qui fait tant parler d’elle.
•Bref historique
•Les raisons du succès
•Pourquoi éviter Node
•Pourquoi choisir Node
•L’écosystème des acteurs
•Gouvernance du projet
Node.js est-il un langage de programmation ? Node.js est-il un framework JavaScript ? Qu’en restera-t-il une fois la frénésie retombée ? Ce chapitre permet de comprendre pourquoi Node a émergé et comment. Surtout, il vous permettra de comprendre les choix techniques à l’origine des fondations de Node et ce que l’utiliser peut vous apporter, que ce soit dans un contexte personnel ou professionnel.
Node.js n’est pas un langage de programmation. Ce n’est pas non plus un framework JavaScript. Node.js est un environnement d’exécution JavaScript.
La différence entre ces trois désignations peut sembler subtile, futile voire inutile, mais le terme « environnement » est la véritable nature de Node.
Exécuter du JavaScript côté serveur n’est pas une révolution. Netscape Enterprise Server s’y est déjà essayé au début des années 1990, juste après son introduction dans le navigateur web Netscape Navigator.
En 1997, la société Netscape s’est attelée à créer Rhino (https://www.mozilla.org/rhino/), un environnement d’exécution JavaScript tournant sous Java et disponible sous licence libre. C’était un des projets liés à la réécriture de Netscape Navigator en Java. Si la société a depuis fermé ses portes, Rhino a entraîné l’émergence de projets utiles aux développeurs web.
Entre-temps, le langage JavaScript évolue, le Web 2.0 émerge des cendres de la première bulle Internet et d’autres initiatives voient le jour dans les années 2000 comme APE (Ajax Push Engine, http://ape-project.org/). Elles mettent également en œuvre JavaScript côté serveur. JavaScript était surtout un choix logique de partage de code entre client et serveur pour Comet, le précurseur des WebSockets.
GLOSSAIRE Comet
Comet est un terme regroupant les différentes tentatives techniques permettant à un serveur web d’envoyer des données à un client sans que celui-ci ne les ait demandées initialement.
Parmi ces techniques, on retrouve le long polling, consistant à conserver une connexion Ajax ouverte pendant la durée de vie d’une page web.
GLOSSAIRE WebSockets
WebSockets est un protocole basé sur TCP.
Il maintient une connexion HTTP active entre un client et un serveur et y fait transiter les données de manière bidirectionnelle.
Ce protocole sera probablement rendu obsolète par HTTP/2, le successeur de HTTP/1.1. HTTP/2 a été lancé par Google sous le nom de protocole SPDY (prononcer speedy).
Cas d’utilisation modernes de Rhino
Rhino est toujours utile dès qu’un projet Java implique du JavaScript.
Google l’utilise comme environnement d’exécution de ses https://gsuite-developers.googleblog.com/2012/11/using-open-source-libraries-in-apps.html. Ces scripts sont destinés à développer des extensions et des interactions supplémentaires pour les documents Google Drive.
Rhino est également employé dans YUI Compressor (https://yui.github.io/yuicompressor/), un optimiseur CSS et JavaScript créé par Yahoo, désormais surpassé par Closure Compiler (https://developers.google.com/closure/compiler/) et UglifyJS (https://npmjs.com/uglify-js). Ce dernier est écrit en JavaScript et repose sur Node. La boucle est bouclée.
Node représente un environnement d’exécution (runtime), un ensemble d’API JavaScript ainsi qu’une machine virtuelle (VM) JavaScript performante (parseur, interpréteur et compilateur) capable d’accéder à des ressources système telles que des fichiers (filesystem) ou des connexions réseau (sockets).
Typiquement, une personne développant en Node écrit du code se basant sur les API à disposition. Ce code est lu par le runtime Node, qui le transmet à la VM JavaScript. Enfin, cette dernière traduit le programme en langage machine (bytecode) avant que le programme soit effectivement exécuté par le processeur.
Pour comprendre comment Node a opté pour cette approche, retournons en 2009, lorsque son créateur Ryan Dahl cherche à résoudre élégamment un problème de performance de programmation.
En 2006, Ryan Dahl est un étudiant américain en troisième année de doctorat de mathématiques. Son but initial était de devenir professeur dans cette matière, mais il prend la décision de ne pas terminer sa thèse et d’entreprendre un voyage au Chili.
Alors qu’il cherche à effectuer des petits boulots, il y rencontre une autre personne développant des sites web. Ruby on Rails connaît un succès grandissant et attire son attention. Alors que Ryan envisage d’utiliser Rails, il découvre avec horreur la lenteur du framework et cherche à en découvrir les causes.
Ryan débute alors sa quête des applications web performantes et découvre Mongrel, un serveur HTTP écrit en Ruby. Il est séduit par deux choses :
•la possibilité d’inclure un serveur HTTP comme bibliothèque applicative ;
•la simplicité de fonctionnement : recevoir une requête HTTP et décider soi-même de la réponse à apporter.
La quête initiale le dirige alors vers la possibilité de créer un serveur web non bloquant ; en d’autres termes, un serveur capable, dans un même processus, de traiter d’autres requêtes en attendant de renvoyer la réponse initiale.
Nous sommes alors en 2008 et le site de partage de photos Flickr innove avec un nouveau système de téléversement d’images : une barre de progression représentant le statut du téléversement remplace alors la page figée – effet inhérent à l’envoi de fichiers depuis un formulaire HTML.
C’est le déclic pour Ryan : bien que Mongrel ait déjà un plug-in pour cette fonctionnalité, il souhaite simplifier davantage le travail pour les développeurs. Il reproduit le mécanisme avec succès en C. Les développeurs web jugeant la solution trop complexe, Ryan tente la même approche avec d’autres langages, comme Python, Lua ou même Haskell. Il se heurte au sempiternel problème des ressources bloquantes des différents interpréteurs.
Figure 1–1 Interface du service Flickr après et avant l’introduction du téléversement progressif
LIEN Annonce du nouveau Flickr Uploadr
L’équipe d’ingénierie de Flickr explique dans un article (https:/...
