Salut et bienvenue dans ce nouvel épisode de Code Garage.
Je m'appelle Nicolas Brondembearnard et aujourd'hui, on va se poser une grande question,
ou plutôt on va répondre à cette question.
Et c'est, quelle est la différence entre une bibliothèque et un framework ?
Ça, c'est une question qui est hyper intéressante parce que,
même quand on la pose à des développeurs junior, ou des développeuses junior, senior, confirmés,
on a souvent des réponses très différentes et on a très peu souvent une bonne réponse,
et une réponse, on va dire, techniquement correcte.
Donc aujourd'hui, on va parler de ce sujet-là.
Et comme ça, que ce soit un entretien ou en discussion,
eh ben, ça vous donnera une occasion de répondre avec des arguments.
Donc souvent, quand on pose cette question-là, c'est quoi la différence entre un framework et une ébrérie ?
On a le droit à un ensemble de réponses un peu tentés au hasard ou tentés avec des bouts d'explication.
Ça peut être, c'est la même chose, on utilise les deux mots, ils sont un peu synonymes.
Ou alors, framework, c'est l'anglais pour bibliothèque.
On peut dire, il y a une différence de taille, le framework est beaucoup plus gros et la l'ébrérie est souvent plus petite.
Ou même, parfois, on a un framework, c'est un ensemble de bibliothèques qui fonctionnent ensemble.
Alors, on pourrait presque croire que la définition exacte se cache un petit peu là-dedans,
ou peut-être que ce serait un mix de ces réponses-là.
Et en fait, eh ben, c'est pas le cas.
Il y a une vraie réponse, une vraie réponse technique, mais vous allez voir qu'elle est un petit peu subtile.
Donc, si je vous en fais une version simple et courte de cette réponse,
c'est simplement qu'une bibliothèque, on va l'utiliser et on va l'appeler dans notre code.
Alors que le framework, c'est lui qui va appeler notre code.
J'espère que vous avez bien la subtilité.
En gros, on peut dire que leur fonctionnement, il est un petit peu inverse l'un de l'autre.
C'est-à-dire qu'on va, si on prend un système de dépendance,
en fait, on va inclure une bibliothèque en tant que dépendance de notre code et on va l'appeler.
Alors que le framework, il va plutôt s'exécuter et appeler notre code logique et notre code métier à nous
pour l'exécuter de la manière dont il est prévu pour le faire.
En français, on traduit le mot framework par un cadre applicatif.
Parce que c'est son but.
Il donne un cadre, il donne une organisation, un squelette, une méthode de travail.
La librairie, ou plutôt la bibliothèque de son côté, elle, elle offre des fonctionnalités
qui sont souvent décorée les unes des autres et elle offre pas spécifiquement de cadre de travail.
Là où il faut faire attention, c'est que même si cette définition, elle est techniquement valide
et c'est techniquement celle qu'on voudrait retenir,
eh ben le mot framework, il est plus attractif et il est synonyme de sérieux.
Il est synonyme un petit peu d'un côté marketing.
Et aujourd'hui, tous les outils se déclarent comme étant des frameworks,
même si leur fonctionnement en vrai ressemble plutôt à celui d'une bibliothèque dans la plupart des cas.
On a par exemple le cas de React, qui est considéré comme un framework.
Il a effectivement tout d'un framework, il l'offre un cadre applicatif.
Et pourtant, techniquement, c'est une librairie.
Parce que ça va être à nous d'instancier cette librairie-là et d'appeler manuellement la fonction render de React.
C'est pareil d'ailleurs pour vue et c'est pareil à l'époque d'Angular.js.
Maintenant, Angular a changé.
Donc effectivement, si on prend cette définition-là,
eh ben on va voir que souvent, il y a des vrais frameworks au sens technique du terme qui sont basés sur ces librairies.
Par exemple, pour React, on a Next.js.
Pour vue.js, on a Nuxt.js.
Pour Express, on a Nest.js.
Et pour Angular.js, on avait par exemple Ionic.
Angular maintenant s'est devenu effectivement un framework,
mais à l'époque de la 1.5 et avant, c'était une librairie.
Ça fonctionnait comme une librairie.
Pourtant, si vous allez sur la page d'accueil de chacune des librairies que j'ai citées,
eh ben vous verrez qu'ils se vendent chacun comme étant des frameworks.
Mais comme je l'ai dit, ça c'est un côté marketing à la chose.
Maintenant, est-ce que c'est vraiment grave de les citer en framework ?
Non, absolument pas.
Parce qu'effectivement, le côté technique en disant,
c'est nous qui appelons le code de la librairie.
Eh ben c'est vrai pour React, c'est vrai pour vue.
Mais il y a quand même de bonnes parties,
où c'est le cycle de vie des composants,
ou des choses comme ça, qui vont appeler notre code logique à nous.
Donc en fait, en réalité, c'est vraiment ok de dire que ce sont des frameworks.
Mais si jamais vous voulez creuser un petit peu le sujet et avoir plus de détails,
je vous mets un article dans les notes de l'épisode,
qui est sur le site de O'Reilly, donc un gros éditeur de livres notamment technique,
et qui explique exactement pourquoi React est une librairie.
Alors c'est en anglais, mais l'article est vraiment très intéressant,
et je vous conseille de lire.
Sur ce, je vous souhaite de passer une bonne journée,
une bonne semaine, et je vous dis à très vite pour un prochain épisode de Code Garage. Salut !