Extrait de l'émission CPU release Ex0110 : Node.js.
Bonjour à toi, Enfant du Futur Immédiat, toi qui va monter ton nouveau service et qui n'a pas envie de manipuler plus d'un langage, du moins plus d'un langage informatique car il faut déjà t'expliquer avec tes associés. Mais rédige quand même la doc de ton code, ça te resservira dans 6 mois…
Plusieurs fées s'étaient penchées sur le berceau de la petite Javascript, et toutes n'étaient pas bien attentionnées : Le nom a été imposé par une équipe commerciale qui vendait le langage Java à côté, on a donné 3 semaine à son développeur Brendan Eich pour le bootstraper, le langage a très vite connu des forks (dont le JScript de Microsoft) et souffre de bugs et imprécisions jusque dans sa standardisation, le ECMAscript.
Mais en soit, comme pas mal de langages déjà existants, elle a su se stabiliser très vite et se montrer solide.
À tel point qu'un jour, quelqu'un s'est dit
Eh ! Javascript a suffisamment grandi ! les fonctions propres aux pages web sont suffisamment séparées pour tenter de le faire tourner ailleurs ! Et si je tentais de le mettre sur un serveur web ? Parce que PHP me les broute.
Bon, ok, j'anticipe sur PHP.
C'était en 2009, on était en pleine explosion sur les langages serveurs orientés web.
À l'époque, Ruby on Rails était connu pour être facile à développer mais très longtemps les docs les plus utiles étaient en Japonais. Microsoft avec son C# poussait pour du langage compilé mais qui tournait que sur son OS, et le framework Django complétait Python mais avait encore plein de manques.
Très vite Javascript côté serveur, aka NodeJS, a connu une popularité énorme, et une très forte communauté. En fait, avec le recul, le décollage a été immédiat pour une plateforme qui était très instable. 10 ans après, celle-ci est toujours aussi dynamique. Mais des fois, pas toujours dans le bon sens.
Enfant du Futur Immédiat, je vais te raconter une histoire vécue :
Il y a 3 ans, je m'occupais dans une entreprise éditant des applications mobiles et des serveurs applicatifs. Ceux-ci étaient un subtil mélange de PHP et de Python. Et l'équipe back-end ne manquait pas de stories à compléter pour maintenir et faire évoluer l'infrastructure. Un jour, on a eu un nouveau directeur informatique. Celui-ci a décrété qu'on allait passer tout le backend en NodeJS. Ce matin-là, on avait entendu une mouche voler. Devant l'enthousiasme très contenu de l'équipe, le nouveau N+1 demanda qui s'y connaissait en javascript.
Tous les devs tournaient le regard vers l'usual suspect. Ma main fut la seule à se lever.
— Ah ( fit-il. visiblement contrarié que je sois le seul à m'y connaitre, et il craignait la suite)
— Monsieur le Directeur technique, pour quelle raison devrions-nous tout migrer vers NodeJS ?
— Parce que le développement est plus rapide et que les programmes vont bien plus vite en NodeJS.
La gène était générale. Surtout que je faisais une moue parce que je n'étais absolument pas convaincu de l'argument, et que mes collègues se ralliaient à moi. Il faut dire qu'au même moment, la solution d'auto-hébergement de données Cozy Cloud ré-écrivait tout son back-end de NodeJS vers Go pour justement… des raisons de performances.
J'ai demandé à des connaissances leur avis sur l'argument de mon supérieur hiérarchique, ils étaient assez compassionnels… entre les hoquets de rire. Heureusement, ce CTO n'est resté en place que 3 mois et tout ses projets (c'était pas le seul qu'il a lancé) sont passés à la trappe ASAP. Et même ASAP dans la minute, parce que nous étions très efficaces dans notre domaine de compétence.
Pourtant, j'apprécie pas mal NodeJS. Même si j'avais essuyé les plâtres beaucoup trop tôt, en 2010 quand il n'était pas très stable, j'ai eu le plaisir de faire des projets rapidement, de m'éclater avec… et si j'ai rien pondu dessus depuis 4 ans, je suis sûr qu'il a connu des évolutions assez marrantes.
Enfant du Futur Immédiat, Javacript côté serveur est passé bien au-delà du concept, et il est utilisé sur des millions d'applications. À toi de l'expérimenter, pour voir si l'environnement te plaît et s'il peut correspondre à des besoins mieux que d'autres solutions.
Texte : DaScritch
Illustration : Logo de Node.js, D.R.