Mais pourquoi devrais-je abandonner jQuery pour Angular, React... ou Vue.js !?

J'ai longtemps utilisé jQuery. Puis Vanilla JS comme on appelle si élégamment le JavaScript implémenté nativement. Je surveillais d'un œil les Knockout et compagnie sans jamais réellement m'y investir. Ce fut également le cas avec AngularJS, tellement super-héroïque et sur toutes les lèvres ! Du MVVM paraissait t-il. Un nom barbare à se retaper alors que je terminais tout juste de comprendre en profondeur les tenants et aboutissants d'une architecture MVC(2). Non merci.

Autant vous le dire : pour ma part je ne jurais que par la séparation des rôles. Je ne voulais pas retourner à du HTML mélangeant de la structure et du comportement, avec des attributs invalides W3C et un code source à chialer. Ça m'a bien conforté dans l'idée que jQuery ou Vanilla JS restaient des valeurs sûr !

Mais voilà. J'ai fini par investiguer ce AngularJS, à force de le voir passer. Il s'est avéré que les principaux défauts que je lui trouvais pouvaient se régler avec un peu de rigueur. OK ? Mais à quoi bon tant d'efforts pour utiliser l'outil à la mode, là où jQuery à toujours fait le job ?

Même si j'ai partiellement compris l'utilité d'un tel changement grâce à mes études de surface sur Aurelia, React puis Angular, il semble que j'ai trouvé la réponse définitive à la bonne raison d'abandonner jQuery grâce à l'étude de Vue.js. Et en une simple après midi de lecture ! Je ne jure plus que par cette bibliothèque à présent !

Pour faire simple : jQuery pilote par le DOM, là où Vue pilote par les données ! Et ça, ça change tout.

Au commencement, il y avait jQuery

J'ai réellement adoré jQuery ! C'est grâce à cette bibliothèque JavaScript que je suis aujourd'hui un développeur full-stack JavaScript passionné. Si on remonte à l'époque ou je développais des sites web pour le plaisir en total amateur, je ne jurais que par jQuery parmi mes fichiers PHP et mes appels $.ajax. Pourtant, j'ai délaissé PHP qui commençait à se parer d'une syntaxe objet sérieuse au profit d'une spécialisation plus front-end. J'étais fasciné par la souplesse de jQuery.

Comment était t-il possible que jQuery soit fait... en JavaScript ?! Mon seul rapport au JavaScript à l'époque c'était des scripts « taxés » sur le site Éditeur JavaScript. Ils étaient mis à ma sauce avec des heures de « bidouilles » pour éviter les différentes erreurs entres navigateurs. Fatiguant. Le JavaScript était définitivement un langage « dégueulasse » que je détestais. Mais ce jQuery était simple, élégant, rapide à écrire, simple, séparé du HTML, avec des milliers de plugins, etc. Et, je ne sais pas si je l'ai dit, mais simple aussi.

Avec HTML pour la structure, CSS pour l'habillage, et jQuery pour l’interaction, j'avais trouvé là un fabuleux moyen de développer en séparant les différents rôles sans jamais faire de mélange afin, qu'avec un même HTML je puisse sortir des interfaces complètement différentes.

Bien sur, pour me tenir à niveau côté back-end, j'ai étudié la programmation orienté objet avec Java (à l'école) et C# (en entreprise). Ce sont des langages que j'ai respecté pour leurs rigueur, complexité, et la philosophie objet de mise en œuvre qu'ils portaient. Mais jQuery était bien trop évolutif, versatile, élégant et simple pour ne pas rester mon chouchou. Si je devais faire quelque chose de solide, je le pouvais. Mais contrairement aux langages back-end étudiés ses dernières années, pour quelque chose de simple, jQuery répondait également présent !

jQuery était devenu tellement confortable, qu'il était difficile de s'en détacher, et même d'imaginer que d'autres bibliothèques puissent faire mieux.

Mais cette question me chagrinait toujours... Comment une bibliothèque qui m'avait définitivement détournée de PHP, puis C# et Java pouvait avoir été développée... en JavaScript. Ce langage que je détestais !

Le JavaScript, c'est pas automatique !

J'ai donc retroussé mes manches pour réellement comprendre les fondamentaux du JavaScript. Je dirais que la clé de mon côté a été de comprendre toute la portée du caractère asynchrone de ce langage et la possibilité de... passer des fonctions en paramètre ?! WTF. Je fais quelque chose, et je passe également la fonction qui devra être appelée quand ce quelque chose sera fini, indépendamment du temps que ce quelque chose va prendre. Incroyable, ce n'était donc pas jQuery qui avait « inventé » ça. En fait, ce mécanisme était possible grâce aux fermetures et le fait que les fonctions puissent se passer elles-mêmes dans des fonctions venait du fait que les fonctions étaient... des objets ?! Et ce pauvre langage souffrant de ne pas être typé, sans possibilité de caster les valeurs était en fait typé faiblement et utilisait la coercition pour « automatiquement » changer de type au besoin...

Le JavaScript était définitivement plus intéressant qu'au premier abord et mélangeait énormément de concepts étudiés dans tous les précédents langages que j'avais pu étudier. Enfin, en étudiant l'API DOM native implémentée dans tous les navigateurs récents, j'en suis même venu à la conclusion qu'il était temps de dire au revoir à jQuery. Cette trousse à outil fabuleuse n'était en réalité qu'un tremplin pour aborder le JavaScript sous le bon angle et plus facilement. Il suffisait simplement d'en avoir le courage.

J'ai donc ouvert les bras à Vanilla JS, et me suis dès lors convaincu que du JavaScript natif, avec de petites bibliothèques et polyfills utilisées avec parcimonie étaient la clé de mon salut.

Autant vous dire qu'à cette époque, avec une telle révélation, c'était mal parti pour que je me lance dans AngularJS !

AngularJS, Node.js, React, Angular... tous dans le même panier ?

Le back-end me manquait ! Je dépendais de mes collègues experts en C# pour mener à bien un site complet. Mes petites excursions avec CodeIgniter ou Laravel pour refaire un peu de PHP m'ont vraiment fait comprendre à quel point la « magie » JavaScript manquait aux autres langages. Mais il paraissait qu'on pouvait faire du JavaScript... côté serveur o_O !? Alors là, il ne m'en fallait pas plus pour sauter sur Node.js alors que celui ci n'affichait encore qu'une version 0.1x.x ! Obligé de nager parmi les différentes ressources attribuées aux différentes versions que je trouvais, il a été difficile au départ de distinguer ce qui appartenait réellement au cœur de Node.js et à ces packages npm comme Express ou encore même aux middlewares d'Express en lui-même.

La courbe d'apprentissage, même si elle n'a pas été si compliquée avec mon background JavaScript m'a fait pensé qu'il fallait un petit coup de pousse à Node.js pour permettre aux développeurs front-end « coincés » avec jQuery ou aux développeurs back-end PHP se méfiant de JavaScript de se lancer. C'est pourquoi j'ai développé le framework NodeAtlas qui, contrairement à ses concurrents se voulait évolutif dans sa prise en main par itération progressive et très proche d'une architecture PHP dans son approche. Bien entendu, en creusant le framework au fur et à mesure de ses besoin, il est possible d'embrasser pleinement Node.js et ses modules. Il est possible d'obtenir un site multilingue costaud pour la production en un tour de main, sans tous ses gros mots de l'écosystème Node.js, Angular ou React que sont gulp, grunt, Browserify, webpack, Babel, Bower, etc.

Au côté de AngularJS qui se targuait de bientôt devenir Angular avec une refonte tellement profonde que mêmes sa maman ne le reconnaissait plus, est arrivé React. React permettant de générer du contenu serveur à l'aide de, je cite, « son DOM virtuel ». Mais qu'est ce que c'est que ce délire ? React, c'était donc un concurrent de NodeAtlas ? Pour faire du JavaScript côté serveur ? Une alternative à Node.js peut-être ? C'est avec ça qu'était développé Facebook ? Mais c'était pas une alternative à Angular ? Pourquoi, il y a que du JavaScript et pas de HTML dans les exemples ? C'est quoi ça : JSX ? Plus je creusais l'écosystème JavaScript, et moins il semblait que j'en savais à propos de lui... qu'elle complexité ! J'étais bien content d'offrir ma petite porte d'entrée NodeAtlas, certe. Je me demandais bien si, noyé dans tout ce JavaScript côté client, et côté serveur, et côté mobile, et côté révolution, j'allais m'en sortir. Le petit temps bien au chaud avec mes jCertitudes était bien loin, et ça c'était effrayant.

L'écosystème JavaScript a explosé, ma compréhension de cette écosystème avec. Maintenant plus personne n'embauche d'expert JavaScript. Les offres se contentent d'annoncer qu'on a besoin d'un développeur JavaScript travaillant sur tel framework. Au vu des NodeJS, ReactJS, NodeJS, AngularJS ou VueJS, y a t-il encore du monde qui sait de quoi il parle ? Comment les non-experts le pourraient t-ils si même les développeurs JavaScript sont perdus.

Mais après plusieurs recroisement et une veille rigoureuse, finalement ce n'est pas si effrayant. Demandez aux experts !

Vue ? Je l'avais pas Vue !

Au côté de AngularJS, il y avait discrètement un Vue.js. Sans prétention, capable de rivaliser avec lui. Simplicité, élégance, il se démarquait avec une volonté d'être utilisé de manière évolutive et versatile. Son API était surtout si bien définie, que changer sa mécanique interne en profondeur n'a pas affecté son utilisation externe lors de son passage de Vue 1.0 à Vue 2.0, le dotant, entre autre, d'un DOM virtuel. AngularJS, lui, à perdu tout le monde et forcé le commun des mortels à se mettre à TypeScript (même si pas obligatoire... bon courage sans).

Quand React est arrivé avec son rendu côté serveur grâce à son DOM virtuel et l'utilisation de JSX (« même si pas obligatoire... bon courage sans » bis), Vue était encore là, pouvant également faire du rendu côté serveur. En fait Vue est là depuis le début et est tellement bien pensé qu'il n'a quasiment pas changé de l'extérieur. Pourtant, en terme de performance, de poids et de courbe d'apprentissage, il surpasse Angular et React ! Là où les poids lourd Google et Facebook se livrent une guerre, Vue.js se faufile, mené par une communauté JavaScript indépendante.

Vue est tellement évolutif et simple, que vous pouvez l'utiliser aussi simplement que vous utiliseriez jQuery ! Et ce n'est pas une astuce. Vue est conçu pour être utilisé aussi bien avec parcimonie sur un DOM client, quelque interfaces et formulaires que pour gérer lui-même un DOM complet côté client et serveur et une navigation complète !

Et maintenant ?

Vue.js est à Angular et React ce que jQuery est à Vanilla JS ! Aussi, si vous là bas, êtes toujours dans votre zone de confort avec jQuery et défendez cette position comme un irréductible gaulois en vous persuadant que les usines à gaz Angular et React n'ont rien à vous apporter, tentez l'aventure avec Vue.js. Il ne vous faudra pas plus d'une demi journée pour goûter à son potentiel grâce à son guide intuitif et en français !

En tout cas, pour moi, c'est tout Vue !

Pour les gourmands

Pour ceux qui veulent manger de la technique à propos de ces histoires de pilotage par le DOM vs. pilotage par données c'est pour bientôt !