Cette page a été traduite par l'API Cloud Translation.

Différence entre les bibliothèques et les frameworks JavaScript

Umar Hansa

Cet article vous explique les différences entre les frameworks et les bibliothèques dans le contexte d'un environnement JavaScript côté client, qui est le code exécuté dans votre navigateur Web. Cependant, certains des points abordés dans cet article s'appliquent également à d'autres environnements, car les bibliothèques et les frameworks font partie de nombreux domaines de l'ingénierie logicielle, tels que le développement d'applications mobiles natives.

Les discussions de cet article portent sur les différences qualitatives plutôt que quantitatives entre les bibliothèques et les frameworks. Exemple :

Quantitatif:les frameworks respectent généralement le principe d'inversion du contrôle.
Qualitative:l'expérience avec un framework peut plaire davantage aux futurs employeurs lorsque vous recherchez un emploi.

Pourquoi apprendre à connaître les bibliothèques et les frameworks ?

L'utilisation du framework et de la bibliothèque JavaScript est prolifique sur le Web. Tous les autres sites Web semblent utiliser du code tiers dans leurs ressources JavaScript. Le poids des pages Web s'aggrave avec le temps, ce qui affecte les utilisateurs. Le JavaScript est un facteur important de la taille globale de la page. C'est ce même JavaScript qui comprend souvent des bibliothèques et des frameworks tiers.

Il ne suffit pas de dire "Arrêtez d'utiliser les frameworks JavaScript", car les frameworks présentent de nombreux avantages pour les développeurs. Les frameworks peuvent vous aider à coder efficacement et à fournir rapidement des fonctionnalités, entre autres avantages. Vous devez plutôt vous renseigner pour pouvoir prendre une décision éclairée le moment venu.

La question "Devrais-je utiliser une bibliothèque ou un framework ?" est inhabituelle. Les bibliothèques et les frameworks sont deux choses très différentes. Cependant, les bibliothèques et les frameworks sont souvent confondus. Plus vous en savez sur les deux, plus vous êtes susceptible de prendre des décisions éclairées sur leur utilisation.

Exemples de bibliothèques et de frameworks

Vous remarquerez peut-être du code tiers sous d'autres noms, tels que des widgets, des plug-ins, des polyfills ou des packages. Cependant, ils appartiennent généralement à la catégorie d'une bibliothèque ou d'un framework. En gros, la différence entre les deux peut se résumer comme suit :

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

Bibliothèque

Les bibliothèques ont tendance à être plus simples que les frameworks et à offrir un champ d'application limité. Si vous transmettez une entrée à une méthode et que vous recevez une sortie, vous avez probablement utilisé une bibliothèque.

Voici un exemple de la bibliothèque lodash:

import lodash from 'lodash'; // [1]
const result = lodash.capitalize('hello'); // [2]
console.log(result); // Hello

Comme c'est le cas avec de nombreuses bibliothèques, il est pratique de lire ce code et de comprendre ce qu'il fait. Il n'y a pas de magie en jeu:

Une instruction import importe la bibliothèque lodash dans le programme JavaScript.
La méthode capitalize() est appelée.
Un seul argument est transmis à la méthode.
La valeur renvoyée est capturée dans une variable.

Framework

Les frameworks ont tendance à être plus volumineux que les bibliothèques et à contribuer davantage à la taille globale de la page. En fait, un framework peut inclure une bibliothèque.

Cet exemple présente un framework simple sans bibliothèque et utilise Vue, un framework JavaScript populaire:

<!-- index.html -->
<div id="main">
  {{ message }}
</div>

<script type="module">
import Vue from './node_modules/vue/dist/vue.esm.browser.js';

new Vue({
  el: '#main',
  data: {
    message: 'Hello, world'
  }
});
</script>

Si vous comparez cet exemple de framework à l'exemple de bibliothèque précédent, vous remarquerez peut-être les différences suivantes:

Le code du framework englobe plusieurs techniques et les abstrait dans sa propre API orientée.
Les développeurs n'ont pas un contrôle total sur la manière et le moment où les opérations se produisent. Par exemple, vous n'avez pas besoin de savoir comment et quand Vue écrit la chaîne 'Hello, world' sur la page.
L'instanciation de la classe Vue entraîne des effets secondaires, qui sont courants lorsque vous utilisez des frameworks, tandis qu'une bibliothèque peut proposer des fonctions pures.
Le framework prescrit un système de modèles HTML particulier plutôt que d'utiliser le vôtre.
Si vous lisez plus en détail la documentation du framework Vue ou la plupart des autres documents du framework, vous pouvez découvrir comment les frameworks prescrivent des modèles architecturaux que vous pouvez utiliser. Les frameworks JavaScript vous déchargent d'une partie de la charge cognitive, car vous n'avez pas à trouver vous-même ces informations.

Quand utiliser une bibliothèque plutôt qu'un framework

Après avoir lu les comparaisons entre les bibliothèques et les frameworks, vous pouvez commencer à comprendre quand utiliser l'un ou l'autre:

Un framework peut réduire la complexité pour vous, en tant que développeur. Comme indiqué, un framework peut abstraire la logique, le comportement et même les modèles d'architecture. Elle est particulièrement utile lorsque vous commencez un nouveau projet. Une bibliothèque peut contribuer à la complexité, mais se concentre généralement sur la réutilisation du code.
Les auteurs de frameworks souhaitent que vous soyez productif. Ils développent donc souvent des outils supplémentaires, des logiciels de débogage et des guides complets, entre autres ressources, pour vous aider à utiliser un framework efficacement. Les auteurs de bibliothèques souhaitent également que vous soyez productif, mais les outils spécialisés sont rares dans les bibliothèques.
La plupart des frameworks fournissent un point de départ fonctionnel, tel qu'un squelette ou un modèle, pour vous aider à créer rapidement des applications Web. Une bibliothèque fait partie de votre codebase déjà établi.
En général, les frameworks introduisent une certaine complexité dans votre codebase. La complexité n'est pas toujours évidente au départ, mais elle peut se révéler au fil du temps.

Pour rappel, vous ne comparez généralement pas une bibliothèque à un framework, car il s'agit de deux éléments différents qui effectuent des tâches différentes. Toutefois, plus vous en savez sur les deux, plus vous êtes à même de choisir celle qui vous convient le mieux. La décision d'utiliser un framework ou une bibliothèque dépend de vos exigences.

Interchangeabilité

Vous ne changerez pas votre bibliothèque ou votre framework toutes les semaines. Toutefois, il est recommandé de comprendre les inconvénients d'un package qui vous enferme dans son écosystème. Il est également recommandé de comprendre que le développeur qui décide d'utiliser un package tiers est responsable de la création d'un couplage faible entre le package et le code source de l'application.

Un package lié au code source est plus difficile à supprimer et à remplacer par un autre. Vous devrez peut-être échanger un package dans les cas suivants:

Vous devez mettre à jour un package dont la maintenance n'est plus assurée.
Vous découvrez que le package est trop buggé pour être utilisé.
Vous découvrez un nouveau package qui répond mieux à vos besoins.
Les exigences de votre produit changent et le package n’est plus nécessaire.

Considérez l'exemple suivant :

// header.js file
import color from '@package/set-color';
color('header', 'dark');

// article.js file
import color from '@package/set-color';
color('.article-post', 'dark');

// footer.js file
import color from '@package/set-color';
color('.footer-container', 'dark');

L'exemple précédent utilise le package tiers @package/set-color dans trois fichiers distincts. Si vous travaillez sur ce code et que vous devez remplacer le package tiers, vous devez mettre à jour le code à trois endroits.

Vous pouvez également simplifier la maintenance et regrouper l'utilisation de la bibliothèque en un seul endroit, comme illustré dans cet exemple:

// lib/set-color.js file
import color from '@package/set-color';

export default function color(element, theme = 'dark') {
  color(element, theme);
}

// header.js file
import color from './lib/set-color.js';
color('header');

// article.js file
import color from './lib/set-color.js';
color('.article-post');

// footer.js file
import color from './lib/set-color.js';
color('.footer-container');

Dans l'exemple précédent, l'utilisation directe de la bibliothèque est abstraite. Ainsi, si vous devez échanger le package tiers, vous ne mettez à jour qu'un seul fichier. De plus, le code est désormais plus facile à utiliser, car le fichier set-color.js interne définit un thème de couleur par défaut à utiliser.

Simplicité d'utilisation

Un framework peut avoir une API complexe, mais il peut proposer des outils de développement qui le rendent plus facile à utiliser dans l'ensemble. La facilité d'utilisation dépend de nombreux facteurs et peut être très subjective. Un framework peut être difficile à utiliser pour les raisons suivantes:

Le framework possède une API intrinsèquement complexe.
Le framework est mal documenté et nécessite de nombreux essais et erreurs pour résoudre les problèmes.
Le framework utilise des techniques que vous et votre équipe ne connaissez pas.

Les frameworks peuvent atténuer ces défis grâce à des bonnes pratiques courantes, par exemple:

Le framework propose des outils de développement et de diagnostic pour faciliter le débogage.
Le framework dispose d'une communauté active de développeurs qui collaborent sur une documentation sans frais, des guides, des tutoriels et des vidéos. Une fois que vous avez consommé ce contenu, vous êtes productif avec le framework.
Le framework propose une API qui respecte les conventions de codage courantes. Vous êtes productif avec le framework, car vous avez déjà appris ces conventions et que vous connaissez mieux les styles de codage.

Bien que ces points soient généralement attribués aux frameworks, ils peuvent également être attribués aux bibliothèques. Par exemple, la bibliothèque JavaScript D3.js est puissante et dispose d'un vaste écosystème qui propose des ateliers, des guides et de la documentation, entre autres ressources, qui ont tous un impact sur sa facilité d'utilisation.

De plus, un framework prescrit généralement une architecture pour votre application Web, tandis qu'une bibliothèque est généralement compatible avec votre architecture existante, quelle qu'elle soit.

Performances

En général, les frameworks peuvent affecter les performances plus que les bibliothèques, bien qu'il existe des exceptions à ce cas. Les performances Web sont un domaine vaste qui couvre de nombreux sujets. Ces sections abordent donc deux sujets importants: le balayage de l'arborescence et les mises à jour logicielles.

Agitation des arbres

Le regroupement n'est qu'une facette des performances Web, mais il a un impact important sur les performances, en particulier avec les bibliothèques plus volumineuses. L'utilisation du ramassage d'arbres lors de l'importation et de l'exportation améliore les performances, car elle permet de trouver et d'élaguer le code inutile à l'application.

Lorsque vous regroupez du code JavaScript, il existe une étape utile appelée "tree shaking", qui permet d'optimiser les performances de votre code, bien qu'elle soit plus facile à réaliser avec des bibliothèques qu'avec des frameworks.

Lorsque vous importez du code tiers dans votre code source, vous le regroupez généralement dans un ou plusieurs fichiers de sortie. Par exemple, les fichiers header.js, footer.js et sidebar.js sont tous combinés dans le fichier output.js, qui est le fichier de sortie que vous chargez dans votre application Web.

Pour mieux comprendre le tremblement d'arbre, vous pouvez étudier ces exemples de code:

// library.js file
export function add(a, b) {
  return a + b;
}

export function subtract(a, b) {
  return a - b;
}

// main.js file
import {add} from './library.js';

console.log(add(7, 10));

À des fins de démonstration, l'exemple de code library.js est volontairement réduit par rapport à ce que vous pourriez trouver dans le monde réel, où la bibliothèque peut comporter des milliers de lignes.

Un processus de bundle simple peut exporter le code avec le résultat suivant:

// output.js file
function add(a, b) {
  return a + b;
}

function subtract(a, b) {
  return a - b;
}

console.log(add(7, 10));

Même si la fonction subtract() n'est pas nécessaire dans cette application, elle est toujours incluse dans le bundle final. Ce code inutile augmente la taille du téléchargement, le temps d'analyse et de compilation, ainsi que les coûts d'exécution que vos utilisateurs doivent payer. Une approche de base d'élagage d'arbres supprime le code mort et produit cette sortie:

// output.js file
function add(a, b) {
  return a + b;
}

console.log(add(7, 10));

Notez que le code est plus court et plus concis. Dans cet exemple, l'amélioration des performances est négligeable, mais dans une application réelle où la bibliothèque contient des milliers de lignes, l'effet sur les performances peut être beaucoup plus important. Il est intéressant de noter que les outils de bundle modernes, tels que Parcel, Webpack et Rollup, vont encore plus loin, car ils combinent la minimisation et le tremblement d'arborescence pour créer un bundle hautement optimisé. Pour démontrer l'efficacité des outils de bundle, nous avons utilisé Parcel pour créer un fichier de bundle avec les exemples de code précédents. Parcel a supprimé tout le code inutilisé et exporté ce seul module:

console.log(7+10);

Parcel est suffisamment intelligent pour supprimer les instructions d'importation, les définitions de fonction et le comportement, entre autres éléments, afin de créer un code hautement optimisé.

Le regroupement n'est qu'un aspect des performances Web, mais il a un impact important sur les performances, en particulier avec les bibliothèques plus volumineuses. Le tree shaking est généralement plus simple à effectuer avec les bibliothèques qu'avec les frameworks.

Mises à jour logicielles

Pour de nombreux frameworks et bibliothèques, les mises à jour logicielles permettent d'ajouter des fonctionnalités, de corriger des bugs et, au final, d'augmenter leur taille au fil du temps. Il n'est pas toujours nécessaire de télécharger les mises à jour, mais si les mises à jour incluent des corrections de bugs, des améliorations de fonctionnalités ou des correctifs de sécurité, nous vous recommandons d'effectuer une mise à jour. Toutefois, plus vous envoyez de données via le réseau, moins votre application est performante et plus l'impact sur l'expérience utilisateur est important.

Si la taille d'une bibliothèque augmente, vous pouvez utiliser les secousses d'arbres pour atténuer la croissance. Vous pouvez également utiliser une alternative plus petite à la bibliothèque JavaScript. Pour en savoir plus, consultez la section Échangeabilité.

Si la taille d'un framework augmente, le débranchement d'arbres devient plus difficile, mais il peut aussi être plus difficile de remplacer un framework par un autre. Pour en savoir plus, consultez la section Échangeabilité.

Employabilité

De nombreuses entreprises ont des exigences strictes pour les développeurs qui connaissent un framework particulier. Il est possible qu'il ne tienne pas compte de vos connaissances de base sur le Web et qu'il ne s'intéresse qu'à vos connaissances spécifiques d'un certain framework JavaScript. Qu'il s'agisse d'une bonne ou d'une mauvaise chose, c'est la réalité de nombreux emplois.

La connaissance de quelques bibliothèques JavaScript ne nuira pas à votre candidature, mais il est peu probable qu'elle vous permette de vous démarquer. Si vous maîtrisez parfaitement certains frameworks JavaScript populaires, il est probable que les employeurs voient ces connaissances comme un atout sur le marché du travail actuel des développeurs Web. Certaines grandes entreprises sont coincées avec des frameworks JavaScript très anciens et peuvent même être désespérées pour des candidats qui ne maîtrisent pas ces frameworks.

Vous pouvez utiliser ce secret ouvert à votre avantage. Toutefois, abordez le marché du travail avec prudence et en tenant compte des points suivants:

N'oubliez pas que si vous passez une grande partie de votre carrière avec un seul framework, vous risquez de manquer d'expériences d'apprentissage avec d'autres frameworks plus modernes.
Imaginons un développeur qui ne maîtrise pas parfaitement les principes de base du développement logiciel ou du développement Web, mais qui est embauché en tant que développeur de framework. Ce développeur n'écrit pas de code efficace, et vous pourriez trouver intimidant ou accablant de travailler sur un tel codebase. Dans certains cas, ce scénario peut entraîner un surmenage. Par exemple, vous devrez peut-être refactoriser le code ou l'optimiser pour les performances s'il est lent.
Lorsque vous apprenez le développement Web, le meilleur moyen est de commencer par vous concentrer sur les principes fondamentaux du développement Web, du développement logiciel et de l'ingénierie logicielle. Une base aussi solide vous permet de maîtriser rapidement et efficacement n'importe quel framework JavaScript.

Conclusion

Bravo pour vos efforts pour comprendre les différences entre les frameworks JavaScript et les bibliothèques. Vous ne choisirez pas souvent de frameworks ou de bibliothèques, sauf si vous travaillez sur des projets greenfield ou en tant que consultant. Cependant, lorsque de telles décisions se produisent, plus vous avez de connaissances sur le sujet, plus votre décision est éclairée.

Comme vous l'avez appris, le choix du framework que vous choisissez et, dans certains cas, du choix de la bibliothèque peut avoir une incidence significative sur votre expérience de développement et les utilisateurs finaux, par exemple sur les performances.