Je réagis à un article que @_kud a relayé sur Twitter. L’article « Time to remove jQuery » a été écrit par Rogchap fin aôut.
Dans cet article, Rogchap explique son souhait de quitter jQuery après l’avoir utilisé, beaucoup, presque à outrance, comme beaucoup d’entre nous. Maintenant il utilisé des micro-librairies pour remplacer jQuery dans les usages que requièrent ses projets.
Je souhaitais réagir à son article plus loin que par un simple commentaire. Aussi parce que pendant longtemps comme vous le savez, j’ai tenu sur ce blog, une chronique jQuery et de nombreux articles autour de jQuery.
Cet article me sert d’amorce au mien. Sur une sorte de ras le bol de cette mode de défoncer jQuery à la première occasion venue sur des arguments parfois quasi foireux. Parfois justifiés aussi.
Un peu d’histoire
jQuery a été créé par John Resig en janvier 2006. Bientôt 9 ans ! A l’époque, on avait déjà des super stars comme Prototype (et son indissociable Scriptaculous) ou encore Yahoo UI, plus connue sous le nom de YUI. Autre star connue du milieu, citons Mootools. Vous aussi vous ressentez un peu de nostalgie pour cette époque ?
Sortons de l’histoire cul-cul pour nous pencher sur la réalité de l’époque. IE 6 était ultra-dominant. IE 7 ne devait apparaître qu’à la fin de 2006. Firefox était encore un logiciel pour geeks, la version 1 datant de fin 2004. Netscape était plus que sur le déclin. Safari, dispo que sur mac depuis 2003. Opera était là depuis 1995, mais restait assez peu représenté auprès du grand public. J’étais encore en primaire en 1995, waouh ! Enfin Chrome… n’existait pas.
Petite excentricité, pour ceux qui s’y sont essayé, il y avait aussi encore à l’époque IE 5. Et le bonus : il y avait IE 5 pour Mac (sorti en 2003). Maintenant et depuis longtemps abandonné, Internet Explorer avait sa version spéciale Apple. Et elle était pire que la version Windows. Vraiment pire. Au point que « ça » n’est même pas arrivé jusqu’à la version 6. Usage plutôt rare, mais ça m’est arrivé de devoir le prendre en compte à l’époque.
Depuis quelques années, on était dans un monde où JavaScript n’était qu’une machine à gaz immonde. Où Flash dominait en maître absolu du cross plateform, cross browser.
Firefox, l’IDE de IE
A l’époque, on codait en JS sur Firefox parce que c’était plus facile, merci Firebug. Mais ça c’était entre nous, geeks, devs, etc. Pour le grand public, fallait aussi et surtout que ça marche sur IE. C’était ça le cross browser de l’époque. On s’inquiétait aussi de savoir si l’utilisateur n’avait pas bloqué l’exécution de JavaScript. Voire parfois le CSS. Qui existait à peine à l’époque d’ailleurs. Et souffrait des mêmes problèmes de portabilité. D’ailleurs, chose que je suis sûr que vous avez oublié tellement vous avez utilisé Firebug, comme moi hein, mais même Firefox 3.5 n’avait pas l’objet console natif. Si si, réinstallez le et essayez sans Firebug. Fatal error 
JavaScript servait à faire neiger sur les écrans ou afficher des popups publicitaires. Dans les grandes lignes. Au point que JavaScript existait sur l’essentiel des navigateurs, mais pas sur Internet Explorer où certes c’était à peu de choses près pareil mais suffisamment différent pour que ça n’est pas le même nom ni certaines fonctionnalités clés.
Arrêtons nous d’ailleurs pour rappeler aussi qu’à l’époque, il y avait aussi les applets Java qui essayaient de concurrencer Flash. Et les activeX comme plugins à IE. Côté Firefox, on devait développer des extensions avec XUL. Un truc assez moisi mais en comparaison d’activeX…
Bon en fait ne mélangeons pas les torchons et les serviettes. Petite anecdote rigolote. Sur IE quand il y avait un bug vous aviez une grosse fenêtre d’alerte qui vous pétait au nez. Si vous aviez le malheur de cliquer sur le bouton de résolution, ça lançait l’éditeur VBA intégré dans Office. Je me souviens, c’était assez drôle de voir les gens arrivés en panique sur les forums croyant qu’ils avaient cassé le code de la machine.
Puis est arrivé AJAX. Alors là, fête du slip. Je me souviens avoir débarqué en salle de cours de BTS pour gueuler à mes camarades qu’on pouvait enfin changer le contenu d’une page sans la recharger entièrement et sans utiliser Flash. On s’est tous précipités sur nos PCs. C’est une révolution !
Pour rappel, les outils de compilation pour JavaScript comme Uglify et même les IDE spécialisés n’existaient pas. Le plus avancé était Dreamweaver et ça déconnait de partout. Au point que tout le monde se rabattait sur Notepad++. Je vous parle même pas de grunt, gulp, brunch, npm, bower, jslint, …
Retour à la réalité
Et là mange ta claque. Il fallait faire un objet, un script pour chaque navigateur. Et ça rien que pour Ajax. Pour faire une conne modif du DOM, aucune fonction n’était commune non plus d’ailleurs. Ce que vous faites avec jQuery pour l’essentiel des usages. A l’époque, les bibliothèques comme jQuery, Prototype, ExtJS, YUI, Mootools, etc. étaient plus que nécessaires. Elles étaient vitales pour ne pas se coller une balle. On tenait le Saint-Graal en fait.
Pour des raisons que je ne saurais expliquer, seuls Mootools et jQuery ont vraiment réussi à décoller et à suivre l’évolution. Concernant jQuery, j’ai tendance à croire que le « jQuery-style » a dû bien aidé. Il y a aussi Sencha qui avait un large public mais dès le début, ils allaient vraiment plus loin que ceux précédemment cités. Ils existent toujours mais parce qu’ils ont appliqué une approche propriétaire. Pourquoi pas.
A l’origine donc, jQuery & co répondait à une vraie problématique. Celle d’être un polyfill.
Il n’y avait pas encore jQuery UI ou jQuery Mobile. Ni même les blockbusters animation, browser, … Un monolithe.
Puis est revenue plusieurs fois la question du poids de jQuery. De ses plugins. Ça pesait lourd. Et côté référencement c’était pas top. Surtout que Chrome était arrivé sur le marché.
Rappelez vous l’arrivée de Chrome
C’était fou. On était vers septembre 2008. Une interface épurée, allégée, une vitesse d’exécution annoncée et ressentie 8 fois supérieure. Et la cerise sur le gâteau, des extensions en HTML/CSS/JavaScript qui s’installaient sans avoir besoin de redémarrer le navigateur.
Et comme un collègue qui ne mange pas son spéculoos avec son café, côté JS, ce qui marchait sous Firefox marchait sous Chrome. Et inversement. Encore une révolution!
Donc avec IE 6/7 qui perdaient des parts de marché face à des Chrome et Firefox déchaînés pour nous offrir une expérience toujours plus rapide et déboguée, on pouvait enfin s’atteler à faire du web. Le web moderne.
Ce n’est pas IE 8, arrivé en mars 2009 qui changera la donne. Souvenez vous, il y a même un petit bouton pour fonctionner en mode compatibilité avec IE 7. Preuve de l’échec de Microsoft à faire évoluer les mentalités de ces utilisateurs. Mais preuve aussi de la prise de conscience à l’époque qu’ils avaient un sérieux problème avec leurs vieux navigateurs.
De nouvelles priorités
On a commencé à se lâcher avec jQuery et Mootools, et leurs armées de plugins. Les compétences de ces frameworks ont littéralement explosées sous leurs poids. On en demandait toujours plus à des outils qui n’étaient pas conçus pour ça. On attendait des polyfills de structurer nos développements, nos pratiques, nos applis web. C’était comme construire des ponts toujours plus grands, toujours plus compliqués mais toujours avec les pierres ramassées sur la rive et disposées au petit bonheur la chance avec un peu de mortier.
Sont alors apparus des frameworks comme UI, jQuery.MVC ou encore un qui s’est bien détaché du lot : Knockout. ExtJS commençait même enfin à être vraiment utilisable. Les navigateurs réussissant enfin à le faire tourner sans ramer. Notons le choix pertinent à l’époque de changer de nom pour Sencha, ils repartirent avec une nouvelle réputation bien propre.
2009, année prospère
Deux grands changements clés à mon sens en 2009.
L’arrivée de IE 9, c’est bête mais c’était le premier navigateur potable de Microsoft. Enfin, on avait un truc qui arrêtait de déconner toutes les deux heures, enfin l’outil de débogue arrivé avec IE 8 avait un panneau « Network ». Il était enfin potable. Plus besoin d’utiliser Debug Bar.
Jeremy Ashkenas nous a offert cette année là, une des meilleures contributions au monde du développement web : CoffeeScript. Qu’on aime ou qu’on n’aime pas (comme moi), on ne peut nier l’impact que CoffeeScript a eu sur le monde du JS.
L’expérience Backbone
On est en octobre 2010, on tourne depuis quelques années maintenant avec des immondes entassements de couche de bibliothèques et débarque comme un pavé dans la mare : BackboneJS. Un framework MVC correctement foutu. C’est la déferlante des applis one-page accessible à tous les devs. Basé sur jQuery, il ne perturbe pas trop les développeurs et a donc une courbe d’apprentissage abordable.
Un rappel que même si on avait l’impression de stagner dans un monde encore franchement hésitant à reconnaître JS comme un vrai langage, oui, c’est un langage, à nous de le faire grandir, nous la communauté de tous les développeurs web.
Et si on pétait jQuery [n’importe comment] ?
Qu’est-ce que j’ai haï la période qui se profilait alors. On entendait partout : « jQuery est trop gros, du coup, j’ai construit ma propre version allégée ». Et là bim, bim, bim, toutes les semaines une nouvelle réinterprétation pourrie allégée de jQuery faisait son apparition. Toutes abandonnées au bout de quelques mois de maintenance. Seule jQLite a survécu, mais elle a eu un sponsor de taille. On en parlera plus loin.
Fut alors prise la décision en interne de découper jQuery. Il y avait déjà Sizzle arrivé en janvier 2009 qui avait extrait le moteur de sélecteurs du cœur de jQuery. C’était déjà un beau geste. Mais ils ont étaient plus loin. Dehors jQuery.animation, dehors jQuery.browser. On était de mémoire, fin 2012. Pas si vieux hein.
Entre deux, on avait déjà eu l’avènement du mobile. Android, iPhone bien implantés dans nos quotidiens et même Windows Phone avait revu sa copie et proposait des téléphones potables.
Courant 2012, il y avait aussi eu 2 énormes missiles arrivés sur la planète du web. J’ai nommé Angular et Ember. On va éviter de troller, chacun ses défauts et qualités. Le monde du web a changé de face en quelques mois. Et les deux avaient pour dépendance jQuery. Mais une dépendance minimale, puisque jQuery était revenu à son rôle de polyfill.
Enfin des outils
On a pu célébrer avec plaisir, une espèce de vague voir une interminable série de vagues qui ont retourné le web dans tous les sens. Entre les minifiers, les gestionnaires de paquets, les outils de qualité de code, les IDE dédiés et un énième pavé dans la mare : NodeJS, JavaScript est enfin reconnu comme un vrai langage industrialisable.
Maintenant on a du JS full stack cross-[ce que tu veux]
Vous vous rendez compte ?!
En quelques années, le web est devenu une espèce de force de frappe pour les entreprises, et la techno a su suivre la cadence malgré quelques à-coups façon vieux moteurs diesel au début.
Maintenant, entre IE 10 bien installé, IE 6/7 quasi disparus, IE 8 en bon déclin. Firefox et Chrome ont explosé leurs numéros de version et font toujours la course à la qualité et à la vitesse. Les mobiles sont aussi puissants que des pc. On peut faire du code serveur en JS, certains équipements embarqués parmi les plus célèbres comme Arduino ou Raspberry supportent très bien JS aussi.
En une dizaine d’années JavaScript est passé du truc infâme, in-développable comme le fut Basic à son époque avec tellement de versions qu’on ne pouvait plus les compter à un unique langage respecté à peu de choses près correctement par tous les acteurs.
Je bâcle la fin de l’historique
C’est tellement récent toute cette conclusion parce qu’on est encore en plein dedans que même les plus jeunes d’entre nous la connaisse.
Et pourtant, jQuery ramasse encore
Et pourtant oui, pourtant, je vois encore des articles à la con où un mec vient se secouer l’ego très très fort pour dire « j’ai pas besoin de jQuery moi ». C’est bien mec. Mais c’est pas un exploit. Alors oui, jQuery est dépassé, mais un polyfill de IE 6/7/8 dans un monde où ils ont presque disparu (j’insiste sur le presque, je le soutiens encore pour de vraies raisons), c’est sûr que c’est pas très utile.
Certains diront « ouais mais jQuery ça fait plus qu’être un polyfill ». Oui, ça sert aussi à manipuler plein de choses simplement. C’est bien, c’est super même, ça me sert encore beaucoup d’ailleurs, mais yep, ça ne devrait plus.
« Ouais mais jQuery c’est lourd, tu te rends compte ça fait 35k ». Alors non quitte à chipoter sur quelques Ko, ça fait 32k pour la version 1.11 et si tu ne supportes pas les vieux navigateurs, tu devrais déjà être passé à la 2.1.x qui elle n’en fait que 28. Et sinon sérieusement ? Même avec la 3G, 32k, c’est ridicule. Oui, c’est ça de gagné. Mais ton favicon en fait presque une dizaine. Si si, prends par exemple celui de Github, site que tu trouves qu’il se charge plutôt vite, même sur ton mobile. Bah il fait déjà 9k.
C’est parce que beaucoup de développeurs sont encore des brêles, des débutants et font n’importe quoi que jQuery est encore d’actualité. C’est parce que tout le monde n’utilise pas des frameworks lourds pour faire des choses simples. Parce que des fois un wordpress n’a souvent pas besoin de plus que jQuery. Peut-être aussi parce que WordPress existe encore. Ou que tous les gens qui utilisent jQuery ne sont pas des développeurs confirmés.
Il est vrai que jQuery n’est plus tout le temps nécessaire. Mais pourtant, ce n’est pas de sa faute. Alors avant d’allumer la tronche de jQuery, développeur qui blogue en crachant dessus, réfléchis d’où vient le problème moderne, pourquoi jQuery est là, pourquoi jQuery est parti en sucette sur la fin, enfin plutôt pourquoi son usage est parti en sucette. Et si finalement, le problème, ce n’est pas plutôt les personnes plus que jQuery.
Ce qu’a permis jQuery pendant de nombreuses années
Manipulation du DOM facilitée
Manipulation de Ajax facilitée
Manipulation des promises entrées dans les moeurs
Base solide pour de vrais frameworks de développement web modernes
Et ceci de façon cross-browsers, cross-platform. Favorisant enfin la disparition de Flash.
Maintenant il y a HTML 5, les web components, de gros frameworks. Mettons jQuery au placard, voire au cimetière, mais avec un peu d’honnêteté. Ne serait-ce qu’en lui disant merci.
Enfin en disant merci aux gens qui ont contribué à cet outil et aux outils concurrents pour nous avoir facilité la vie, notre travail pendant des années.
