Librairie > Framework

Rhâââââââ je sais, on dit "bibliothèque" de code, et pas "librairie". Mais à ce compte-là, on devrait dire "cadriciel", et là je dis : non. 'Faut pas pousser Mémé dans les orties sous prétexte qu'elle aime les fleurs.

En attendant, quel est le sujet ?

Le sujet est que tous les frameworks prétendent faire Papa, Maman et le café, ringardisant les autres par la même occasion :

• Next JS : "The React Framework for the Web"
• Nuxt JS : "The Intuitive Web Framework"
• Vue JS : "The Progressive JavaScript Framework"

Ce "the" est frappant : chacun se définit à l'exclusion des autres. Chose très dommage à mes yeux, tant il est vrai que chaque approche est porteuse d'excellentes idées, singulières, qu'on aimerait pouvoir incorporer à la codebase au travers d'une simple librairie.

Librairie ? Framework ?

C'est vrai, je n'ai pas pris le temps de définir précisément ces termes, mais pour cela je vous renvoie à l'excellent travail de… moi-même (ça va les chevilles), au travers d'un récent article : https://blog.mathieueveillard.com/librairie-vs-framework/. En un mot comme en cent, un framework se définit par l'inversion de contrôle : c'est le framework qui appelle votre code, tandis que c'est votre code qui appelle une librairie.

Ainsi, un framework régit le flux d'exécution d'une application, ce qui explique pourquoi les frameworks sont incompatibles entre eux. Sauf à intervenir sur des périmètres clairement disjoints (exemple : framework Web vs. framework de tests, 2 choses tout à fait compatibles).

Encore une fois, un framework est là pour vous tracer la voie, pour vous permettre d'avancer sans vous demander sans cesse où aller : la direction vous est imposée. Très utile pour mettre le pied à l'étrier à des personnes moins expérimentées et vous permettre de produire rapidement un résultat robuste et de qualité. Cela explique notamment le succès d'AngularJS en entreprise, à une époque (~2010) où personne dans l'industrie du logiciel ne possédait les compétences nécessaires pour mettre en place une Single Page Application.

Mais le corollaire est qu'il est difficile de s'écarter du chemin déjà tracé. À la longue, les développeurs les plus expérimentés peuvent se sentir bridés, voire être contraints de développer des rustines pour pallier les limitations du framework. Raison pour laquelle, à la longue, React a regagné des parts de marché.

Au final, messieurs-dames auteurs de frameworks, plutôt que de prétendre tout faire, plutôt que de nous demander d'abandonner nos outils actuels pour adopter le vôtre, montrez-moi ce que vous faites bien, montrez-moi en quoi vous apportez une réponse distinctive à un problème commun, et là nous pourrons parler. Vos frameworks nous enferment et nous empêchent d'utiliser les bonnes choses que vous apportez. C'est dommage.

Après tout, c'est bien le travail des tech leads, lead developers, architectes techniques et avant cela des développeurs d'identifier les meilleurs outils pour résoudre le problème (business) auquel ils sont confrontés. Ces personnes, parce qu'elles sont au plus près du métier, sont les mieux à même de mettre en place la stack technique la mieux adaptée.