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

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. 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 d'ingénierie logicielle, comme 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 ?

Les bibliothèques et frameworks JavaScript sont largement utilisés sur le Web. Tous les autres sites Web semblent utiliser du code tiers dans leurs ressources JavaScript. La charge 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 pouvez remarquer 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:

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 pour de nombreuses bibliothèques, il est pratique de lire ce code et de comprendre son fonctionnement. Il n'y a pas de magie en jeu:

  1. Une instruction import importe la bibliothèque lodash dans le programme JavaScript.
  2. La méthode capitalize() est appelée.
  3. Un seul argument est transmis à la méthode.
  4. 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 montre 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 consultez la documentation du framework Vue ou la plupart des autres documentations de framework, vous pouvez voir comment les frameworks prescrivent des modèles d'architecture 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, le développeur. Comme indiqué, un framework peut éliminer 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 aider à gérer la complexité, mais elle 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 en définitive 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 en partie responsable de la création d'un couplage lâche 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 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.
  • Vos exigences concernant les produits ont changé 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 remplacer 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 qui vous sont inconnues, à vous et à votre équipe.

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 des documentations, guides, tutoriels et vidéos sans frais. 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 règle générale, les frameworks peuvent affecter les performances plus que les bibliothèques, bien qu'il existe des exceptions. 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, vous pouvez effectuer une étape utile appelée "tree shaking", qui est une optimisation des performances de votre code. Toutefois, cette opération est 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 balayage d'arbre, prenons 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 regroupement simple peut exporter le code avec cette sortie:

// 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'arbre 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 compte des milliers de lignes, l'effet sur les performances peut être beaucoup plus important. Fait intéressant, les outils de bundle modernes, tels que Parcel, Webpack et Rollup, vont plus loin, car ils combinent la minification et le tree shaking 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'une facette 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 nombreuses bibliothèques et frameworks, les mises à jour logicielles ajoutent des fonctionnalités, corrigent des bugs et augmentent leur taille au fil du temps. Il n'est pas toujours nécessaire de télécharger les mises à jour, mais si elles incluent des corrections de bugs, des améliorations de fonctionnalités souhaitées ou des correctifs de sécurité, vous devriez probablement les installer. 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 le tree shaking pour limiter cette 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é

Il est un peu de notoriété publique que 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 bloquées avec de très anciens frameworks JavaScript et peuvent même être désespérées à la recherche de candidats qui maîtrisent ces frameworks.

Vous pouvez utiliser cet open secret à 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 bien 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

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

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