Choisir la bonne librairie Javascript

Lorsque l’on souhaite faire évoluer nos projets, ou tout simplement parce que l’on a besoin de nouveaux outils pour nous faciliter la vie, nous sommes régulièrement amenés à rechercher de nouvelles librairies JavaScript via le Node Package Manager.

Chez i-Run, nous savons à quel point il est difficile de choisir sa nouvelle librairie, et ce, pour diverses raisons.
Nous avons donc établi une liste de critères afin de nous orienter et nous permettre de sélectionner la bonne librairie Node.js.

1/ La performance

Par souci de rapidité de chargement et afin d’offrir une meilleure expérience utilisateur, nous aurons tendance à privilégier une librairie légère en termes de poids (ko).

Bien entendu, tout dépendra du nombre de fonctionnalités attendues, toutefois et en règle générale on ne dépassera pas :

• Quelques kilo octets pour une librairie de petite taille.
• Moins d’un méga octets pour des librairies plus conséquentes.

Nous devons, avant tout, étudier le ratio poids/fonctionnalités en comparant plusieurs librairies similaires.
En effet, il serait dommage de sélectionner une librairie pour sa légèreté alors qu’elle ne couvrirait que la moitié de nos besoins.

2/ Facilité d’utilisation

La facilité d’utilisation et de prise en main d’une librairie doit se faire de manière intuitive afin que l’on puisse l’adopter rapidement.

Pour une librairie utilisée de manière occasionnelle, il est préférable d’orienter son choix vers une librairie simple d’utilisation.
En effet, une librairie qui n’est pas intuitive combinée à une utilisation occasionnelle, demandera un trop grand effort de documentation à chaque utilisation.

En survolant les parties de la documentation du module tel que l’installation, la configuration et l’utilisation, nous pourrons ainsi jauger rapidement de la complexité d’intégration et d’utilisation de cette dernière.

Bien entendu, le niveau de complexité de configuration et d’utilisation d’une librairie augmente au prorata de sa taille.
Il faudra donc comparer ce qui est comparable en opposant au moins deux librairies aux fonctionnalitées équivalentes.

3/ Documentée

La librairie est-elle documentée de manière exhaustive ? Possède-t-elle un site web dédié, un README.md bien détaillé ?
La documentation est-elle à jour ?

Quelle que soit la taille de la librairie, nous devons pouvoir répondre positivement à ces questions, car cela nous évitera de nombreuses frustrations par la suite. Comme par example, découvrir une option ou une fonctionnalité du module dans un article de blog alors qu’il n’est pas répertorié dans la documentation officielle. Si nous pouvons éviter de partir à la chasse aux fonctionnalités en passant en revue le code source, cela nous fera gagner un temps précieux.

4/ Maintenue

Une librairie qui est soutenue par la communauté a de forte chance d'être maintenue à jour et de proposer de nouvelles features.

Sur Github:

Certains indicateurs présents sur le répertoire Github du projet nous aident à déceler son “état de santé” :

• Le nombre de star (plus y en a, plus le projet est apprécié par la communauté)
• Le nombre de fork (plus y en a, plus le projet intéresse la communauté)
• La date de la dernière issue closed (date récente = bon signe)
• Le nombre d’issues et de Pull Request en cours (prises en compte par les mainteneurs = bon signe)
• La date du dernier commit (date récente = bon signe)
• Le nombre de contributeurs (volumineux = bon signe)

Sur NPMJS:

La page npm de la librairie rassemble une bonne partie des informations dont nous avons besoin :

• Le nombre de téléchargements hebdomadaire (volumineux = bon signe)
• La version en cours
• La taille du projet (packagé)
• Le nombre d’issues sur Github, la date de la dernière publication ainsi que lien vers le répertoire
• Lien vers la documentation (présent = bon signe)

exemple : la page npm de Vue

Sur Stack Overflow :

En tant que plateforme d'échange communautaire de référence pour les développeurs, Stack Overflow nous permet également de sonder la popularité de notre librairie :

En effectuant une recherche par tags, on peut découvrir le nombre de questions relatives au sujet (volumineux = bon signe)

exemple : Sujets taggés vue.js sur Stack Overflow

Sur les agrégateurs d’informations :

Il est enfin possible de retrouver l’ensemble des éléments cités plus haut dans des agrégateurs qui réunissent en un seul endroit la plupart des informations nécessaires à notre audit.

Il existe plusieurs outils sur le web, toutefois Snyk Advisor et OpenBase nous proposent un dashboard complet reprenant l’ensemble des informations dont nous avons besoin pour auditer notre librairie.

exemple : Vue.js sur Snyk Advisor ou sur OpenBase

5/ Open source

Il est important de connaître le type de licence sous laquelle notre librairie est distribuée, car toutes ne nous confèrent pas les mêmes libertés d’utilisation.
Sans énumérer l’ensemble des licences existantes, nous privilégierons une librairie fournie avec :

• Soit une Licence Open-Source MIT
• Soit une Licence Open-Source APACHE

En effet, ces deux licences Open-Source nous permettent d’utiliser notre librairie comme nous le souhaitons et nous offrent la possibilité d’en modifier le contenu. Cette notion est d’autant plus primordiale dès que vos applications ont une vocation commerciale.

6/ Pour aller plus loin

Mainteneurs et propriétaires :

Il est important de savoir qui a développé la librairie et qui participe à son maintien.

Les grandes librairies sont souvent développées par des grandes compagnies (pour leur propre usage, au départ) puis, grâce à la licence Open-Source, elles sont ensuite maintenues par une communauté de volontaires. Ce qui renforce la confiance dans le choix de cette dernière.
Il faut garder à l’esprit qu’il peut arriver qu’une librairie ne soit plus supportée par son propriétaire et que, faute de communauté et/ou de soutien suffisant, le projet peut cesser d'être maintenu.

Vulnérabilité - Sécurité :

Une librairie n’est pas à l’abri d’une faille de sécurité surtout si celle-ci provient d’une dépendance de cette dernière.
Pour nous aider à vérifier si une librairie est en bonne santé, nous pouvons également utiliser Snyk Advisor qui nous propose un “score de santé” de la librairie ainsi qu’une section dédiée à la sécurité.

Il existe également une Base de donnée dédiée : National Vulnerability Database

Dépendances :

Est-ce que notre librairie dépend d’autres librairies importantes ?
Cette question a un côté “très inception”, car, doit-on réellement auditer les dépendances de notre librairie ? … ainsi que les dépendances de ces mêmes dépendances ?

La réponse est bien évidemment non, toutefois, il est bon d’avoir un aperçu des dépendances de notre librairie et pour ça il existe une commande toute simple : npm view <name_of_module> dependencies

exemple :

npm view vue dependencies

Couverture des tests :

Est-ce que notre librairie possède une couverture de test ?

Une librairie qui possède une large couverture de test est un gage de qualité.
Si nous souhaitons prendre en compte ce facteur dans le choix de notre librairie, on privilégiera une couverture minimale de 70%.

Conclusion

Sélectionner une nouvelle librairie n’est pas toujours évident. Bien qu’il n’existe pas de critères absolus, cette liste nous offre un bon panel de l’ensemble des points à vérifier avant de valider notre sélection.

Il existe toutefois une dernière notion, le feeling … qui différera suivant telle ou telle librairie, tel ou tel mainteneur.
Cette dernière notion influera très certainement sur notre prise de décision et l’expérience du décisionnaire aura souvent le dernier mot.