Lorsque l'on parle de dépendances , les deux termes peuvent être utilisés, parfois de manière (dangereuse) interchangeable. React est- il un framework ou une bibliothèque ? Qu'en est-il de Bootstrap ou de Lodash ? Les deux sont des « forfaits » après tout, n'est-ce pas ?

Bien sûr, mais ils n'ont certainement pas le même impact sur votre application.

Bibliothèques

Une bibliothèque ("bibliothèque" en français, mais la plupart des français disent "librairie" qui signifie en fait "librairie" en français, mais correspond à la prononciation anglaise de "library") est un ensemble de fonctions à usage général (comme underscore.js ) ou spécialisés (comme moment.js ).

Vous appelez les fonctions de la bibliothèque chaque fois que vous en avez besoin, comme vous choisissez des outils dans une boîte à outils. Ils ne nécessitent aucune modification de la conception de votre logiciel .

Appels propriétaires

En tant que dépendance, cependant, ils vous obligent à appeler leur API propriétaire, "verrouillant" ainsi votre code avec eux (ou même éventuellement une version de ceux-ci), de sorte qu'un appel à la bibliothèque devrait plutôt ressembler à ceci :

Un tel verrouillage augmentera avec le nombre d'appels que vous émettez : plus vous appelez la bibliothèque, plus votre code en dépend (ou une version de celle-ci) :

Point de dépendance unique

Cependant, pour limiter une telle dépendance, vous pouvez la cacher derrière un wrapper :

Un tel emballage peut en fait servir à plus d'un but. En plus de réduire le verrouillage à un seul point dans votre base de code, cela vous permet d' exposer votre propre API aux appelants. Une telle adaptation de la bibliothèque ne comportera que l'API qui a du sens pour votre application, ainsi que les types d'E/S qui ne sont pas spécifiques à votre application, pas à la bibliothèque.

Cependant, en termes d'implémentation, étape par étape, votre code dépend toujours de celui de la bibliothèque.

API métier

Espérons que, comme le disait feu David J. Wheeler :

Tous les problèmes en informatique peuvent être résolus par un autre niveau d' indirection .

En effet, vous pouvez éviter une telle dépendance en ajoutant une interface :

• les appelants dépendront de cette déclaration d'API ;
• l'adaptateur devra l'implémenter (notez que cela faciliterait également les bibliothèques moqueuses lors des tests).

Cadres

Les frameworks ("quadriciels" en français officiel, mais tout le monde dit "framework") sont différents, car ils fournissent un type de service différent : ils proposent de gérer les choses pour vous, au lieu de vous laisser concevoir quoi faire.

Passer le contrôle

Pour ce faire, ils implémentent le backbone (le "frame") d'une application, et vous permettent de remplir les blancs. Mais ces blancs sont laissés à des endroits définis et ont des formes définies.

Cela signifie que:

• l'appli commence par le cadre : il faut remettre le volant.
• puisque le framework pilote l'application, vous n'êtes plus celui qui passe les appels : à la place, vous serez rappelé par le framework le cas échéant.

Contrats

Bien sûr, rien ne vous empêche d'appeler manuellement votre propre code, une bibliothèque tierce ou même une API de framework, mais à vos risques et périls . Cela peut ou non fonctionner comme prévu. Les frameworks ont des règles que vous êtes censé suivre et, si vous les enfreignez, le framework ne pourra être tenu responsable de tout échec.

Typiquement un framework vous permettra d'écrire des composants qui s'intégreront dans leurs conteneurs grâce à la mise en place d'un contrat :

Le conteneur pourra alors gérer votre code comme un logiciel compatible avec le framework dont le cycle de vie peut être géré, et vous rappellera aux moments pertinents pour effectuer une opération ou une autre.

Comme vous pouvez le constater, il s'agit d'un choix beaucoup plus structurel que les bibliothèques pour la conception de votre application : tous vos composants deviennent spécifiques à ce framework. Le ne sera pas portable (c'est-à-dire non compris par un autre framework) ni interopérable (c'est-à-dire qu'un composant Angular n'interagira guère avec un composant React).

On peut affirmer, cependant, que le modèle d'adaptateur pourrait être utilisé pour limiter la dépendance au framework, tout comme nous l'avons fait pour limiter la dépendance aux bibliothèques :

Cela peut sembler aussi utile… si la direction de la dépendance était la même. Mais ce n'est pas le cas : les adaptateurs de bibliothèques avaient l'habitude de prendre une forme requise par l'application, alors qu'ici, les adaptateurs de composants ne peuvent prendre que la forme attendue par le framework. De ce fait, le composant applicatif supposé « gratuit » ne peut que mimer le contrat initial (cycle de vie, sémantique, granularité).

À l'intérieur des frameworks, les adaptateurs de composants seraient alors une superposition inutile.

Bibliothèques de framework

Les bibliothèques peuvent également se conformer aux frameworks. Au lieu de fournir une API, ils fournissent des implémentations de composants pour un framework donné.

Au fur et à mesure que les frameworks sont devenus populaires, un certain nombre de bibliothèques de frameworks sont devenues disponibles. Cependant, la plupart d'entre eux concernent des widgets : par exemple, les composants Material Design ont été portés d' Android vers Web Components , Angular , React , Vue et même les frameworks iOS .

Cadres standards

N'importe qui peut imaginer le coût énorme du portage de la même bibliothèque (et de ses versions ultérieures) sur chacun de ces frameworks.

IBM a imaginé une solution à ce sujet : au lieu de porter leur Carbon Design System sur chacun des frameworks passés, actuels et futurs à la mode, ils ont investi dans un portage sur le framework Web Component standard , qui peut être utilisé dans n'importe quel contexte.

Ainsi, non seulement cela permet d'utiliser leurs composants à partir de frameworks :

Mais les mêmes composants peuvent également être utilisés à partir d'une application simple :

Conclusion

Les frameworks et les bibliothèques sont des options tierces très différentes :

• Les frameworks vous fournissent des plans d'application avec des services intégrés, mais appliquent des contrats prédéfinis pour appeler votre code. A ce titre, ils impliquent une forte dépendance .
• Les bibliothèques ne vous aideront pas à concevoir votre application, mais ne peuvent être appelées que lorsque vous en avez besoin. Vous pouvez concevoir une conception qui limite leur dépendance.