Node.js passe la sixième vitesse

Source: LinuxFR – les dépêches
Liens: Node.js passe la sixième vitesse
Node.js passe la sixième vitesse

Node.js est la principale implémentation du langage JavaScript côté serveur. Elle utilise V8, le moteur JavaScript de Google Chrome, et vient d’atteindre la version 6.0.0 le 26 avril 2016.

Logo Node.js

La montée de version de V8 vers la version 5.0 a d’ailleurs permis une meilleure prise en charge d’ES6, avec 93 % des fonctionnalités couvertes. Parmi les autres nouveautés, on trouve des performances accrues (notamment pour le chargement des modules), une meilleure stabilité et utilisabilité des API JavaScript (notamment Buffer et File System).

Peu de temps après la sortie de la version 6.0.0, des failles OpenSSL ont été annoncées, ce qui a conduit à la sortie d’une version 6.1.0.

Les différentes versions

Ce n’est pas facile de suivre les différentes branches de node.js suite au fork io.js, qui a ensuite refusionné avec node.js. Toutefois, la situation n’est que temporaire et on devrait y voir plus clair d’ici la fin de l’année. En attendant, voici un petit résumé :

  • node.js 0.10 : une vieille version, qui est toujours celle packagée par Debian notamment, est en phase de maintenance jusqu’à octobre 2016 (ensuite, ce sera les oubliettes)
  • node.js 0.12 : pareil, mais la phase de maintenance durera jusque décembre 2016
  • node.js 4 : c’est la version LTS actuelle. Elle sera en LTS Active jusqu’avril 2017, puis passera en phase de maintenance pour une année supplémentaire
  • node.js 5 : c’est juste une version de développement et elle s’arrêtera dans 2 mois
  • node.js 6 : c’est également une version de développement (current) et deviendra une version LTS en octobre 2016. D’ici là, il pourra encore y avoir des changements assez conséquents (montée de version de V8 notamment).

Donc, pour le moment, il est recommandé d’utiliser node.js 4 en production et de commencer à faire tourner des tests avec node.js 6 dans les environnements d’intégration continue pour détecter les régressions. À noter que pas mal de modules npm compilés sont en train d’être corrigés pour node.js 6.

Npm3

Node.js 5 et 6 viennent avec npm3 et non plus npm2. Ce changement est majeur.

Avec npm2, les dépendances d’une dépendance s’installaient dans le répertoire node_modules de la dépendance. Et donc, on pouvait avoir un même module avec deux versions différentes au sein d’un même projet, si deux dépendances incluaient ce module dans des versions différentes. Avec npm3, ce n’est plus le cas. Toutes les dépendances (directes et indirectes) sont installées dans le node_modules du projet.

Ce changement a permis de régler pas mal de problèmes sous Windows, où les dépendances de dépendances de dépendances de… (vous voyez l’idée) avaient des chemins très longs, trop longs pour Windows. Il permet également de s’assurer qu’un module n’est installé qu’une seule fois par projet, ce qui est très utile pour les projets front-end qui utilisent npm.

Par contre, le passage à npm3 n’a pas que des bons côtés. Ce changement a introduit pas mal de régressions et la situation commence juste à se stabiliser. Npm3 est également de façon notoire bien plus lent que npm2.

ES6, ES7 et la suite

ES6, ou ES2015, la version actuelle du standard qui décrit le langage JavaScript est le fruit d’un long travail et les implémentations des moteurs JavaScript supportent la plupart des fonctionnalités. Que ce soit chez Google, Mozilla, Microsoft ou Apple, on est proche des 100 %, avec jusque quelques bugs sur des cas très particuliers ou la volonté de ne pas implémenter les Tail Calls Optimisation (car ils posent des problèmes).

Pour autant, tout n’est pas rose. Les nouvelles fonctionnalités ne sont pas aussi optimisées que le reste. Les benchmarks montrent qu’il est fréquent que du code ES6 soit entre un et trois ordres de grandeur plus lent que son équivalent en ES5. Les moteurs vont combler ces différences mais cela risque de prendre encore quelques mois ou années.

Autre point noir : les modules d’ES6. L’équipe derrière node.js a fait une proposition pour prendre en charge les modules d’ES6 (en disant que s’ils vont faire les modules d’ES6, ce sera de cette façon, mais il se peut aussi qu’ils ne fassent rien car ils considèrent que les modules d’ES6 sont une mauvaise chose et que le standard devrait étudier à nouveau cette question). Cette proposition n’a pas plu à une partie de la communauté car elle introduit l’extension .mjs, ce qui va poser problème pour les modules qui seront utilisables à la fois par node.js et les navigateurs. On a donc eu le droit à une contre-proposition et les noms d’oiseau ont volé une nouvelle fois sur Twitter. La situation semble enlisée pour le moment.

ES7, ou ES2016, est beaucoup plus léger. C’est principalement l’arrivée de l’opérateur ** pour calculer des puissances et de Array.prototype.includes pour savoir si un élément fait partie d’un tableau.

Par contre, on attend toujours async/await. Cette solution devrait permettre d’écrire du code asynchrone de manière beaucoup plus propre et est même décrite comme la solution miracle depuis plusieurs années. Seul problème, aucun moteur JS ne l’a implémentée pour le moment.

Lire les commentaires

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *