Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Choisir une bibliothèque ou un framework JavaScript

Umar Hansa

Cet article explique comment choisir une bibliothèque ou un framework à utiliser dans votre application Web. Les discussions de ce document vous aideront à peser le pour et le contre afin de trouver la bibliothèque ou le framework JavaScript adaptés au problème métier que vous essayez de résoudre. Il est essentiel de comprendre quels avantages et inconvénients s'appliquent à différentes situations pour évaluer le grand nombre de bibliothèques JavaScript disponibles.

Que sont les bibliothèques et les frameworks JavaScript ?

Qu'est-ce qu'une bibliothèque JavaScript ? Dans sa forme la plus simple, une bibliothèque JavaScript est un code pré-écrit que vous pouvez appeler dans le code de votre projet pour effectuer une tâche spécifique.

Cet article mentionne principalement les "bibliothèques". Cependant, de nombreuses discussions s'appliquent également aux frameworks. En gros, la différence entre les deux peut être résumée comme suit :

Pour une bibliothèque, le code de votre application appelle le code de la bibliothèque.
Pour un framework, votre code d'application est appelé par le framework.

Les exemples pratiques suivants illustrent les différences.

Exemple d'appel d'une bibliothèque JavaScript

Une bibliothèque JavaScript effectue une tâche spécifique, puis redonne le contrôle à votre application. Lorsque vous utilisez une bibliothèque, vous contrôlez le flux de l'application et choisissez quand l'appeler.

Dans l'exemple suivant, le code d'application importe une méthode à partir de la bibliothèque lodash. Une fois la fonction terminée, le contrôle est renvoyé à votre application.

import capitalize from 'lodash.capitalize';
capitalize('hello'); // Hello

Lorsque la méthode lodash.capitalize est exécutée, elle appelle un code JavaScript pré-écrit qui met en majuscule le premier caractère d'une chaîne.

Exemple d'utilisation d'un framework JavaScript

Un framework JavaScript est un modèle de code prédéfini dans lequel vous construisez le comportement de votre application. En d'autres termes, lorsque vous utilisez un framework, celui-ci contrôle le flux de l'application. Pour utiliser un framework, vous écrivez le code de votre application personnalisée, puis le framework appelle ce code.

L'exemple suivant montre un extrait de code qui utilise le framework JavaScript Preact :

import { createElement } from 'preact';

export default function App() {
  return (
    <p class="big">Hello World!</p>
  )
}

Dans l'exemple, vous pouvez remarquer que le framework a beaucoup plus de contrôle sur le code que vous écrivez. Dans certains cas, il prend même le contrôle sur le moment où votre code doit être exécuté.

Pourquoi utiliser une bibliothèque ?

L'utilisation d'une bibliothèque JavaScript peut vous aider à éviter les répétitions de code inutiles. Les bibliothèques peuvent abstraire une logique complexe, comme la manipulation de dates ou les calculs financiers. Une bibliothèque peut également vous aider à lancer votre produit initial, plutôt que d'avoir à écrire tout le code à partir de zéro, ce qui peut prendre du temps.

Certaines bibliothèques JavaScript côté client permettent d'éliminer les particularités de la plate-forme Web. Une bibliothèque peut également servir d'outil d'apprentissage. Par exemple, si vous ne connaissez pas les fonctions d'accélération d'animation, le code source d'une bibliothèque peut vous apprendre comment elles fonctionnent.

Certaines bibliothèques sont soutenues par de grandes entreprises qui investissent du temps et de l'argent pour les maintenir à jour et sécurisées. De nombreuses bibliothèques sont accompagnées d'une documentation complète, qui vous permet, à vous et à votre équipe, de vous familiariser rapidement avec l'utilisation de la bibliothèque.

En fin de compte, l'utilisation d'une bibliothèque JavaScript vous fait gagner du temps.

Pourquoi l'utilisation de la bibliothèque est-elle importante ?

Techniquement, vous pouvez développer votre application Web de toutes pièces, mais pourquoi vous donner cette peine alors que vous pouvez utiliser un logiciel libre (open source) ou acheter une solution qui, à long terme, peut vous faire gagner du temps et de l'argent ? Il existe un grand nombre de bibliothèques et de frameworks JavaScript, chacun offrant une approche unique pour résoudre les problèmes et présentant des caractéristiques différentes. Exemple :

Une bibliothèque peut être écrite et gérée en interne plutôt que par un tiers.
Une bibliothèque peut disposer de licences juridiques spécifiques qui la rendent adaptée ou non à votre application Web.
Une bibliothèque peut être obsolète ou ne plus être gérée.
Une bibliothèque peut simplifier un ensemble de tâches complexes, et vous faire gagner beaucoup de temps et d'argent.
Une bibliothèque peut être largement utilisée par la communauté et bien connue des développeurs.

Comme vous pouvez l'imaginer, différentes caractéristiques peuvent affecter votre application Web de différentes manières. Parfois, la décision n'est pas si importante, et vous pouvez facilement remplacer une bibliothèque si elle ne vous plaît pas. Cependant, une bibliothèque peut parfois avoir un impact significatif sur votre travail et votre application Web, ce qui suggère qu'une approche plus éclairée peut être nécessaire.

Dans certains environnements JavaScript non côté client, comme sur le serveur (exécuté dans un environnement cloud) ou sur un Raspberry Pi, vous devrez peut-être ajuster les critères que vous utilisez pour examiner les bibliothèques et les frameworks.

Performances

L'impact d'une bibliothèque JavaScript sur les performances d'une application Web côté client ne doit pas être ignoré. Une bibliothèque JavaScript volumineuse peut perturber les performances de chargement de votre page. N'oubliez pas que chaque milliseconde compte.

Prenons l'exemple d'un scénario dans lequel vous utilisez une bibliothèque JavaScript pour l'animation. Certaines bibliothèques peuvent facilement ajouter des dizaines de kilo-octets, voire des centaines de kilo-octets dans certains cas. Les ressources JavaScript de ce type peuvent retarder considérablement le chargement de page, car le navigateur doit télécharger, analyser, compiler et exécuter le code.

Plus la bibliothèque JavaScript est volumineuse, plus l'impact sur les performances est important pour vos utilisateurs.

Lorsque vous évaluez ou utilisez une bibliothèque ou un framework JavaScript, tenez compte des suggestions suivantes pour améliorer les performances :

Si vous utilisez une bibliothèque JavaScript volumineuse, envisagez d'utiliser une alternative plus petite. Par exemple, date-fns offre de nombreuses fonctionnalités pour une taille plus raisonnable que d'autres options.
En reprenant l'exemple date-fns précédent, n'importez que les fonctions dont vous avez besoin, par exemple : import { format } from 'date-fns'. Veillez à combiner cette approche avec le tree shaking, afin qu'une charge utile JavaScript minimale soit créée et envoyée à vos utilisateurs.
Utilisez des outils de test des performances tels que Lighthouse pour observer l'impact sur les performances de l'utilisation d'une bibliothèque JavaScript spécifique. Si une bibliothèque ajoute un délai d'une seconde au temps de chargement de votre page (n'oubliez pas de limiter votre réseau et votre processeur pendant les tests), vous devrez peut-être réévaluer la bibliothèque de votre choix. En plus de vérifier le chargement de la page, veillez à profiler tout comportement de page Web qui appelle du code de la bibliothèque en question. En effet, les performances de chargement de la page ne suffisent pas à donner une vue d'ensemble.
Si l'auteur de la bibliothèque accepte les commentaires, envoyez-lui vos observations, suggestions et même contributions au projet. C'est là que la communauté Open Source tire son épingle du jeu. Si vous décidez de faire une contribution, vous devrez peut-être d'abord vérifier auprès de votre employeur.
Utilisez un outil de suivi automatisé des bundles, tel que bundlesize, pour surveiller les mises à jour de bibliothèque d'une taille anormalement élevée. Il est courant qu'une bibliothèque JavaScript s'agrandisse au fil du temps. L'ajout de fonctionnalités, les corrections de bugs, les cas particuliers et d'autres éléments peuvent augmenter la taille du fichier d'une bibliothèque. Une fois que vous ou votre équipe avez accepté d'utiliser une bibliothèque, sa mise à jour peut poser moins de problèmes et ne susciter que peu ou pas de questions. C'est là que l'automatisation s'avère utile.
Examinez vos exigences pour une bibliothèque et déterminez si la plate-forme Web offre ou non la même fonctionnalité de manière native. Par exemple, la plate-forme Web propose déjà un sélecteur de couleur, ce qui évite d'avoir à utiliser une bibliothèque JavaScript tierce pour implémenter la même fonctionnalité.

Sécurité

L'utilisation d'un module tiers comporte des risques de sécurité inhérents. Un package malveillant dans la codebase de votre application Web peut compromettre la sécurité de votre équipe de développement et de vos utilisateurs.

Prenons l'exemple d'une bibliothèque publiée dans l'écosystème NPM. Un tel package peut être légitime. Cependant, au fil du temps, le package peut être compromis.

Voici quelques conseils de sécurité à prendre en compte lorsque vous utilisez ou évaluez du code tiers :

Si vous utilisez GitHub, tenez compte des offres de sécurité du code, telles que Dependabot. Vous pouvez également envisager d'utiliser d'autres services qui analysent les failles de votre code, comme snyk.io.
Envisagez de faire appel à des services d'audit de code, c'est-à-dire à une équipe d'ingénieurs capables d'auditer manuellement le code tiers que vous utilisez.
Déterminez si vous devez verrouiller vos dépendances sur une version spécifique ou valider votre code tiers dans votre contrôle des versions. Cela peut vous aider à verrouiller votre dépendance sur une version particulière, qui est vraisemblablement considérée comme sûre. Paradoxalement, cela peut avoir un effet inverse sur la sécurité, car vous risquez de passer à côté de mises à jour essentielles de la bibliothèque.
Parcourez la page d'accueil du projet ou la page GitHub, le cas échéant. Recherchez s'il existe des problèmes de sécurité non résolus et si les problèmes de sécurité précédents ont été résolus dans un délai raisonnable.
Le code tiers qui utilise un autre code tiers peut présenter plus de risques qu'une bibliothèque qui n'a aucune dépendance. Soyez conscient de ce risque.

Accessibilité

Vous vous demandez peut-être quel est le rapport entre les bibliothèques logicielles et l'accessibilité Web. Bien qu'une bibliothèque logicielle puisse être utilisée dans différents environnements, l'accessibilité Web est d'une grande importance dans le contexte d'une bibliothèque JavaScript côté client.

Une bibliothèque (ou un framework) JavaScript côté client peut augmenter ou diminuer l'accessibilité de votre site Web. Prenons l'exemple d'une bibliothèque JavaScript tierce qui ajoute un curseur d'image à une page. Si le curseur d'image ne tient pas compte de l'accessibilité Web, vous, en tant que développeur Web, risquez de négliger une fonctionnalité aussi importante et de publier un produit auquel il manque des fonctionnalités essentielles, comme la possibilité de naviguer dans le curseur à l'aide du clavier.

Le plug-in de typographie responsive est-il compatible avec les utilisateurs qui effectuent un zoom avant ou arrière sur la page ?
Le plug-in d'importation de fichiers est-il compatible avec l'importation de fichiers depuis des appareils d'assistance ?
La bibliothèque d'animations est-elle compatible avec les utilisateurs qui préfèrent les animations réduites ?
Le plug-in de cartes interactives est-il compatible avec une utilisation au clavier uniquement ?
La bibliothèque du lecteur audio offre-t-elle une expérience appropriée sur les lecteurs d'écran ?

Il est raisonnable de s'attendre à ce que vous, en tant que développeur Web, deviez vous impliquer dans une certaine mesure pour répondre à ces exigences d'accessibilité. Exemple :

Vous pouvez implémenter les fonctionnalités manquantes dans votre codebase, même si vous continuez à utiliser la bibliothèque en question.
Avec l'aide de votre employeur, vous pouvez ajouter une fonctionnalité manquante à la bibliothèque, si l'auteur de la bibliothèque l'autorise.
Vous pouvez ouvrir un dialogue avec l'auteur de la bibliothèque. Par exemple, ces fonctionnalités d'accessibilité spécifiques figurent-elles dans votre feuille de route ? Êtes-vous d'accord pour dire qu'ils ont leur place dans la bibliothèque ?
Pour les cas d'utilisation courants, vous pouvez explorer d'autres options de bibliothèque plus accessibles. Elles existent peut-être, mais sont plus difficiles à trouver.
Dans les cas extrêmes, vous devrez peut-être abandonner complètement une bibliothèque et implémenter vos fonctionnalités de zéro. Cela peut se produire lorsqu'une bibliothèque ou un framework propose une expérience d'accessibilité dégradée lors de la première utilisation, et que vous devez annuler une grande partie de ce que la bibliothèque ou le framework est censé vous fournir sans frais.

Conventions

Une bibliothèque logicielle qui utilise des conventions de codage établies est plus facile à utiliser. Si une bibliothèque utilise une convention de codage inconnue, il peut être difficile pour vous et votre équipe de travailler avec une telle bibliothèque.

Si une bibliothèque ne respecte pas les conventions de codage courantes (par exemple, un guide de style commun), vous ne pouvez pas faire grand-chose pour y remédier immédiatement. Toutefois, il existe encore quelques options :

Veillez à faire la distinction entre le code source de la bibliothèque et l'API exposée à l'utilisateur de la bibliothèque. Même si le code source interne utilise des conventions peu familières, si l'API (la partie de la bibliothèque avec laquelle vous interagissez) utilise des conventions familières, il n'y a peut-être pas lieu de s'inquiéter.
Si l'API de la bibliothèque ne suit pas les conventions de codage courantes, vous pouvez utiliser un modèle de conception JavaScript, comme le modèle de proxy, pour encapsuler et contenir toutes les interactions avec la bibliothèque dans un seul fichier de la codebase. Votre proxy peut alors proposer une API plus intuitive à d'autres parties du code de votre codebase.

Les conventions jouent un rôle important dans la facilité d'utilisation. Une bibliothèque qui inclut une API intuitive peut faire gagner de nombreuses heures, voire des jours de travail, par rapport à une API contre-intuitive qui nécessite beaucoup d'expérimentation pour être comprise.

Mises à jour

Par exemple, une bibliothèque entièrement fonctionnelle qui effectue quelques calculs mathématiques peut rarement nécessiter des mises à jour. En fait, une bibliothèque dotée de fonctionnalités complètes est une trouvaille rare dans le monde en constante évolution du développement Web. Toutefois, il peut arriver que vous souhaitiez que l'auteur de la bibliothèque soit réactif et disposé à effectuer des mises à jour. De nouvelles recherches et découvertes peuvent révéler de meilleures façons de faire les choses. Les techniques utilisées dans les bibliothèques et les frameworks sont donc toujours susceptibles de changer.

Lorsque vous choisissez une bibliothèque ou un framework, faites attention à la façon dont les mises à jour sont gérées et sachez que ces décisions peuvent vous affecter :

La bibliothèque dispose-t-elle d'un calendrier de publication raisonnable ? Par exemple, les mises à jour du dépôt de code source peuvent être fréquentes, mais si elles ne sont pas "publiées" ou "diffusées" en conséquence, vous aurez peut-être du mal à les télécharger.
La bibliothèque publie-t-elle des mises à jour avec un schéma de gestion des versions logicielles pertinent ? Une bibliothèque doit vous faire gagner du temps. Si vous devez modifier votre code de manière inattendue chaque fois que vous mettez à jour la version de la bibliothèque, cela peut aller à l'encontre de l'objectif d'utiliser cette bibliothèque. Les modifications destructives sont parfois inévitables, mais dans un monde idéal, elles sont peu fréquentes et ne sont pas imposées aux utilisateurs de la bibliothèque.
La bibliothèque s'efforce-t-elle d'assurer la rétrocompatibilité ? Parfois, les mises à jour logicielles peuvent s'accompagner de modifications destructives, mais elles fournissent également une couche de rétrocompatibilité. Cela permet au consommateur de la bibliothèque d'utiliser la dernière version de la bibliothèque avec un minimum de modifications de son code.

Licences

Les licences logicielles sont un aspect important de l'utilisation de bibliothèques logicielles tierces. L'auteur d'une bibliothèque peut lui attribuer une licence. Si vous envisagez d'utiliser la bibliothèque, le choix de la licence peut vous affecter.

Par exemple, une bibliothèque JavaScript peut disposer d'une licence logicielle qui vous autorise à l'utiliser dans un environnement non commercial. Pour un projet personnel, cela peut être un excellent choix. Si votre projet comporte un élément commercial, vous devrez peut-être envisager une licence d'entreprise.

En cas de doute, demandez l'avis d'un professionnel ou consultez l'équipe juridique de votre entreprise.

Communauté

Une bibliothèque ou un framework disposant d'une grande communauté d'utilisateurs/de contributeurs peut être bénéfique, mais ce n'est pas une garantie. En général, plus une bibliothèque ou un framework compte d'utilisateurs, plus il est susceptible d'en bénéficier. Voici les avantages et les inconvénients de la participation à une communauté de développement :

Avantages :

Une base d'utilisateurs importante peut augmenter les chances de détecter les bugs rapidement et souvent.
Une grande communauté active peut signifier plus de tutoriels, de guides, de vidéos et même de cours sur la bibliothèque ou le framework en question.
Une communauté active importante peut signifier une plus grande assistance sur les forums et les sites Web de questions-réponses, ce qui augmente la probabilité que les questions d'assistance trouvent une réponse.
Une communauté engagée peut se traduire par un plus grand nombre de contributeurs externes à la bibliothèque ou au framework. Ils peuvent aider à fournir des fonctionnalités qui ne figurent pas dans la feuille de route de l'auteur.
Lorsqu'une bibliothèque ou un framework sont populaires au sein d'une communauté, il est plus probable que vos pairs et collègues en aient entendu parler, voire qu'ils les connaissent.

Inconvénients :

Un projet avec une base d'utilisateurs importante et diversifiée peut devenir surchargé en raison de l'ajout constant de fonctionnalités. Les bibliothèques trop volumineuses peuvent nuire aux performances Web.
Un projet avec une communauté active et engagée peut être stressant pour les auteurs et les responsables de la maintenance, et peut nécessiter une modération importante de la communauté.
Un projet qui se développe rapidement, mais qui ne bénéficie pas d'un soutien approprié, peut commencer à montrer des signes de communauté toxique. Par exemple, les développeurs Web débutants ou juniors peuvent se sentir indésirables dans une certaine communauté en raison du filtrage.

Documentation

Quelle que soit la simplicité ou la complexité d'une bibliothèque ou d'un framework JavaScript, la documentation logicielle peut toujours vous aider. Même les développeurs très expérimentés utilisent la documentation plutôt que de déchiffrer le code eux-mêmes. La documentation clarifie l'API que vous devez utiliser et comment l'utiliser.

La documentation peut même fournir des exemples de code, ce qui vous permet de démarrer rapidement. Lorsque vous évaluez une bibliothèque ou un framework, vous pouvez vous poser les questions suivantes :

La bibliothèque inclut-elle de la documentation ? Si ce n'est pas le cas, vous devrez être à l'aise pour trouver des solutions par vous-même.
La documentation est-elle claire, facile à comprendre et sans ambiguïté ? De nombreux développeurs passent beaucoup de temps sur la documentation. Cela peut sembler insignifiant, mais la clarté de la documentation textuelle peut avoir un impact important sur votre productivité.
La documentation est-elle entièrement générée automatiquement ? Ce type de documentation peut être plus difficile à assimiler et ne fournit pas toujours d'instructions claires sur l'utilisation d'une API.
La documentation est-elle à jour ? La maintenance de la documentation est parfois traitée comme une réflexion après coup. Si la bibliothèque est mise à jour, mais pas la documentation, cela peut entraîner une perte de temps de développement.
La documentation est-elle complète et disponible dans plusieurs formats ? Les guides de l'utilisateur, les exemples de code, la documentation de référence, les démonstrations en direct et les tutoriels sont tous des formats de documentation utiles qui peuvent vous aider à utiliser efficacement une bibliothèque ou un framework.

La documentation ne peut pas toujours être complète, et ce n'est pas grave. Vous devrez évaluer les besoins de votre organisation, les exigences de votre projet et la complexité de votre logiciel, puis utiliser ces informations pour déterminer le niveau de documentation dont vous avez besoin.

Conclusion

Il est normal de se sentir dépassé lorsque l'on choisit une bibliothèque ou un framework pour la première fois. Comme pour tout le reste, plus vous apprenez et pratiquez une tâche, plus vous vous améliorez. Il peut être utile de vous référer à cet article la prochaine fois que vous choisirez une bibliothèque ou un framework à utiliser. Vous pouvez utiliser les titres de cet article comme checklist. Par exemple : cette bibliothèque est-elle performante ? Cette bibliothèque répond-elle aux normes de mon entreprise en matière d'accessibilité Web ?

Il existe d'autres aspects des bibliothèques et des frameworks que vous pourriez envisager, et qui n'ont pas été abordés en détail dans cet article :

Extensibilité : est-il facile d'étendre la bibliothèque avec une logique et/ou un comportement personnalisés ?
Outils : le cas échéant, la bibliothèque dispose-t-elle d'outils tels que des plug-ins d'éditeur de code, des outils de débogage et des plug-ins de système de compilation ?
Architecture : un code propre est important, mais l'architecture globale de la bibliothèque est-elle pertinente ?
Tests : le projet dispose-t-il d'une suite de tests ? Le site Web du projet utilise-t-il des badges ou des indicateurs qui montrent que la suite de tests réussit sur le dernier commit ?
Compatibilité : la bibliothèque fonctionne-t-elle bien avec les autres bibliothèques et/ou frameworks que vous utilisez actuellement ?
Coût : quel est le coût d'un framework ? Est-il Open Source ou disponible à l'achat ?
Métriques de vanité : ce critère doit être placé en bas de votre liste, voire être complètement ignoré. Toutefois, vous pouvez prendre en compte les "votes" du projet, les comptes de réseaux sociaux qui le représentent et/ou le nombre de bugs/problèmes ouverts sur la page du projet.