1 Présenté le 3 juillet 2014 à Sophia-Antipolis lors de la soirée « Nouvelles tendances du développement web » de la SophiaConf. CC-BY-NC-SA You can quote, reuse and remix this presentation as long as you cite me, but you may not make money out of it, including from training classes. If you include parts of this work in yours, you must make your own work available to the public for reuse too. Also, it would be nice from you to let me know about it :) If you want to use this material otherwise, please contact me. 

M AT T I S C H N E I D E R / / @ M AT T I _ S G X Développe des applications web de manière agile, actuellement en tant qu’indépendant. 7 ans de développement JS. 3 ans d’usage quotidien de Node, notamment à travers Watai, un outil de test d’intégration d’application web. 

X Parler de Node en 2014… pour dire quoi ? Cela fait maintenant cinq ans que cet exécutable permettant d’exécuter du code JavaScript en dehors du navigateur est disponible, Node en tant que tel n'est donc plus une « nouvelle tendance ». Je vais donc essayer d'isoler ce qui l’est. 

API 2 Avant tout, qu’est-ce que Node ? Le terme recouvre plusieurs composantes de maturité variable. 

API 3 Maturité Nous allons rapidement les passer en revue et préciser leur niveau respectif de maturité. 

4 Maturité API Le langage JavaScript existe depuis vingt ans, est aujourd’hui mature et continue à évoluer (ES6), mais avec un organisme responsable de sa compatibilité ascendante et à un rythme très lent. 

5 Maturité API La machine virtuelle V8, qui interprète le langage, continue à évoluer régulièrement. On observe notamment une augmentation continue des performances, mais également une très bonne stabilité. À la base, c’est l’interprète JavaScript de Google Chrome, qui a été extrait du contexte du navigateur pour permettre l’exécution de JavaScript de manière indépendante. 

6 Maturité API Extraire l’interprète est nécessaire, mais pas suffisant au découplage d’avec le navigateur. C’est l’API de Node qui permet l’interaction avec le système d’exploitation plutôt qu'avec le navigateur (ouvrir des fichiers, des sockets plutôt que modifier des éléments du DOM). 

7 Maturité API Quand on parle de Node, on inclut aussi aujourd’hui le gestionnaire de paquets NPM (Node Package Manager). Exécutable indépendant, mais installé par défaut par tout installateur de Node. Relativement stable, mais la compatibilité ascendante n’est pas toujours respectée. 

8 Maturité API Le registre public des modules NPM et le réseau de distribution associé font aussi partie de l’écosystème Node, puisque ce sont eux qui rendent accessibles les modules… du moins quand ils sont disponibles ! C’est la composante aujourd’hui la moins mature de l’écosystème, avec de nombreux modules de mauvaise qualité, et de régulières indisponibilités. Il faut dire que l’architecture n’avait pas été prévue pour 13 millions de téléchargements par jour… 

API plateforme 9 Le point principal est que “Node.js is a platform” (source), dont tous les composants ne sont pas au même niveau de maturité. Néanmoins, une tendance claire se dégage. 

10 M AT U R AT I O N tendance #1 C’est celle d’une maturation de l’écosystème. Aujourd’hui, les utilisateurs de Node ne sont plus dans une phase exploratoire, et attendent de toutes les composantes qu’elles se stabilisent pour pouvoir développer des applications de grande envergure. C’est en effet l’objectif annoncé de la plateforme : faciliter la création de programmes réseaux qui passent à l’échelle. 

programmes réseaux 11 “Node's goal is to provide an easy way to build scalable network programs.” (source). Mais qu’est-ce qui n’est pas encore un programme réseau ? Tout se connecte (IoT…). Tout programme devient donc un programme réseau. 

application web 12 Plus précisément, tout programme devient un programme réseau avec, le plus souvent, une application web en bout de chaîne pour présenter les résultats à l’utilisateur final. 

– J E F F AT W O O D ( @ C O D I N G H O R R O R ) « Toute application sera bientôt une application web. » 13 Vous connaissez forcément Jeff Atwood, même sans le savoir. C’est un des cofondateurs de StackOverflow. Jeff Atwood nous disait déjà en 2009, indépendamment de Node : “Pretty soon, all programming will be web programming.”. 

14 Que signifie qu’une application devienne une « application web » ? Quelle est la différence aujourd’hui ? Elle semble de plus en plus ténue. La frontière n’est plus dans l’interactivité depuis le « Web 2.0 ». 

15 Et elle ne semble plus dans les performances ou la complexité non plus. En 2011 déjà, on faisait de la synthèse vocale dans le navigateur grâce à speak.js, port d’eSpeak (C++) via emscripten (compilateur LLVM → JS). 

16 On peut même aller plus loin en étendant cette analyse à toute la « plateforme web », c’est-à-dire les technologies connexes à JavaScript tels que WebGL, canvas… Mars 2013 : Mozilla aide à porter Unreal Engine 3 (UT3) en 4 jours, 40% des performances natives. Mars 2014 : Unreal Engine 4 (encore peu de jeux avec ce moteur, premier sorti : Daylight, PS4, 29 avril 2014), 67% des performances natives. 

17 Il est donc clair que la frontière entre une « application » et une « application web » s’efface, ce qui semble donner raison à Atwood. Atwood est d’ailleurs allé plus loin, avec sa fameuse « loi d’Atwood ». 

– J E F F AT W O O D ( @ C O D I N G H O R R O R ) « Toute application qui peut être écrite en JavaScript sera à terme écrite en JavaScript. » 18 Dans The principle of least power, 2007-07-17 (deux ans avant Node). C’est là que ceux qui ne le connaissaient pas comprennent pourquoi son blog s’appelle CodingHorror… Si cette prophétie s’avère vraie, alors Node, en venant étendre la quantité d’applications qui peuvent être écrites en JavaScript, devrait générer une immense production d’applications écrites en JavaScript. 

19 Cette prophétie se réalise-t-elle pour les applications écrites en JavaScript en dehors du côté client ? 

2011/06/26 2011/12/26 2012/06/26 2012/12/26 2013/06/27 2013/12/27 2014/06/28 Clojars (Clojure) CPAN (Perl) GoDoc (Go) Maven Central (Java) Rubygems.org nuget (.NET) Packagist (PHP) PyPI (Python) npm (node.js) 20 Évolution du nombre de paquets publics Il semblerait que oui, si l’on se base sur le nombre de modules publiés sur les registres publics des langages les plus utilisé (source : modulecounts.com). Le 30 juin 2014, Maven, premier dépôt depuis toujours en termes de modules hébergés, a été dépassé par NPM avec 80970 modules publiés contre 80962. Évidemment, il y a des biais : JavaScript et Node aident à créer des micro-bibliothèques, et on publie en partie des bibliothèques frontend, ce qui pousse au grand nombre. Et on a en tant qu’usager les inconvénients de ce grand nombre… Tweet : @_kud, 2014-03-25. Une discussion intéressante s’ensuit. 

2011/06/26 2011/12/26 2012/06/26 2012/12/26 2013/06/27 2013/12/27 2014/06/28 Clojars (Clojure) CPAN (Perl) GoDoc (Go) Maven Central (Java) Rubygems.org nuget (.NET) Packagist (PHP) PyPI (Python) npm (node.js) 20 Évolution du nombre de paquets publics Il semblerait que oui, si l’on se base sur le nombre de modules publiés sur les registres publics des langages les plus utilisé (source : modulecounts.com). Le 30 juin 2014, Maven, premier dépôt depuis toujours en termes de modules hébergés, a été dépassé par NPM avec 80970 modules publiés contre 80962. Évidemment, il y a des biais : JavaScript et Node aident à créer des micro-bibliothèques, et on publie en partie des bibliothèques frontend, ce qui pousse au grand nombre. Et on a en tant qu’usager les inconvénients de ce grand nombre… Tweet : @_kud, 2014-03-25. Une discussion intéressante s’ensuit. 

2011/06/26 2011/12/26 2012/06/26 2012/12/26 2013/06/27 2013/12/27 2014/06/28 Clojars (Clojure) CPAN (Perl) GoDoc (Go) Maven Central (Java) Rubygems.org nuget (.NET) Packagist (PHP) PyPI (Python) npm (node.js) 20 Évolution du nombre de paquets publics Il semblerait que oui, si l’on se base sur le nombre de modules publiés sur les registres publics des langages les plus utilisé (source : modulecounts.com). Le 30 juin 2014, Maven, premier dépôt depuis toujours en termes de modules hébergés, a été dépassé par NPM avec 80970 modules publiés contre 80962. Évidemment, il y a des biais : JavaScript et Node aident à créer des micro-bibliothèques, et on publie en partie des bibliothèques frontend, ce qui pousse au grand nombre. Et on a en tant qu’usager les inconvénients de ce grand nombre… Tweet : @_kud, 2014-03-25. Une discussion intéressante s’ensuit. 

21 Il semble donc empiriquement que oui, toute application qui peut être écrite en JavaScript soit en train de l’être. 

principe de moindre pouvoir 22 Mais ce constat n’est pas qu’empirique. En réalité, Atwood se base sur l’un des axiomes de l’architecture du web donné par Tim Berners-Lee. The principle of least power has a W3C-documented rationale: “the less powerful the language, the more you can do with the data stored in that language”. Le couple JS/JSON incarne ce principe. 

23 Mais, tout ce qui peut l’être… Certainement, tout ne peut pas être écrit en JavaScript. Et l’embarqué, alors ? 

24 Tessel est un microcontrôleur rendu possible par du financement participatif, sur lequel on peut brancher une grande quantité de modules. Un peu comme un Arduino, mais avec du JavaScript. Pour développer : `npm install tessel`. Pour ajouter un module : le brancher, et `npm install sensor` par exemple. Le code est poussé sur le microcontrôleur en WiFi. Ce n’est d’ailleurs pas le seul microcontrôleur capable d’exécuter du JavaScript : Espruino est son alternative principale. Fun : le logo Tessel est généré par un module NPM… JSception ! 

25 Donc, oui : à chaque fois qu’il est possible d’écrire une application en JavaScript, cette application est écrite en JavaScript. 

26 E X PA N S I O N tendance #2 C’est bien cette tendance que l’on voit : l’expansion de JavaScript dans des domaines de plus en plus éloignés du client web. 

remplacer tous les devs par des frontend 27 Si JavaScript va tout manger, alors autant s’y mettre, non ? En plus, les ingés front coûtent moins cher ! 

remplacer tous les devs par des frontend 27 Si JavaScript va tout manger, alors autant s’y mettre, non ? En plus, les ingés front coûtent moins cher ! 

28 PayPal intends to switch fully from Java to Node (2013-11-22). Less LoC, less files, more performance (x2 requests, 35% less latency). This does not mean you should expect the same, but it is an interesting data point. It worked so well for them that they open-sourced KrakenJS, the suite they developed over Express to help with Node backends… 

29 Box is like Dropbox, but for bigger companies. Box notes is a collaborative edition service introduced on 2014-05-08, written in Node.js! Obviously, it has load balancing and is not exposing directly the built-in Node server to end-users. Requests go through an Apache Helix stack, finally hit the Node after layers of indirections, which treat them and redirect to a balanced DB access layer… 

30 Meteor Et on a bien entendu Meteor, un framework 100% JS avec sérialisation automatique, appel distant à la DB serveur depuis le client… Mais… si à chaque fois on a besoin d’un framework, c’est bien que le JS dont on a déjà l’habitude n’est pas suffisant ?! 

31 ≠ Le fantasme d’écrire un seul JavaScript est effectivement… un fantasme. Si vous parlez à un développeur habitué au JS côté client de Promesses, de Streams, de remontée (ou pas) des erreurs dans la boucle d’événements principale, des callbacks de l’API fs… il ne saura pas de quoi on parle. Partager le langage n’est pas la même chose que partager l’environnement d’exécution. On ne partage pas les références, pas les prototypes, on doit toujours sérialiser pour passer sur le réseau… Le fantasme d’avoir tout dans un langage est celui qui a mené à GWT (paix à son âme). 

32 A D O P T I O N R A I S O N N É E E N P R O D U C T I O N tendance #3 L’adoption se fait donc au cas par cas, souvent pour une brique, en full stack sur des projets spécifiques dans des besoins précis. L’interaction avec l’existant est facile car HTTP + architecture micro-services, ou streams + interface POSIX. Également, il est possible d’avoir des ponts avec l’existant avec par exemple Nodyn, API Node dans la JVM pour interagir directement avec Java. 

remplacer tous les outils par des frontend 33 Ce qu’on observe n’est donc pas un remplacement des développeurs… En revanche, on assiste clairement à un développement d’outils d’aide à la réalisation d’applications web qui part du monde du côté client. 

34 La création d’une nouvelle applications web est facilitée par Yeoman. Comment l’utiliser ? `npm install yeoman` 

35 Grunt, un gestionnaire de workflow (penser : Ant sans XML) ? `npm install grunt` Il a été « remplacé » par Gulp comme le gestionnaire génial avant même d’avoir atteint la maturité. Le remplacement de Grunt par Gulp est certes une preuve du manque de maturité d’un écosystème qui se construit, mais est aussi l’affirmation de la spécificité des API Node (Grunt proche de Make, Gulp basé sur les streams). La discussion engendrée a aussi permis de centrer le débat sur la nécessité de changer aussi souvent d’outils. Pour information, j’utilise npm run ou, au besoin, task.js (voire stagedProcess.sh). 

35 Grunt, un gestionnaire de workflow (penser : Ant sans XML) ? `npm install grunt` Il a été « remplacé » par Gulp comme le gestionnaire génial avant même d’avoir atteint la maturité. Le remplacement de Grunt par Gulp est certes une preuve du manque de maturité d’un écosystème qui se construit, mais est aussi l’affirmation de la spécificité des API Node (Grunt proche de Make, Gulp basé sur les streams). La discussion engendrée a aussi permis de centrer le débat sur la nécessité de changer aussi souvent d’outils. Pour information, j’utilise npm run ou, au besoin, task.js (voire stagedProcess.sh). 

36 Bower, gestionnaire de paquets côté client lancé par Twitter… et qui lui aussi va disparaître. Mais cette fois-ci, remplacé non pas par un nouvel arrivant mais par NPM lui-même ! Le gestionnaire de paquets de Node devient en réalité le gestionnaire de paquets JavaScript, aidé par des outils comme napa (qui permet d’installer comme dépendance un dépôt n’ayant pas été publié sur NPM). 

36 Bower, gestionnaire de paquets côté client lancé par Twitter… et qui lui aussi va disparaître. Mais cette fois-ci, remplacé non pas par un nouvel arrivant mais par NPM lui-même ! Le gestionnaire de paquets de Node devient en réalité le gestionnaire de paquets JavaScript, aidé par des outils comme napa (qui permet d’installer comme dépendance un dépôt n’ayant pas été publié sur NPM). 

37 Les applications Node commencent aujourd’hui à aller plus loin que la ligne de commande, et utilisent toutes les avancées du web. Exemple : ungit, qui fournit une interface graphique sur Git, qui ouvre un serveur de manière transparente. On peut s’y connecter en local mais peut donc également être utilisée sur les services de cloud. On voit donc que Node peut également être une porte d’entrée vers les interfaces web pour les développeurs historiquement backend. 

38 L’aboutissement est probablement incarné par Atom, l’éditeur de code de GitHub, qui mélange les deux API : interface web avec backend Node, le tout packagé dans une seule application. Du JS appelant dans la même ligne les API du DOM et de Node… 

39 C R É AT I O N M A S S I V E D ’ O U T I L S tendance #4 Permet aux devs frontend de résoudre leurs problèmes. Et la complexification des interfaces web côté client de ces dernières années a fait qu’ils en avaient beaucoup (cf. création du poste de « frontend operations », sessions précédentes…). 

40 M AT U R AT I O N tendance #1 À la fois cause et conséquence, puisque les outils permettent de faire mûrir l’écosystème, mais voient également le jour au fur et à mesure de cette maturation. 

41 A D O P T I O N R A I S O N N É E E N P R O D U C T I O N tendance #3 Cette maturation pousse à l’adoption. Cependant, l’adoption en tant que serveur de production contraste avec celle des outils, et se fait encore au cas par cas. La tendance à la massification apparaîtra certainement dans le temps. 

42 E X PA N S I O N tendance #2 On peut lier cette adoption à l’élargissement des types de programmes pouvant être écrits avec du JavaScript. Les preuves de fonctionnement en conditions réelles encouragent à viser de nouvelles frontières. Rendez-vous l’an prochain pour voir où on retrouvera JavaScript ! 

Remerciements Anouchka Labonne Thomas De Bona Crédits images Cartographie serveurs NPM © Brandon Cannaday Logo V8 © Alessandro Gatti Marques © leurs propriétaires Logo JS WTFPL Chris Williams Icônes depuis The Noun Project : Server CC-BY Konstantin Velichko Microchip CC-BY Márcio Duarte 43 Q U E S T I O N S ? M E R C I !