Il est temps d’avoir déjà quitté jQuery

Flattr this!

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.

Flattr this!

A propos de Mathieu

Ingénieur développeur web dans la vente par correspondance B2B, adepte de nouvelles technologies et d'innovation. Vous pouvez aussi me retrouver sur Twitter @mathrobin
Cette entrée a été publiée dans JavaScript, avec comme mot(s)-clef(s) , , , , , , , , , , , , , , , , , , , , . Vous pouvez la mettre en favoris avec ce permalien.
  • http://b2bweb.fr molokoloco

    Longue vie à jQuery !
    La conception web ne sera jamais réservé à la hype, grâce à lui..
    Une « micro-lib » pour le DOM autre n’aura que 3 lignes de code en moins sans apporter d’avantage…
    Vos applis ne seront pas compatibles et vous ne pourrez plus échanger vos plugins… uniquement dépendants de la hype à la dernière mode, genre « angular directive pour afficher un email » 😉

  • Hervé

    Un très grand merci à jquery qui nous a bien et très bien assisté jusqu’à présent, très sincèrement.

    Plus utile désormais, surtout pour afficher un email (en fait j’ai pas compris ni pourquoi ni comment le commentaire précédent) ni quoique ce soit d’autre – si ce n’est devoir supporter des browsers dépassés qu’on ne supporte plus ou ne veut plus supporter.

  • syndrael

    Merci pour cet hommage.
    En tout cas dans le monde de l’entreprise jQuery est encore beaucoup utilisé, un peu pour les mêmes raisons que l’existence de support à IE9- .
    Sympa cette séquence nostalgie, je m’y retrouvais..
    Bonne soirée

  • http://uncatcrea.com UncatCrea

    Excellent article qui remet les pendules à l’heure. Merci. (Deux petites coquilles repérées : « j’ai hait » et « qu’a permit » ; rien de méchant.)

    • http://www.mathieurobin.com/ Mathieu

      Merci pour la correction^^

  • Eric

    Je n’ai jamais eu besoin d’utilise jquery et les autres framework car je me suis fait le mien il y a quelques années Le gain est appréciable : 2 à 10 fois plus rapide pour trouver les éléments du DOM que jquery, plus fluide sur les animations que Mootools et cela permet de mieux comprendre comment fonctionne le Javascript.
    Faites un petit test : un document.getElementById va être au moins 10 fois plus rapide qu’un $ (et comme on n’a pas toujours besoin d’utiliser $ car les fonctions standards JS sont bien fournies).
    Exemple simple à comparer : document.getElementById(‘monobjet’).style=’border 1px solid black’;

    Ensuite, il ne faut pas se limiter sur le poids d’un JS. C’est insuffisant.

    Il faut savoir que le navigateur bloque tout autre chargement tant qu’un JS n’a pas été chargé ET interprété. Et la vitesse d’interprétation d’un JS dépend de certaines fonctions.
    Une compression Dean Edwards par exemple, certes très bonne, peut-être plus longue à charger que si le code n’est pas compressé, dû en particulier à l’eval.
    La vitesse réseau peut être plus rapide que la vitesse d’exécution (surtout maintenant).

    • http://www.mathieurobin.com/ Mathieu

      Plusieurs choses à dire :
      – Merci tout d’abord, ça fait toujours plaisir d’être lu et commenté.
      – Merci de soulever le débat du DIY. Même si :
      – ton exemple de getElementById est foireux. Sous IE 6/7, getElementById ne fonctionne pas comme ailleurs. Même si introduit avec le DOM Level 2 en 2000, cette méthode avait un comportement différent sur ces 2 navigateurs. Il fallait prendre en compte l’attribut name des éléments input quand on voulait faire un getElementById. C’est là que jQuery devenait cool, il réglait ce problème de compatibilité entre navigateurs. Aux détriments des performances, logique. Plus d’infos ici.
      – Quand au chargement du JS, oui et non. Tout d’abord la règle du blocage ne s’applique que dans la partie HEAD du HTML. Les ressources comprises en en-tête sont considérées comme critiques donc bloquantes. D’où le conseil de mettre les scripts non-critiques dans le body. Plus en fin de body pour permettre d’abord le chargement du texte et des images.

      • Eric

        Tu as le même probème en fin de body qu’en début de body car le JS peut tout simplement modifier le body (la vieille commande document.write), d’où le blocage. Regarde une console avec Firebug pour le voir.
        Si tu le mets en bas de body, le blocage est moins visible (ça peut laisser le temps de charger d’autres éléments) mais tout aussi présent car le JS doit être interprété (http://stackoverflow.com/questions/4396849/does-the-script-tag-position-in-html-affects-performance-of-the-webpage)

        Quand au getElementByID, qui n’est qu’un exemple dans mon cas, il fonctionne sur IE6/IE7 (moins bien, d’accord mais ce n’est pas bien gênant au point d’être foireux. Dans mon cas je n’utilise l’attribut NAME que s’il y a un submit. Et j’ai bien sûr les mêmes noms en id et name, voire pas d’id si pas besoin de JS).

      • Anon

        Y’a encore des gens qui gèrent la compatibilité IE 6/7 ?
        Les malheureux ..!

        Je pense qu’une proportion non négligeable de devs utilise jQuery seulement pour la manipulation de DOM.
        Du coup, je me demande si personne n’a pensé à intégrer directement dans la norme cette fameuse méthode $ ?
        Parce ne pas pouvoir selectionner un élément par sa classe, rien que pour ça le JS alone me fais chier.
        Qu’est ce qui les empeche de récupérer les meilleures idées de jQuery ? Ajax aussi par exemple…
        Il y a peut être une bonne raison que je vois pas pour ne pas le faire, si quelqu’un peut m’éclairer ?

        Ps : Bon article

        • Elo

          On voit que tu ne connais pas le JS (sans méchanceté).
          getElementsByClassName (peut être 10x plus rapide que la version jQuery)
          Pour l’AJAX, bien sûr qu’il fait partie du JS.

          • Anon

            Au temps pour moi, je ne sais pas pourquoi je croyais ça.
            Reste que les sélecteurs CSS sont quand même bien plus pratique…
            Oui, AJAX fait partie du JS, mais bon voila la syntaxe quoi… J’ai jamais été foutu de la retenir, alors qu’avec jQuery ça rentre tout seul !

          • http://www.mathieurobin.com/ Mathieu

            Ce que ne précise pas elo concernant ton commentaire, c’est que ces méthodes n’ont pas toujours existé. Pendant longtemps, on n’a eu que getElementById et getElementsByClassName. Amplement suffisant pour les choses de base. A condition qu’elles fonctionnent de façon similaire sur tous les navigateurs. Ce qui n’était pas le cas. D’où l’importance de jQuery & confrères à l’époque. Maintenant on a toute une tripotée de nouvelles méthodes géniales pour faire le boulot. Comme querySelector (https://developer.mozilla.org/en-US/docs/Web/API/document.querySelector) ou querySelectorAll (https://developer.mozilla.org/fr/docs/Web/API/document.querySelectorAll) par exemple

        • http://www.mathieurobin.com/ Mathieu

          Oui, il y a des gens qui gèrent encore la compatibilité IE 6/IE 7. Tant qu’on ne fait pas des applications d’une complexité extrême, ce n’est presque pas compliqué. J’entends qu’avec peu d’efforts et pas mal d’expérience, je sais quels polyfills vont me manquer et donc les ajouter pour que mon appli marche. Mes applis angular fonctionnent sur IE 6 par exemple. Mais c’est un autre débat…

      • syndrael

        Pour le getElementById il n’a peut-être pas les mêmes contraintes que toi ce qui lui a permis de faire son propre ‘framework’. La compatibilité IE6/7 est une contrainte qui n’est pas présente chez tout le monde.. chez moi elle l’était pendant de nombreuses années en entreprise.

  • https://github.com/AMorgaut Alexandre Morgaut

    Ton article me rappelle la création d’un site: http://youmightnotneedjquery.com/
    Il avait provoqué un énorme buzz (voir http://apdevblog.com/to-use-jquery-or-not-to-use-jquery/) et au final des réactions qui ont permis de mettre en avant ce pourquoi, encore aujourd’hui, jQuery est très utile.
    Je pense en particulier à la liste remontée par Rick Waldron d’un nombre impressionnant de bugs de browsers pris en compte par jQuery: https://gist.github.com/rwaldron/8720084#file-reasons-md
    Cette liste, brute à l’origine, a été reprise et enrichie par John-David Dalton et Paul Irish… que des beaux noms pour les connaisseurs 😉
    Je vous invite à y jeter un oeil, ça vaut le détour
    https://docs.google.com/document/d/1LPaPA30bLUB_publLIMF0RlhdnPx_ePXm7oW02iiT6o/edit

  • gregory

    bonjour,
    j’ai lu le post moi je suis en train de me former au JS (c’est quand même un langage particulier)
    mais au départ je n’utilisais que jquery et il m’a amener au JS (oui je sais je ne suis qu’un débutant),
    ma question c’est d’après toi pour devenir un bon développeur JS il faut combien de temps?

    • http://www.mathieurobin.com/ Mathieu

      Hello !

      Alors là, je l’avais pas vue venir celle là… Honnêtement, c’est quoi déjà un bon développeur JS ? Un dev front capable de faire des animations complètement craquées ? Un dev appli one page comme moi ? Un dev full stack qui fait du client comme du serveur en JS ? Tout dépend vers quoi tu te tournes, ce que t’estimes être bon.
      Perso, j’ai pas appris le web en cours. J’écris un autre article sur ce sujet en ce moment d’ailleurs.

      J’ai dû apprendre sur le terrain et ça m’a beaucoup ralenti, comme tu as pu le lire, JavaScript a été mal aimé pendant longtemps à cause des navigateurs qui partaient un peu dans tous les sens. Ça a pris beaucoup de temps pour être capable de faire un projet potable en JS, de faire des applis et de maintenant avoir mon statut de lead dev JS. Il y a encore 3 ou 4 ans, on aurait pas vu un tel marché de l’emploi sur JS. C’est cool que ça se développe.

      Courage à toi, tu as fait une bonne première étape qui a été de sortir du pur jQuery pour comprendre JavaScript. C’est une bonne première chose.

  • https://github.com/AMorgaut Alexandre Morgaut

    Ton article me rappelle la création d’un site: http://youmightnotneedjquery.com/

    Il avait provoqué un énorme buzz (voir http://apdevblog.com/to-use-jquery-or-not-to-use-jquery/) et au final des réactions qui ont permis de mettre en avant ce pourquoi, encore aujourd’hui, jQuery est très utile.
    Je pense en particulier à la liste remontée par Rick Waldron d’un nombre impressionnant de bugs de browsers pris en compte par jQuery: https://gist.github.com/rwaldron/8720084#file-reasons-md
    Cette liste, brute à l’origine, a été reprise et enrichie par John-David Dalton et Paul Irish… que des beaux noms pour les connaisseurs 😉

    Je vous invite à y jeter un oeil, ça vaut le détour
    https://docs.google.com/document/d/1LPaPA30bLUB_publLIMF0RlhdnPx_ePXm7oW02iiT6o/view

    • http://www.mathieurobin.com/ Mathieu

      Tiens ouais, j’avais oublié ça. Je crois que c’est le commentaire le plus constructif depuis que j’ai lancé ce blog…

      • https://github.com/AMorgaut Alexandre Morgaut

        du coup il apparait en double maintenant
        mais merci pour le côté « constructif » 😉
        vivement que je puisse refaire un BeerJS pour te taper sur l’épaule

  • http://www.cedricrey.fr Cédric Rey

    Bonjour,
    L’article est super intéressant.
    Ayant pu commencer par Prototype en ce qui concerne les lib JS, pour bifurquer ensuite sur jQuery, je pense que ce qui a fait que le premier n’a pas pu résister est surtout sa lourdeur. Il était certes plus orienté « objet » (si je peux me permettre), mais le temps d’exécution était bien plus lourd, surtout pour faire du simple polyfill, à côté de jQuery. Il me semble que les bench montraient de grosses différences. Peut être que je me trompe totalement.
    En ce qui concerne getElementsByClassName, elle a été longtemps absente (je crois qu’elle est même absente d’IE8), et chez moi, seul getElementById ou getElementsByTagName étaient dispo en JS pur. Du coup, merci à ces lib, que je ne jetterai pas aux orties aussi facilement.
    L’article résume bien l’idée qu’il faut utiliser les outils adéquats aux bons moments en développement front comme en développement tout court.
    Merci

    ps : c’est quand les BeerJS sur Paris?

    • http://www.mathieurobin.com/ Mathieu

      Salut !

      Content de voir que l’article plaît toujours.

      Effectivement, j’ai aussi utilisé Prototype pendant longtemps. Je ne me souviens plus très bien de ce qui m’a amené de passer de l’un à l’autre. Sûrement sa lourdeur. Je me souviens que même si ça simplifiait beaucoup de choses, ce n’était pas encore idéal. C’était déjà génial ceci dit.
      J’ai le même doute pour getElementsByClassName, j’ai préféré ne pas dire de bêtise.

      Et nous sommes d’accord sur la question de jeter trop facilement des libs qui nous ont plus d’une fois sauver la mise.

      Pour les BeerJS, tu dois suivre l’actualité du meetup de FranceJS (http://www.meetup.com/FranceJS/) ou le twitter dédié de BeerJS_Paris (https://twitter.com/BeerJS_Paris)

  • Mickaël Houët

    Bonjour,

    Merci pour cet article très intéressant permettant de prendre du recul vis à vis des technos qu’on utilise au quotidien. Jquery reste pour moi une solution tout à fait valable.

    Je voulais ajouter un aspect généralement peu abordé dans le genre de discussion « cette techno est obsolète, y’a mieux, faut tout jeter et recommencer avec cette nouvelle techno qui déchire, etc… !! ».
    Personnellement je suis développeur web professionnel client et serveur (PHP + jQuery principalement). Le cycle de vie de nos applications web est assez long : 2 à 3 ans de développement pour ensuite 2 à 4 ans de durée de vie (en ajoutant durant ce temps de nouvelles fonctionnalités pour nos clients et en corrigeant les failles de sécurités qui sont découvertes). Tout cela pour dire qu’il est très difficile voire impossible de changer radicalement de technologie durant ce cycle de vie. Nous n’avons tout simplement pas le temps pour cela : le temps des développeurs est strictement planifié entre l’ajout de nouvelles fonctionnalités, la TMA, les projets client, etc…
    Une fois le choix des technos effectués, on s’y tient durant toute la durée de vie de l’application. Cela couterait tout simplement trop chère de changer au rythme des modes qui passent et qui s’en vont.
    jQuery a été choisi pour notre application de vente e-commerce que j’ai personnellement commencé à écrire en 2008 (version 1) et qui est utilisé aujourd’hui encore sur plusieurs sites e-commerce en activité. Le choix de jQuery nous semblait pertinent en 2008 et il l’était encore en 2012 quand nous avons commencé à écrire la version 2 de notre logiciel. Cette v2 est actuellement en fin de dev aujourd’hui et elle va commencer sa vrai carrière commerciale par un projet qui sera lancé en 2015. Donc nos sites actuels et futurs utilisent jQuery de manière intensives et s’en portent très bien malgré tout.
    Dans notre cadre de travail nous avons besoin de technologies que l’on estime fiables dans le temps. Et nous n’avons malheureusement pas le luxe de pouvoir changer en cours de route les technologies utilisés parce qu’un super framework de la mort vient de sortir et que tout le monde dit que c’est le saint graal etc…

    Pour moi jQuery reste un choix pertinent encore aujourd’hui pour tout un tas de raisons donc la compatibilité ie8/7/6 reste pour moi la plus anecdotique (il y a maintenant un an que nous annonçons que nos applis ne fonctionneront plus sur ie6/7 et pour ie8 c’est 10% de coût en plus histoire de décourager les demandes).
    Lorsque nous entamerons la V3 (sans doute en 2015 quand notre v2 commencera son cycle de vie commercial), nous regarderons alors la techno qui nous semble la plus intéressante, en prenant en compte de l’aspect certes techniques mais pas seulement. Je dirais même que cet aspect arrive pratiquement en dernier. La pérennité d’une solution, son support par une équipe sérieuse et compétente, le nombre de dev sur le marché du travail, le nombre d’extensions utilisables sur le net etc… seront pour nous des critères bien plus déterminent dans nos choix. Et ce choix, nous le tiendrons et l’assumerons durant au moins 5 ans. Nous savons pertinemment que durant ces 5 années de nouvelles choses arriveront et nous nous y intéresseront forcement dans le cadre de notre veille technologique. Mais nous n’allons certainement pas réécrire 10000 lignes de code en claquant des doigts sans conséquences sur le planning ou les investissements réalisés.

    Voilà, désolé pour le pavé :/ mais je souhaitais juste ajouter quelques arguments venant d’une certaine industrie du logiciel en faveur de toutes ces technologies jugées trop souvent à tord obsolètes ou « ayant fait leur temps » par une population de développeurs ultra réactifs et peut être trop enthousiaste vis à vis de la nouveauté.

    • http://www.mathieurobin.com/ Mathieu

      Pas de problème pour le pavé, c’est aussi ce genre de propos qui font vraiment progresser une discussion. Ça fait également plaisir de voir l’avis d’une personne qui fait des projets de très longues haleines. Je ne retrouve plus le lien dans mes archives mais j’avais lu qu’en gros entre 60 et 70% des gens qui utilisent jQuery, sont des intégrateurs ou des développeurs front/full stack bossant pour des projets de petite ampleur, à peine quelques mois en général de dev, souvent en one-shot, type presta. Forcément, la capacité d’évolution est énorme, pour des développeurs à un niveau plus industriel comme il en existe, ce n’est pas du tout la même présentation du travail au quotidien, et nous sommes d’accord, le changement de technologies à un coût énorme parfois impossible à assumer.
      Encore une fois merci de ton point de vue, c’est un des plus pertinents :)

  • Quentin

    Bonjour, je viens de découvrir ton blog e je prends beaucoup de plaisir à le lire.
    Je suis relativement novice dans l’informatique et je fais principalement du html / css + javascript (JQuery).
    Bon du coup j’ai bien compris que JQuery commençait à être « dépassé ».
    J’aime beaucoup JQuery car il permet un gain de temps non négligeable lors de l’écriture du code (pour être honnête, j’utilise très rarement la syntaxe de base de javascript, je trouve celle ci beaucoup moins claire).
    Ma question est la suivante; étant encore en phase « d’apprentissage », est ce que je dois laisser tomber complètement JQuery pour me diriger vers autre chose?
    Ou bien est-il quand même avantageux de continuer à l’utilisé pour des sites web ou l’optimisation n’est pas critique par exemple.
    Et finalement, quelles sont les alternatives les plus « viable »

    • http://www.mathieurobin.com/ Mathieu

      Alors je commencerais par un immense « Bienvenue ! » :)
      (et merci aussi)

      Alors attention, à bien différencier les vils trolls, souvent des développeurs débutants, qui parce qu’ils sont tombés sur un super framework de dingue genre Angular, Ember, ou en ce moment React, etc. qui se lâchent le cerveau en critiques sur les choses plus âgées, plus matures telles que jQuery, Mootools ou même Backbone.

      Certains y voient des solutions miracles pour tout faire mais oublient que des fois, il n’y a pas besoin de sortir une escadrille complète de tanks pour buter une vache. Parfois un lance-roquettes suffit. Et d’autres fois, un petit pistolet aussi.

      Selon les usages, un bon développeur, un vrai, saura si il doit ranger son très gros fusil dans sa poche et rester humble. Dès fois le JS natif (dit Vanilla) est amplement suffisant, quitte à se prendre un peu la tête. D’autres fois jQuery est carrément le bon choix, quand on n’est pas sur une Single-Page-Application (SPA, anciennement RIA) par exemple mais qu’on a besoin d’interactivités. Et certains ont tendance à oublier que l’immense majorité des frameworks modernes se basent sur jQuery voire, dépendent de jQuery. Backbone et Ember ont piur dépendance obligatoire jQuery, Angular l’intègre en allégé (même si pour la V2 ils s’en débarrassent).

      C’est à toi d’adapter tes usages. Ne connaître qu’un seul framework est une erreur, n’en user qu’un seul aussi. Et ne pas connaître le Vanilla l’est encore plus.

  • Quentin

    Merci pour ta réponse rapide!
    En fait pour le moment je participe au développement d’un site du même type qu’Air bnb ( Je parle juste de la « structure » du site, le concept n’a rien à voir avec celui ci).
    On utilise un framework php (symphony 2) et j’utilise beaucoup le librairie JQuery.
    Je comprends et je sais utiliser le Vanilla, je suis juste beaucoup moins à l’aise avec.
    Mais tu me conforte dans l’idée que tout est une question de contexte pour le choix du framework.
    J’ai pu apprendre à utilisé de manière très basique Angular, mais j’ai pensé qu’il n’était pas forcément adapté à la création d’un tel site (peut être que je me trompe).
    En parallèle j’apprends aussi à coder avec Sencha touch (c’est la solution qui m’a semblé le plus adapté pour un développement cross-platform sur mobile).
    En bref, pour le développement d’un tel site, JQuery te semble t-il adapté?

    • http://www.mathieurobin.com/ Mathieu

      C’est pas directement ce que doit faire le site qui doit déterminer quel framework JS tu dois utiliser. C’est là où tu mets la frontière entre le serveur et le client. En gros, si tu dois tout faire sur une page avec que des appels à des petits templates et du json partout, oui, Angular, c’est mieux. Si tu fais un site avec plein de pages et juste des interactions sur chaque page, là dans ce cas jQuery est adapté. Après si t’as pas besoin de rétro-compatibilité, descendre jusqu’à Vanilla peut sembler encore plus pertinent. T’as quand même une grosse lib bien lourde à charger juste pour pouvoir être plus à l’aise. C’est l’expérience qui te fera savoir si valait mieux rester en Vanilla.

      • Quentin

        D’accord, merci beaucoup :).
        Donc oui clairement la JQuery est bien plus adapté que Angular pour le projet.
        Tu as probablement raison pour Vanilla, mais bon maintenant que c’est codé en JQuery, je ne peux pas prendre le temps de tout refaire.
        Bon le site reste relativement rapide à charger et la lib est chargé une fois sur la première page et gardée en cache ensuite donc pour le moment cela fera l’affaire.
        Merci pour le temps que tu as pris pour me répondre en tout cas!

        • http://www.mathieurobin.com/ Mathieu

          Pas de soucis, t’es le bienvenu !

Articles liés