CC-BY-NC-SA
Vidéo : https://www.youtube.com/watch?v=ULXWJQcLaqc Quelles sont les nouvelles tendances du développement web associées à Node en 2014 ?
Présentation de clôture de la SophiaConf 2014.
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.
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.
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.
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.
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).
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.
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…
#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.
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.
( @ 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.”.
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).
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.
« 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 ».
( @ 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.
(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.
(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.
(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.
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.
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 !
(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…
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…
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 ?!
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).
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.
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.
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).
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).
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).
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).
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.
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…
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…).
#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.
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.
#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 !
mattisg
xin9le
star_zero
maaretp
azuki
morit4ryo
uzulla
manfredsteyer
cer
goto_tsl
tomokusaba
nealle
watanave
jmmastey
mraible
bluesmoon
mza
pauljervisheath
kneath
ddemaree
scottboms
danielanewman
swwweet
geeforr
chrisshort
