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 qui s'exécute dans votre navigateur Web. Toutefois, 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 se concentrent sur les différences qualitatives plutôt que sur les différences 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 offerte par le framework peut attirer davantage les futurs employeurs lorsque vous recherchez un emploi.

Pourquoi se familiariser avec les bibliothèques et les frameworks ?

L'utilisation des bibliothèques et des frameworks JavaScript est prolifique sur le Web. Tous les autres sites Web semblent utiliser du code tiers dans ses ressources JavaScript. Le poids de la page Web diminue avec le temps, ce qui affecte les internautes. JavaScript est un facteur important pour 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êter d'utiliser les frameworks JavaScript", car ils présentent un grand intérêt pour les développeurs. Entre autres avantages, les frameworks peuvent vous aider à coder efficacement et à fournir rapidement des fonctionnalités. Au lieu de cela, vous devez vous éduquer afin de pouvoir prendre une décision éclairée le moment venu.

« Dois-je utiliser une bibliothèque ou un framework aujourd’hui ? » est une question peu courante à vous poser. 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 disposez de connaissances sur les deux, plus vous avez de chances de prendre des décisions éclairées concernant leur utilisation.

Exemples de bibliothèques et de frameworks

Vous remarquerez peut-être du code tiers sous d'autres noms, tels que widgets, plugins, polyfills ou packages. Cependant, ils appartiennent tous généralement à la catégorie d’une bibliothèque ou d’un framework. 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.
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 offrent un champ de fonctionnalités restreint. Si vous transmettez une entrée à une méthode et recevez une sortie, vous avez probablement utilisé une bibliothèque.

Examinez cet exemple de 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. C'est très magique, pas besoin:

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 sont généralement plus volumineux que les bibliothèques et contribuent davantage au poids global des pages. En fait, un framework peut inclure une bibliothèque.

Cet exemple présente un framework simple sans bibliothèque qui 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 extrait dans sa propre API bien définie.
Les développeurs n'ont pas un contrôle total sur le mode et le moment des opérations. Par exemple, le mode et le moment où Vue écrit la chaîne 'Hello, world' sur la page est extrait.
L'instanciation de la classe Vue comporte certains effets secondaires, courants lorsque vous utilisez des frameworks, tandis qu'une bibliothèque peut proposer des fonctions pures.
Le framework recommande un système de modèles HTML spécifique plutôt que votre propre système.
Si vous lisez davantage la documentation sur le framework Vue ou la plupart des autres documentations liées au framework, vous verrez comment les frameworks prescrivent des modèles architecturaux que vous pouvez utiliser. Les frameworks JavaScript vous déchargent de la charge cognitive, car vous n'avez pas à vous en soucier.

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

Après avoir lu les comparaisons entre les bibliothèques et les frameworks, vous comprendrez peut-être quand utiliser l'un ou l'autre:

Un framework peut réduire la complexité pour vous, en tant que développeur. Comme nous l'avons vu, un framework peut éliminer la logique, le comportement, voire les modèles architecturaux. Elle est particulièrement utile lorsque vous commencez un nouveau projet. Une bibliothèque peut aider à réduire la complexité, mais elle se concentre généralement sur la réutilisation du code.
Les auteurs de frameworks veulent que vous soyez productif. Ils développent souvent des outils supplémentaires, des logiciels de débogage et des guides complets, entre autres ressources, pour vous aider à utiliser efficacement un framework. Les auteurs de bibliothèques veulent également que vous soyez productif, mais les outils spécialisés sont rares.
La plupart des frameworks offrent un point de départ fonctionnel, tel qu'un squelette ou un code récurrent, 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 ajoutent une certaine complexité à 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 cadre car ce sont des éléments différents qui effectuent des tâches différentes. Cependant, plus vous avez de connaissances sur les deux, plus vous serez en mesure de décider ce qui vous convient le mieux. La décision d'utiliser un framework ou une bibliothèque dépend de vos besoins.

Interchangeabilité

Vous ne changerez pas de bibliothèque ni de framework chaque semaine. Cependant, il est recommandé de comprendre les inconvénients d’un package qui vous bloque dans son écosystème. Il est également recommandé de comprendre que le développeur qui décide d'utiliser un package tiers est en quelque sorte 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 package. Vous pouvez être amené à changer de 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 traité.
Vous découvrez une nouvelle solution qui répond mieux à vos besoins.
Les exigences relatives au produit changent et le package n'est plus nécessaire.

Prenons 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 @package/set-color tiers dans trois fichiers distincts. Si vous travaillez sur ce code et devez remplacer le package tiers, vous devez mettre à jour le code en trois endroits.

Vous pouvez également simplifier la maintenance et éliminer l'utilisation de la bibliothèque en un seul endroit, comme vous pouvez le voir 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 supprimée. Ainsi, si vous devez remplacer le package tiers, vous ne mettrez à 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 couleurs par défaut.

Simplicité d'utilisation

Un framework peut avoir une API complexe, mais le framework peut offrir des outils pour les développeurs qui le rendent plus facile à utiliser dans son ensemble. La facilité d'utilisation repose sur de nombreux facteurs et peut être très subjectif. Un framework peut être difficile à utiliser pour les raisons suivantes:

Le framework comporte une API complexe par nature.
Le cadre 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 cadres peuvent atténuer ces problèmes grâce à des bonnes pratiques courantes, telles que:

Le framework fournit 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 des documents, des guides, des tutoriels et des vidéos sans frais. Une fois que vous avez consulté 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 appris ces conventions précédemment et vous maîtrisez mieux les styles de codage.

Bien que ces points soient communément attribués à des frameworks, ils peuvent également être attribués aux bibliothèques. Par exemple, la bibliothèque JavaScript D3.js est puissante et bénéficie d'un vaste écosystème qui propose, entre autres, des ateliers, des guides et de la documentation. Toutes ces ressources contribuent à 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, à quelques exceptions près. Les performances Web représentent un domaine gigantesque avec de nombreux sujets. Ces sections traitent donc de deux sujets importants: le tree shaking et les mises à jour logicielles.

Tremblements d'arbres

Le regroupement ne représente qu'un aspect des performances Web, mais il a un effet important sur les performances, en particulier avec les bibliothèques plus volumineuses. L'utilisation de tree shaking (tremblement d'arborescence) lors de l'importation et de l'exportation améliore les performances, car elle détecte et élimine le code inutile pour l'application.

Lorsque vous regroupez du code JavaScript, il existe une étape utile appelée "tree shaking", qui s'avère très utile pour optimiser les performances de votre code. Toutefois, cette étape est plus facile à réaliser avec des bibliothèques qu'avec des frameworks.

Lorsque vous importez du code tiers dans votre code source, vous l'intégrez 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, considérez 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 naïf peut exporter le code avec la sortie suivante:

// 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 tout de même incluse dans le bundle final. Un tel code inutile augmente la taille de 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 du tree shaking élimine le code mort et génère le résultat suivant:

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

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

Notez que le code est plus court et plus succinct. Dans cet exemple, l'amélioration des performances est négligeable, mais dans une application réelle où la bibliothèque comporte des milliers de lignes, l'effet sur les performances peut être beaucoup plus important. Il est intéressant de noter que les outils modernes pour les lots, tels que Parcel, Webpack et Rollup, vont encore plus loin, car ils combinent la minimisation et le tree shaking pour créer un bundle très optimisé. Pour démontrer l'efficacité des outils de lot, 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 a exporté ce module unique:

console.log(7+10);

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

Le regroupement ne représente qu'un aspect des performances Web, mais il a un effet important sur les performances, en particulier avec les bibliothèques plus volumineuses. Le tremblement d'arborescence est généralement plus simple avec les bibliothèques qu'avec les frameworks.

Mises à jour logicielles

Pour de nombreux frameworks et bibliothèques, les mises à jour logicielles ajoutent des fonctionnalités, corrigent des bugs et, à terme, augmentent leur taille au fil du temps. Il n'est pas toujours nécessaire de télécharger les mises à jour. Toutefois, si les mises à jour incluent des corrections de bugs, des améliorations de fonctionnalités souhaitées ou des correctifs de sécurité, elles doivent probablement être mises à jour. Toutefois, plus vous envoyez de données sur le réseau, moins votre application sera performante et plus l'impact sur les performances de l'expérience utilisateur sera important.

Si une bibliothèque s'agrandit, vous pouvez utiliser le tremblement d'arbre pour limiter la croissance. Vous pouvez également utiliser une alternative plus petite à la bibliothèque JavaScript. Pour en savoir plus, consultez la section Interchangeabilité.

Si un cadre augmente en taille, non seulement il est plus difficile de secouer l'arbre, mais il peut aussi être plus difficile de remplacer un cadre par un autre. Pour en savoir plus, consultez la section Interchangeabilité.

Effort à l'emploi

C'est un peu secret : de nombreuses entreprises ont des exigences strictes pour les développeurs qui connaissent un framework particulier. Ils peuvent ignorer votre connaissance des principes de base du Web et se concentrer uniquement sur votre connaissance spécifique d'un certain framework JavaScript. À tort ou à raison, c'est la réalité pour de nombreux emplois.

La connaissance de quelques bibliothèques JavaScript ne nuira pas à votre candidature, mais il y a peu de chances que cela vous différencie. Si vous connaissez très bien quelques frameworks JavaScript populaires, il y a de fortes chances que les employeurs considèrent que ces connaissances sont favorables 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 désespérer des candidats qui sont à l'aise avec de tels frameworks.

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

N'oubliez pas que si vous passez beaucoup de temps dans votre carrière avec un seul cadre, vous risquez de passer à côté d'expériences d'apprentissage avec d'autres cadres plus modernes.
Prenons l'exemple d'un développeur qui ne comprend pas parfaitement le développement de logiciels ou les principes fondamentaux du développement Web, mais qui est embauché en tant que développeur de framework. Ce développeur n'écrivant pas de code efficace, et travailler sur un codebase de ce type peut vous intimider. Dans certains cas, ce scénario peut entraîner un surmenage. Par exemple, vous devrez peut-être refactoriser le code ou l'ajuster aux performances, car il est lent.
Lorsque vous étudiez le développement Web, la meilleure façon de commencer est de vous concentrer sur les principes de base du développement Web, du développement de logiciels et de l'ingénierie logicielle. Une base aussi solide vous permet d'assimiler n'importe quel framework JavaScript rapidement et efficacement.

Conclusion

Bravo pour votre persévérance de compréhension des frameworks et des bibliothèques JavaScript. Vous ne choisirez pas souvent des frameworks ou des bibliothèques, sauf si vous travaillez sur des projets innovants ou en tant que consultant. Cependant, lorsque de telles décisions sont prises, plus vous avez de connaissances sur le sujet, mieux votre décision sera éclairée.

Comme vous l'avez appris, le choix du framework que vous choisissez (et, dans certains cas, le choix de la bibliothèque) peuvent avoir un impact significatif sur votre expérience de développement et vos utilisateurs finaux, par exemple en termes de performances.