Différence entre framework et librairie
Le framework est ce squelette que vous devez recouvrir de la chair qu'est votre code. C'est ce qui implique qu'un framework comme Angular vous impose - c'est même ce qui fait son intérêt - certaines pratiques (les anglophones disent qu'il est "opinionated") - là où une librairie vous assiste efficacement dans une tache particulière, sans vous contraindre au-delà du problème spécifique qu'elle résoud.
L'avantage du framework est que tout est inclus : vous disposez de la possibilité de créer des modules, des composants, des services, un système de routage ... etc ... . L'inconvénient est qu'il n'est pas possible - en tous cas pas recommandé - d'essayer de le greffer sur une application existante. Vous démarrez dès le début avec un framework, généralement pour créer une SPA (Single Page Application). Alors qu'une librairie peut être adoptée en cours de route. C'est le cas de jQuery par exemple. Une autre librairie plus spécialiée, telle que React, librairie chargée de créer une vue à partir d'un état, est dédiée à une tâche, la fait très bien, mais vous impose de lui adjoindre une librairie complémentaire pour s'attaquer à un autre problème. Par exemple quand il s'agit ensuite de disposer du routage, vous devez ajouter une autre librairie dédiée à cette tâche (react-router par exemple).
Enfin Redux, librairie spécialisée dans la gestion de l'état d'une application (même si Redux est un 3ème type, ni framework ni tout à fait librairie), peut être utilisée avec React, mais aussi avec Angular, Backbone ou du vanilla JavaScipt.
Librairies et frameworks doivent faire des compromis
Il n'y pas de framework idéal, pas plus qu'il n'y a de librairie parfaite. Les créateurs des uns et des autres font des compromis. Toujours. Et ils le savent. Ce sont les utilisateurs les moins nuancés qui n'en n'ont pas conscience. Ceux qui ne s'en rendent pas compte sont ceux qui n'ont pas encore atteint les limites de leur framework ou de la librairie de leur choix. C'est pour cette raison que dans 6 mois ou 1 an, nous passons aux nouveaux frameworks venus. Mais après quelques années d'expérience et quelques frameworks et librairies à son actif, on fini par comprendre qu'on passera au petit suivant par attrait pour la nouveauté, et/ou suite à son adoption grandissante en entreprise ou suite à la demande spécifique d'un client. En bref, vous remarquerez que ce ne sont pas les créateurs de frameworks ou de librairies qui prétendent avoir accédé au Saint Graal : ce sont les "fans".
inscrivez vous à la newsletter de meanjs.fr
Vous n'avez pas besoin de jurer fidélité à une entreprise, un framework ou une librairie
Rien ne vous oblige à choisir un camp. Choisir un framework n'implique pas de le défendre bec et ongle contre les framework concurrents. Aussi, ne vous sentez pas obligé d'être d'accord avec tous les compromis faits par tel framework ou telle librairie. Respectez les utilisateurs d'autres frameworks et librairies. Vous aussi êtes dans l'autre camp de quelqu'un et n'appréciez pas d'être pris de haut en parce que vous utilisez tel framework plutôt que tel autre.
Pour préférer un framework, encore faut-il en connaitre au moins deux ?
Lapalissade ? Et pourtant ... On ne compte plus les articles de blog sur Medium pendant lequel l'auteur va expliquer pourquoi le framework X est bien supérieur aux autres. Et lorsqu'il s'aventure à les comparer, c'est bien souvent en comparant ce qui n'est pas comparable - une librairie comparée à un framework - où en comparant une ancienne version du framework qu'il n'apprécie pas avec son framework ou sa librairie favorite dans sa dernière version bien évidemment. C'est d'autant plus regrettable qu'au fil des versions, les frameworks et librairies s'influencent : ainsi, le concept de virtual DOM a été emprunté par Vue à React par exemple.
Les frameworks et les librairies s'influencent mutellement
Les développeurs talentueux d'une entreprise gardent un oeil sur leurs concurrents. Tout comme les ingénieurs aéronautique d'Airbus connaissent les spécifités de Boeing, les ingénieurs de Google qui développent Angular sont au courant de ce que mijotent les développeurs de Facecebook en charge de React, ou de ce qu'Evan You concocte sur Vue.js.
Autrement dit : inutile de "choisir" un framework et d'ignorer les autres. Si vous avez le temps et l'énergie, faites de la veille sur au moins deux frameworks. Sinon, adoptez un framework mais continuez à lire des articles sur les frameworks concurrents, articles écrits par leurs auteurs, pas par leurs détracteurs excessifs.
Alors, comment choisir un framework ou une librairie front ?
Aucun amateur n'apprend Angular, React ou Vue. Cela demande trop de temps, d'efforts et d'énergie. Contrairement à l'utilisation d'un CMS comme WordPress, qui peut être utilisé par des utilisateurs non professionnels dans le cadre d'un hobby, vous ne rencontrerez pas d'utilisateur d'Angular, React ou Vue amateurs. Autant pousser la logique jusqu'au bout et se faire une idée des débouchés professionnels dans votre secteur géographique : allez sur Indeed et tapez le nom d'une techno et le nom de votre ville ou de la grande ou moyenne ville près de chez vous. Si une techno est pas ou peu présente, à quoi bon l'apprendre maintenant si votre objectif est d'être "employable" rapidement ?
Attirance ou répulsions personnelles
Peut-être que certains points sont rédhibitoires pour vous : certains développeurs ne supportent pas le JSX car cela leur donne l'impression (l'illusion ?) de mélanger du HTML et du JavaScript et passeront leur chemin concernant React. D'autres n'ont pas apprécié de voir Google modifier le framework AngularJS au point d'en faire un nouveau framework, après avoir sué sang et haut à maîtriser la première mouture de ce framework. Il n'y pas de mal à aller voir ailleurs. Ce sera l'occasion de voir comment les mêmes problèmes (création de composants, routage, gestion de l'état ...) sont abordés par d'autres équipes.
A l'inverse, vous pouvez vous sentir immédiatement à l'aise sur une techno et choisir de rester dessus pour cette raison subjective.
Le meilleur gagne-t-il toujours ?
C'est la question qui pollue votre choix plus ou moins consciemment. Maintenant que vous savez qu'il n'y a pas un framework / une libraire idéal(e), sensiblement meilleur(e) que les autres, la crainte de se tromper devrait s'estomper. Y a-t-il des frameworks qui gagneraient à être plus connus ? Aurelia fait sans doute partie de ceux-là. Mais de nouveau, s'il n'y pas d'offres d'emploi ou de missions dans votre secteur, cela vaut-il le coup de lui consacrer temps et efforts ? Oui si :
- vous souhaitez faire partie des (rares) développeurs qui seront alors (relativement) recherchés car peu nombreux et qu'il y a des possiblité d'emploi près de chez vous ou en télé-travail,
- vous pariez (il y a une part de jeu) que la techno en question peut monter
non si :
- vous souhaitez jouer la sécurité et misez sur les deux poids lourds (Angular et React), car pour l'heure, fin 2017, Angular et React restent des valeurs sans risque, qui continueront à permettre de trouver un emploi ou des missions facilement
- vous n'avez pas le temps ou l'énergie de prendre des risques car votre priorité est de faire bouillir la marmitte pour vous et votre famille
Ce ne sont pas les meilleures technos qui percent, ce sont celles qui sont poussées par de grands groupes. Ne serait-ce que parce qu'en cas de dérive d'un projet, un responsable informatique n'aura pas à se justifier d'avoir utilisé une technologie perçue comme "exotique" par son n+1. Les grands groupes ayant les moyens d'attirer les meilleurs développeurs ou de racheter les petits éditeurs, le biais s'en trouve partiellement corrigé. Alternativement, dans le cas de l'open source, ce sont les technologies plébiscitées par la communauté qui s'imposent : ainsi, Vue.js et ses 76000 étoiles sur Github ne disparaîtra pas du jour au lendemain. Mais hors de quelques grandes villes, pour l'instant, la demande en Vue.js est très en deça de celle d'Angular et de React. En 2018, Vue pourrait commencer à se tailler une part de marché significative. Mais on retourne dans le domaine du pari.
Au lieu de perdre du temps à lire des comparatifs : testez
A l'époque où j'étais friand des comparatifs de frameworks - avant de réaliser qu'ils étaient souvent biaisés d'entrée de jeu - j'ai chiffré le temps que je passais par semaine à lire de tels comparatifs : je pouvais arriver à près de 6 heures de lecture par semaine (une demi-heure par ci, 45 minutes par là), soit 24 heures par mois. Cela représentait l'équivalent de 3 journées de travail par mois. Depuis que je consacre ce temps à étudier un framework ou une librairie qui a retenu mon attention en lisant et pratiquant ce que recommandent leurs auteurs, j'ai de biens meilleures données pour me faire une opinion, données de première main. De nouveau, cela représente l'équivalent de 3 jours de travail par mois, soit (en retirant un mois de congés) 33 jours de lecture de comparatifs annuels réinvestis bien plus utilement en lectures de livres écrits par les créateurs des technologies, de visionnage de vidéos tournées lors de meetup, puis de réalisation de POC.
Rendez-vous ce service : apprenez le framework qui paiera à coup sûr et à court terme dès maintenant, en fonction de votre secteur géographique, puis un 2ème une fois que vous vous sentirez à l'aise avec votre framework principal, si le démon de la lecture des comparatifs vous reprenait. Et si c'est pour le fun, il n'y a alors plus de pression, choisissez un framework ou une librairie qui a éveillé votre curiosité, peu importe ce qu'en pensent les autres développeurs. De nouveau, vous aurez l'embarras du choix (Aurelia, Cycle.js, Meteor, Ember.js, Riot.js ... etc ...).