En ce moment côté startup et innovateurs, les développeurs javascript ont le vent en poupe. Pour autant, je ne crois pas que Javascript côté serveur soit le rouleau compresseur qu’on veut nous faire croire.
La syntaxe du langage est honnête, mais a largement autant de points négatifs que de points positifs par rapport à l’existant ailleurs.
Si je résume, on me dit que Javascript a
- Une grosse base de développeurs à cause de son utilisation dans les pages web
- Un runtime existant sur quasiment toutes les machines
- La possibilité d’avoir un seul langage côté client et côté serveur
- Un système de prototype
- Un système d’event loop, api asynchrones et callbacks sur nodejs
La base d’utilisateur est un facteur très important, mais sur ceux ci une frange très mineure peut se réclamer d’avoir une bonne connaissance de Javascript. Le niveau moyen est même presque pire que sur PHP. Si on se contente de ceux qui font plus de quelques lignes et qui pourraient passer côté serveur, la base utilisateur n’est plus si fantastique que cela. PHP ou Java en ont probablement autant si ce n’est plus.
On trouve de quoi exécuter Javascript même sous Windows, mais au final on va installer une machine virtuelle dédiée. Encore une fois, si on parle de côté serveur, Linux et autres BSD sont une bien meilleure cible et là Python ou Ruby sont par défaut, PHP est déployable facilement, Java est presque partout. Je n’ai jamais entendu dire que l’un des trois premiers souffrait d’un frein à cause de la nécessité d’installation sur telle ou telle machine.
La possibilité d’avoir un seul langage n’est pas à négliger, mais au final coder du Javascript pour une page web dans le navigateur n’est pas comme coder du Javascript pour nodejs : Les API, les performances, les besoins, tout ça est différent. Même sans ça, les partages de code entre client et serveurs resteront anecdotique, Java en a fait l’expérience il y a longtemps. Reste la syntaxe qui est la même, et évite un nouvel apprentissage, mais c’est assez faible. L’expertise dans un langage est principalement liée à l’API et à ses implications, la syntaxe de base s’apprend rapidement.
Le système de prototype est effectivement une des spécificités de Javascript par rapport aux langages courants. Ceci dit c’est un point incompris par quasiment tous les développeurs au point que tous essayent de recréer artificiellement un système de classe au dessus du système de prototype. Le résultat est d’ailleurs un peu bancal. En théorie le système de prototype ça peut être génial. Dans la réalité, sauf pour une petite minorité, c’est un gros point noir. Difficile de considérer ça comme un avantage.
Il reste un point, particulier : Tout l’environnement Javascript côté serveur s’est construit autour d’un système asynchrone bourré de callback. S’il est facile d’y faire de la programmation spaghetti, c’est aussi une grande force et la plus grande spécificité du langage.
Avoir un système d’évent loop avec des accès asynchrones c’est réalisable sur les autres langages, mais ça prend du temps. Il faut refaire tout un jeu de bibliothèques. Les quelques essais actuels sont limités, complexes à mettre en oeuvre, et surtout n’ont pas eu le coup de projecteur qui a lancé nodejs.
Et c’est un peu ça l’idée : Rien n’empêche Ruby, Python ou Java de créer une bibliothèque équivalente à nodejs. S’il y a une vraie valeur ajoutée, alors ça se fera. À ce moment là, à part le coup de projecteur, Javascript n’aura plus de quoi prétendre être en avance. Ça restera un bon langage, avec une excellente machine virtuelle, qui méritera probablement d’être côté serveur, mais pas plus que les autres. Je ne vois pas ce qui justifiera la lame de fond que certains imaginent.
Laisser un commentaire