Logo_jQuery

jquip & cie, une fausse bonne idée

Publié le 29 novembre 2011 par (34 commentaires)
Flattr this!

Comme dit hier dans ma chronique, certaines choses commencent à me fatiguer et il est temps de remettre les pendules à l'heure. Ou à minima que je pousse mon coup de gueule, ça fait toujours du bien.

jquip est une fausse bonne idée !

Bon en fait, ce n'est pas que jquip mais toute tentative de construire une version personnalisée de jQuery ou de n'importe quel autre framework "populaire".

Pourquoi ?

Parce que cela signifie plusieurs choses :

  • vous fragmentez un tout qui a été pensé et conçu comme tel ;
  • vous rendez la maintenance de votre application/site quasi impossible du fait du temps passé à porter vos modifications sur chaque nouvelle version ;
  • vous devez reprendre tous les tests unitaires et y porter les modifs nécessaires pour éliminer les tests qui concernent vos suppressions (ah ah rien qu'à cette idée j'en pleure de rire, à ce point, ce n'est plus du courage) ;
  • vous allez certainement provoquer un bug ou une instabilité dans un plugin qui n'est pas de votre oeuvre, en plus de ceux pouvant déjà être potentiellement présents. Votre seul test est visuel, avec un peu de chance, vous avez les unitaires mais c'est rare, très rare ;
  • vous avez effectivement réduit la taille de votre bibliothèque, bravo, vous avez gagné 10Ko (en admettant que vous ayez su retirer 30% de la librairie en version de production). Bravo, 10Ko, même un téléphone 3G (et pas 3G+) ne fera pas la différence. Sur un modem 56Ko, vous avez économisé quelques précieuses secondes à vos visiteurs ;
  • vous avez perdu une semaine (si vous avez travaillé rapidement et salement) pour faire gagner quelques instants à 1% 40% de vos visiteurs (correction suite à un commentaire).

La solution

Oui, il est vrai, jQuery fait son poids mine de rien : 31Ko pour la 1.7.1 en version minifiée et gzippée. Pour certains terminaux et certaines connexions, ça représente une belle charge et c'est bien d'en avoir conscience. Ceci dit, vous allez devoir réfléchir plus loin que votre personne application.

Utilisez les CDN !

C'est fou, on ne le répétera jamais assez. Le principe est simple : tous les navigateurs disposent d'un cache. Un passage sur un site au cours de la session du navigateur, voire plus pour ceux qui ne nettoient rien, et pof, la librairie est en cache et n'en bouge plus. Ce qui veut dire :

  • vous ne cherchez pas à découper un monolithe ;
  • la mise à jour vers une nouvelle version se fait par un simple changement d'appel de fichier (20 secondes) ;
  • vous n'avez pas besoin de dérouler les tests unitaires, l'équipe l'a déjà fait pour vous ;
  • vous n'avez à traiter que les potentiels problèmes déjà existants des plugins que vous utilisez, pas ceux que vous avez ajoutés ;
  • vous avez toujours une librairie de 36Ko, mais qui pèsera 0 (même pas les en-têtes) si la personne a visité un autre site utilisant jQuery avant le vôtre, ce qui est de plus en plus probable ;
  • vous avez pu vous occuper de votre application/site, vous avez économisés une semaine de votre temps et avez pu prendre votre temps en pause déjeuner tout en bouclant le projet en temps et en heure.

J'ai employé un ton quelque peu ironique ici mais j'espère par là vous avoir fait comprendre le ridicule de ce débat : "version composée personnelle VS. version originale complète".

Attention, à ne pas confondre avec la question actuellement traitée par l'équipe de développement qui concerne l'allègement par l'élimination des choses qui n'ont rien à faire dans le coeur. Sauf que eux connaissent vraiment la librairie sur le bout des doigts et c'est vraiment leur projet professionnel.

Et parce qu'il serait dommage d'arrêter là, je vous recommande le CDN de jQuery :

http://code.jquery.com/jquery-1.7.1.min.js

Vous pouvez bien évidement utiliser les CDN de Google et Microsoft mais ceux-ci sont mis à jour dans un délai plus long que l'officiel et s'éparpiller serait ridicule en ôtant tout intérêt aux CDN. Dernière précision, si vous voulez éviter des mauvaises surprises à l'usage d'un CDN, précisez toujours le numéro de la version utilisée, sinon, vous risquez un résultat hasardeux.

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 jQuery, avec comme mot(s)-clef(s) , , , , , , , , , . Vous pouvez la mettre en favoris avec ce permalien.
  • http://www.magix-dev.be gtraxx

    J’avais pas vu ce billet, je postais dans l’autre et je te rejoins à 100% sur le sujet.
    Pour ceux qui souhaitent alléger la charge, il faut simplement utilisé les bonnes pratique pour l’inclusion de script externe, optimisé votre code source, utilisé la minification pour le JS et CSS, etc…
    Bref autant de technique bien documenté sur internet pour réduire la charge, puis c’est à la charge du développeur de se renseigner sur le sujet :)
    Utilisé jQuery original vous garantis une stabilité optimal n’ayant pas besoin de se taper la série de tests unitaire.
    Bref 2 ans que je tente d’enseigner ses techniques ayant fait leurs preuves donc utilisé la marque pas la contre façon (je suis dur la lol)

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

      L’image est plutôt bien trouvée ceci dit.

  • François « cahnory » Germain

    Entièrement d’accord, c’est à se demander si les gens à l’origine de ces initiatives n’ont pas plutôt envi de créer leur librairie tout en bénéficiant de l’atout popularité de jQuery. Là on se retrouve avec un code voué à l’obsolescence ou à sa désolidarisation pure et simple de jQuery (qui n’aura donc servi qu’à attirer l’œil du public).
    C’est d’autant plus inutile que les gars de chez jQuery bossent actuellement, comme le précise ton article, au « nettoyage » de la lib. et que les solutions type CDN apportent bon nombre d’avantages.
    Pour les frileux du CDN je colle ici un code qui devrait (je pense, dans l’idéal) mettre tout le monde d’accord tiré du célèbre html5boilerplate :

    window.jQuery || document.write('\x3C/script>')

  • François « cahnory » Germain

    Oops :
    <!-- Grab Google CDN's jQuery, with a protocol relative URL; fall back to local if necessary -->
    <script src="//ajax.googleapis.com/ajax/libs/jquery/1.5.1/jquery.js"></script>
    <script>window.jQuery || document.write('<script src="js/libs/jquery-1.5.1.min.js">\x3C/script>')</script>

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

      Merci de la précision à propos de HTML5Boilerplate^^

      • François « cahnory » Germain

        Je me rend compte que l’exemple utilise une ancienne version de jQuery qui plus est sur le CDN de google ^^ mais ce code n’est là qu’à titre d’exemple.

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

          Oui, si on a fait l’effort de tout lire et d’accepter de comprendre ce que ce code fait, on est capable de remplacer 5 par 7 😉

  • https://twitter.com/tbassetto Thomas

    Merci d’avoir écrit cet article. Si je suis d’accord dans l’ensemble, il faut toujours garder à l’esprit que l’utilisation d’un CDN n’est pas à toute épreuve. Il *faut* utiliser le pattern décrit dans HTML5 Boilerplate comme le rappelle François. Je recommande la lecture de cet article aussi http://performance.survol.fr/2009/02/cache-central-des-bibliotheques-javascript/ (et de tout http://performance.survol.fr en fait :) et aussi http://www.mnot.net/cache_docs/). Pour la petite histoire, j’ai déjà vu le CDN Google être inaccessible pendant un quelques minutes, selon l’audience du site ça peut être fatal :)

    Yahoo avait fait une étude il y a quelques temps sur le vrai apport d’un cache et s’était aperçu que 40 à 60% de leur visiteur avait un cache vide : http://www.yuiblog.com/blog/2007/01/04/performance-research-part-2/

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

      C’est sûr, il faut en avoir conscience, merci à toi aussi pour cette précision. Je vais foncer voir le lien que tu suggères !

      • https://twitter.com/tbassetto Thomas

        Je suis tombé sur un article intéressant et dans le sujet aujourd’hui : http://statichtml.com/2011/google-ajax-libraries-caching.html

        Résumé (mais je recommande plutôt la lecture de l’article en entier) :
        Si vous ne connaissez pas http://httparchive.org, vous avez tort :) C’est un super outil qui analyze des milliers de pages des sites les plus populaires. Ce nombre augmente au fur et à mesure des mises à jour du site. L’auteur de l’article s’est servi des données du site pour voir combien de pages font appel à jQuery via un CDN et surtout quelle URL (quelle version) ils utilisent. Il a trouvé que la version la plus fréquente est jQuery 1.4.2, appelée via HTTP sur … 2.7% de l’échantillon.

        Comme tu dis plus bas « à nous de faire en sorte que ce ne soit plus le cas », mais il reste un long chemin à parcourir.

    • Marwan

      J’aurais quand même tendances à utiliser les CDN de google
      avant de mettre le mien en place 😉 => CDN qui ne délivrera qu’une feuille JS (concaténation de plusieurs modules) pour optimiser le chargement, aider à la SEO ….

  • Savageman

    Là ou je suis moins d’accord c’est quand tu dis que 10 ko ça représente rien.
    Quand tu commences à faire de l’optimisation client (min, gzip, sprites, etc.) et que tu as réduit de 70% la taille téléchargée par le client (ça n’est pas impossible, lis la fin pour un exemple en live), 10ko ça peut très vite représenter assez gros en pourcentage… De l’ordre de plus de 10%.

    Et si jquip est bien fait, tu n’as rien à changer dans ton code, ou presque. Le rapport temps passé / résultat obtenu n’est pas forcément mauvais comparé aux autres optimisations que l’on peut faire (les sprites, c’est assez long pour un résultat pas forcément énorme…).

    Selon moi, ça n’est pas du tout si négligeable que ce que tu dis. D’autant plus que comme l’a dit Thomas, au moins 40% ont un cache vide (au passage, tu remarqueras donc que le chiffre 1% que tu cites dans ton dernier point est complètement faux 😉 ).

    Autre chose à prendre en considération : le CDN se situe sur un autre domaine que notre site, du coup ça fait une requête DNS en plus et au final, le temps de download du fichier est plus élevé que s’il avait été hébergé par nous-même. Ceci vrai si ton serveur d’hébergement se situe près du lieu de résidence de tes visiteurs. Car si ton serveur est en France et ton visiteur aux USA, alors le CDN sera plus rapide. :-) Tout dépend de la cible du site. Si 90% de tes visiteurs viennent de France et que le serveur du CDN n’est pas dans le pays, alors ça ne vaut pas forcément le coup non plus…

    Concernant les 3 premiers points : « fragmenter quelque chose qui a été conçu comme tel », « temps passer à porter les modifications » et « reprise des tests unitaires », c’est un peu un faux problème. Quand on utilise jQuery, on ne fait pas nous-même les modifications ou les tests, on délègue ce travail aux créateurs. Et quand on utilise jquip, c’est la même chose : il faut faire confiance aux outils qu’on utilise, ou sinon on ne les utilise pas.
    Je t’accorde cependant que j’ai une totale confiance en jQuery ce qui n’est pas le cas pour jquip. Ils sont peu connus et manquent sans doute de rigueur, mais c’est un autre problème.

    Tant qu’on parle d’optimisation, j’ai regardé sur ton site ce qu’on pourrait faire, et j’ai trouvé un super exemple !
    Tu pourrais facilement gagner 30% de la taille téléchargée sur ton site, simplement en optimisant l’image de fond. C’est un motif jpg de 740*740 pixels qui fait 195 ko, et la page au total fait environ 500 ko : l’image de fond représente donc presque 40% du total ! En passant l’image en 300*300 et une meilleure compression, le rendu ne serait vraisemblablement pas bien différent et l’image devrait passer sous la barre des 50 ko (à la louche, hein ^^ ). 150 ko de moins, ça fait 30% de taille gagnée pour tous tes visiteurs. Le rapport temps passé / résultat obtenu serait excellent ! 😉

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

      Pas faux. Je reprends point par point :
      – Effectivement dans une optim très poussée, 10%, c’est un chiffre énorme et pouvoir s’en débarrasser, c’est déjà bien.
      – Si je ne dis pas de bêtise, avec les sprites, finalement, on ne gagne que sur les en-têtes des requêtes/réponses, non ?
      – Pour le coup, les 40% de caches vides, bon bah là ok, j’ai tort hein (je corrige le billet en conséquence). Ceci dit, à nous de faire en sorte que ce ne soit plus le cas, non ? En se mettant tous aux CDN, seul le premier site visité trinquera pour les autres. Même réponse pour les soucis de DNS et de cross-domain, une fois qu’il est chargé et en cache, la question ne se pose plus.
      – Concernant jquip, effectivement, il faut faire confiance à l’équipe de jquip, cependant ce n’est pas les seuls qui tentent de faire ça mais les premiers à vraiment faire parler d’eux. Sur les forums officiels de jQuery, on en voit passer un de temps en temps qui propose une version allégée ou modifiée. Ceux-là sont aussi visés par mon billet même si moins explicite.
      – Concernant mon site, j’avoue n’avoir même pas cherché à vérifier le thème fourni par celui qui m’a fait le design, mais je vais regarder ça. Merci de l’info !

      • Savageman

        – Avec les sprites, tu gagnes un chouilla avec les entêtes, mais tu gagnes surtout en nombre de requêtes brutes (genre un set de 20 smileys par exemple, ou des icônes de menu). Ceci dit, toutes les images du sprite ne servent pas forcément non plus, du coup tu télécharges aussi certaines parties « pour rien ».

        – Oui, en se metttant tous aux CDN ça améliore un peu la chose. Mais plusieurs CDN existent (celui de Google et celui de jQuery pour ne pas les citer), et plusieurs versions de jQuery existent aussi, donc au final ça fait quand même un paquet de combinaisons possibles…

        – Pour jquip, on est sur la même longueur d’onde. Au final ça fait quand même bouger jQuery et on peut espérer plus tard avoir ce genre de choses en natif.

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

          Merci pour les explications sur les sprites, je connaissais le principe mais je ne suis pas trop au fait de ce que ça changeait.

          D’où l’importance d’essayer d’être vraiment tous à jour et c’est aussi pour ça que je n’ai mis que le CDN jQuery, pour n’en suggérer qu’un.

          jquip et cie a ont eu effectivement cet effet positif sur l’équipe de jQuery. Les forcer à faire le ménage et à proposer plutôt des plugins comme dans le cas de jquery.browser.

          • http://www.megaptery.com/ Pierrinho

            Désolé pour avoir fourni cette fameuse image de fond ! 😛

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

            Eh eh, je vais voir ce que je peux faire pour réduire un peu, ça ne retire pas à la qualité de ton travail ceci dit 😉

          • François « cahnory » Germain

            Pour les images, sous mac je ne peux que conseiller la très bonne application « imageOptim » ! Un must have.

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

            Je suis sous PC/Ubuntu, les jouets d’Apple ne sont pas pour moi. Mais merci du conseil quand même 😉

  • http://www.olivierpons.fr/ Olivier Pons

    Je cite « Je suis sous PC/Ubuntu, les jouets d’Apple ne sont pas pour moi. Mais merci du conseil quand même « .

    J’aurais dit : « Je suis sous PC/Ubuntu, les jouets «Apple» ne sont pas pour moi. Mais merci du conseil quand même ».

    Troll time 😉

  • http://www.magix-dev.be gtraxx

    L’équivalent de imageOptim pour linux c’est bien entendu Trimage voir :
    Pour débian : http://packages.debian.org/fr/sid/trimage
    Pour ubutnu: http://packages.ubuntu.com/oneiric/graphics/trimage
    Sinon pour ce qui est de l’optimisation, les techniques sont nombreuses et surtout à mettre en œuvre suivant le cas nécessitant pas mal de travail.
    Pour ma part, j’ai pris le plis d’utiliser les sprites depuis un bon moment c’est tellement pratique en plus mais je n’utilise que rarement jQuery venant de google code, je préfère l’intégrer directement sa m’évite d’avoir un problème si sa saute chez google code puis la gestion du cache est tellement amusante.
    Heureusement yslow est la pour nous aidez dans l’amélioration des performances sans oublier les tutos, les docs, etc…

  • http://www.pure-tentation.fr/ Syndrael

    +1 pour le coup de gueule..
    J’en reste à me demander qui a envie d’optimiser à ce point, surtout pour quel gain ??
    Un gain de temps de chargement ? Un gain de bande passante côté serveur ?
    Quand je vois des gens qui cherchent ce genre de pétouilles et qui codent comme des ploucs, je ne m’étonne plus de rien.. Ne soyons pas plus royalistes que le roi, et apprenons à optimiser notre propre code.. Le code côté serveur, y’a du boulot pour 10 ans.. LOL !!
    En tout cas, content de voir que le sujet fait réagir..
    Bonne journée
    S.

  • LynK

    Jquip à deux avantages et ou applications:

    – La première est d’inciter jQuery à se sortir les doigts. Je m’explique :
    En ce moment, la taille des disques dur explose, les jeux font du n’importe quoi. World of Warcraft fait par exemple 30Go avec les extensions pour un jeux sommes toute pas surcharger en texture etc… alors qu’un skyrim ne prends que 5,4 Go… Sert a rien d’optimiser vu la taille des disques dur.
    En ce moment, la vitesse des connexions explosent à travers le monde, les developpeurs font n’importe quoi. On créé des librairies n’importe comment, on ajoute des fonctionnalités à tout va sans supprimer les anciennes etc… enfin chaque mise à jour apporte son lot de Ko, mais on s’en fou, on a tous l’adsl.

    Mais ce n’est pas le cas. Et oui un exemple criant, le web mobile. Je lis cet article en m’intéressant à appli mobile (d’ailleurs j’ai un pb, je fais un site iphone et dans ce site ya 3 liens. Je créé un raccourci sur l’écran d’accueil et celui ci s’ouvre correctement en plein écran. par contre quand je clique sur un des liens, il bascule sur safari. n’y a t’il pas un moyen sans utiliser les iframes et ajax ? ). Donc je reprends.
    Les connexions internet mobile peuvent être d’une lenteur extrême et là, la taille et l’optimisation joue un role fondamental.

    Quand j’ai vu que jQuery travaillait sur jQuery mobile, je me suis dit « génial il vont sortir qqch de plus léger et optimiser pour le mobile » Que nini, il rajoute une surcouche par dessus la grosse librairie js pour faire des interface … Dans le problème que j’évoque au dessus, le site ne comporte pas de javascript, il pèse 423ko sans minification aucune… donc si je rajoute jquery ça me fait quasi 25% de taille en plus… Y’a rien qui vous choquent ?

    Pour conclure, Nous n’avons aucun recul sur jquip, mais je suis content que certain monte au créneaux pour montrer aux dévs que les utilisateurs ont des attentes…

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

      Dans ce cas, ce n’est pas la bonne façon, à mon avis. jQuery est un produit libre et ouvert. Tout le monde peut y apporter sa contribution, faire des demandes, des suggestions et même proposer du code. Je pense que c’est un moyen plus simple et plus intelligent que d’aller carrément reprendre toute la lib pour la diviser d’un bout à l’autre. ça peut marcher mais ça me semble un peu bourrin pour l’idée. En tout cas oui, l’équipe a réagi et construit une version allégée en envoyant des fonctionnalités dans des plugins. Ce qui est à mon sens plus intelligent qu’un constructeur personnalisé.

  • http://tutos-django.com Guillaume

    Bonjour, je suis d’accord avec ce que tu écris Mathieu.
    Je vais simplement faire un hors sujet : est-il possible que les Français écrivent bibliothèque à la place librairie..
    Library = bibliothèque -> une collection d’outil et non un endroit où l’on va acheter des outils.

    Désolé, mais ça me sortait par les yeux ^^ »

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

      Je vais essayer de préserver tes yeux à l’avenir 😉

  • Elo

    Je ne suis pas d’accord : vous partez de l’idée que tout le monde utilise Jquery pour mettre en avant cette bibliothèque au sein des navigateurs.

    Ayant développé mes propres routines JS, je n’utilise ni Prototype, ni Jquery, ni Mootools. J’ai un code plus propre, en français, commenté et mieux compressé que Jquery puisque j’ai tout réalisé de A à Z : la bib avec ses commentaires, la fusion, la suppression du code mort, le lint, l’obfuscation, la compression…. J’ai un final un seul fichier de quelques dizaines de Ko pour plus de 250 Ko de code. Faites un Lint sur Jquery et vous verrez le résultat.

    Et donc pourquoi privilégier une bib plutôt qu’une autre ? Parce que Jquery est à la mode ? Il y a 5 ans, c’était Prototype et dans 5 ans, ce sera peut-être autre chose.

    Je suis pour la concurrence. Qu’on arrête de croire que le monde entier tourne autour de son nombril et qu’il faille se LIMITER à ce que certains utilisent (même s’ils sont nombreux).

    Les CDN ont l’inconvénient de placer une partie du code du site sur un autre avec du coup le pb des délais avant de localiser le serveur, des pb si le fichier est absent ou le serveur indisponible. CONSERVER LE CONTROLE DE SES DONNEES : un site DOIT fonctionner même si Google tombe ou Facebook s’arrête. Faire mieux que les des autres en étant indépendant, telle est ma devise !

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

      Je crois qu’on s’est mal compris. Je parle effectivement de jQuery, mais c’est pour l’idée de jquip. C’est à dire que l’idée d’utiliser un CDN vaut aussi pour Prototype, ExtJS, Mootools et ainsi de suite pour toutes les libs. J’ai pas été clair là dessus, je te le concède.

      Par contre, pour les CDN, l’un des commentaires précédents suggèrent justement d’utiliser les CDN mais de s’assurer aussi que cela a été efficace. C’est dans la stratégie de HTML5Boilerplate.

      Quand à ta devise, j’aime bien le principe de DIY (Do It Yourself) mais pas à ce point, je n’ai pas envie/besoin de réinventer la roue en permanence.

    • Marwan

      personnellement je pense que refaire la roue est inutile 😉

      • Elo

        « refaire la roue est inutile » -> La réponse classique… Ca veux dire que tu refuses le progrès ou toute évolution ? Tu aurais donc dit à J. Resig de ne pas écrire Jquery parce qu’il y avait déjà Prototype ? Heureusement pour lui qu’il a osé réinventer la roue.

        Je préfère savoir comment ça marche (j’ai codé ma bib AVANT de connaître l’existance de Jquery) et créer mes propres programmes plutôt que d’utiliser des outils sans comprendre comment ils fonctionnent (combien savent comment fonctionne une animation JS ou une recherche dans le DOM ?).

        Dernièrement, j’ai créé un outil de blog pour un site alors que WordPress existe. Bizarre, non ? Sauf que j’ai ainsi gardé le contrôle de mes données et j’ai réalisé des fonctionnalités spécifiques (bon, j’en ai plein qui n’existent pas sur mon outil de blog aussi, mais je n’en ai pas l’utilité), tout en restant simple à comprendre : avez-vous déjà ouvert la BDD de certains CMS (EZPublish par exemple) ? Et bien c’est pas joli-joli si on veux apporter des évolutions. C’est d’une lourdeur (et en chargement aussi d’ailleurs). Je suis resté sur une BDD simple, sans éclater une donnée dans 3 tables. Si certains connaissent Magento, c’est pas mieux. Obligé de payer un serveur dédié pour le faire fonctionner correctement (ils le disent eux-mêmes).

        Pour info, ma bib JS est + rapide que Jquery (ça ne se voit pas sur quelques anims mais si j’anime 200 objets en temps réel, y’a pas photo) et plus courte (quelque Ko). Et je ne suis pas dépendant des autres.

        Mais chacun est libre de faire ce qu’il veut : de suivre la masse et de ne pas créer, d’installer WordPress et Jquery… Ou alors d’innover et de comprendre le système, sachant que l’un des points les + importants, c’est la maintenance, la perénnité. Quand on a fait un outil, ce point est plus simple.

        • https://github.com/DrBenton Dr. Benton

          Même s’il peut effectivement être très intéressant de créer soi-même son « jQuery-like » lorsqu’on débute (c’est d’ailleurs ce que nous faisions tous, chacun dans notre coin, avant l’apparition des premiers frameworks Javascript populaires comme Prototype), l’utilisation d’un « standard » comme jQuery/Mootols/Prototype/… a tout de même de sérieux avantages, comme :
          * Un code qui a été testé sous de très nombreuses configs et dans de nombreux cas de figure. Même si tu as produit des tests unitaires sur ta bibliothèque perso, tu ne pourras vraisemblablement pas à toi tout seul égaler ce niveau de qualité de code – surtout pour du Javascript, avec la très grande diversité des comportements des navigateurs !
          * Lorsqu’un nouveau développeur rejoint ton équipe, il est tout de suite opérationnel car il a quasiment forcément déjà travaillé avec la bibliothèque « standard » que tu utilises. Si c’est une bibliothèque perso, il va falloir au préalable qu’il apprenne à l’utiliser, et l’expérience qu’il aura acquis sur cette bibliothèque après avoir travaillé dessus ne lui servira à peu près à rien, puisque toi seul l’utilise et qu’il ne travaillera vraisemblablement plus dessus. Il ne peut pas non plus arguer de cette expérience lorsqu’il recherchera un nouveau job ou une nouvelle mission.

          Concernant le code en français, j’ai essayé d’en faire lorsque j’ai commencé à développer, mais ça n’est pas pratique du tout, et même si je suis pour la préservation de cette langue il ne faut tout de même pas se voiler la face, le développement informatique ça se fait en anglais – ne serait-ce que parce que la grammaire du langage de programmation que tu vas utiliser est en anglais, et que tu vas donc forcément avoir des mots anglais au coeur de ton code.

          Ta bibliothèque est-elle publiée en Open Source, par exemple sur GitHub ? Si c’est le cas, c’est déjà ça, ça peut permettre à d’autres personnes de profiter de ton travail, voire peut-être même d’y ajouter leur pierre pour l’améliorer avec toi.
          Si en revanche elle est privée et destinée à ton seul usage, personnellement je ne vois vraiment aucun intérêt à créer sa propre bibliothèque Javascript « à la jQuery », sorti de l’apport didactique au début de sa réalisation. Mais ça n’est que mon humble avis ^_^

          Pour revenir au sujet de jQuip, en ce qui me concerne lorsque le poids de l’application sur laquelle je travaille est critique, j’utilise Zepto, qui imite les portions les plus utilisée de l’API de jQuery, pour seulement 5-10ko.
          Et si en cours de développement je m’aperçois que Zepto ne suffit pas, je repasse alors à jQuery en toute simplicité, le reste de mon application ne voyant pas la différence en raison de cette même API.
          > https://github.com/madrobby/zepto

          (le populaire framework MVC Backbone.js, par exemple, gère aussi bien Zepto que jQuery)

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

            Tout à fait d’accord concernant la première partie et merci pour le partage à propos de Zepto que je ne connais pour ainsi dire pas du tout. Faudrait que je prenne le temps de tester Backbone sérieusement aussi…

          • Elo

            Ca me fait sourire de voir que tu parles de qualité de code que je ne pourrais égaler. Tu présumes donc que je suis plus mauvais que les autres. :)) 20 ans de programmation et lire ça, ça fait plaisir.

            Allez, fais un Lint sur Jquery et on en rediscute ? Tous mes codes JS ont zéro erreur sur ce test car je les vérifie en cours de route. Quand à la compatibilité entre navigateurs, faut pas pousser, il y a des différences, certes, mais elles tendent à disparaître. Et pour info, j’ai une machine virtuelle dans laquelle sont installés plusieurs navigateurs (Chrome, IE7, IE8, IE9, Firefox, Safari, Opera…) afin de faire mes tests.

            « Si c’est une bibliothèque perso, il va falloir au préalable qu’il apprenne à l’utiliser »
            « Il ne peut pas non plus arguer de cette expérience lorsqu’il recherchera un nouveau job »
            –> On parle de JS. Il ne s’agit pas d’inventer un nouveau langage, c’est du Javascript et mon code est bcp plus proche du JS standard (qui, est, comme son nom l’indique, le standard !) que Jquery. Si tu connais le standard, tu sais tout.

            Pour le choix du français, j’admets que ça se discute mais quand on est habitué à avoir les mots clés en anglais, c’est très pratique de voir les fonctions perso dans une autre langue. C’est du coup plus rapide de cerner ce qui est standard de ce qui ne l’est pas. Par exemple, sais-tu d’un seul coup d’oeil que getAttributeNode et createAttribute sont des mots clés JS et non pas perso ?
            Le pb est pour l’export pour d’autres utilisateurs mais c’est très facile d’écrire en JS une bib multilangue.

            Le gros inconvénient de Jquery est une syntaxe confuse. Trop courte parfois, souhaitée proche du CSS, avec des appels enchaînés sans grande logique fonctionnelle et des objets prototypés non standards au JS.

            Tout ça est déconcertant pour un vrai programmeur, travaillant avec des objets. C’est bien pour les néophytes (graphistes par exemple, qui ne connaissent rien à la programmation) mais c’est (ou sera) un gros pb pour les développeurs qui doivent maintenir le code.
            Pour Zepto, c’est bien mais je préfère largement un analyseur de code mort qui crée un paquet JS. Je trouve ça plus intelligent de supprimer les fonctions inutilisées de la librairie plutôt que de jongler entre les librairies ou se trimbaler 150 Ko de code inutile.

            Concernant le libre, non, ce n’est pas le cas. Peut-être un jour mais je ne suis pas vraiment pour ce modèle « économique » car trop peu rémunérateur et trop destructeur de revenus (même si je suis bien content de trouver gratuitement certains logiciels).

            Quant à l’intérêt de le faire soit-même, je l’ai déjà expliqué : en ce moment même se préparent d’autres logiciels que ceux existants. Tu ne vas pas leur dire que ça ne sert à rien parce que tu te limites à un autre ? Ils s’en fichent, il s’agit d’évolution et de concurrence. Pourquoi avoir réalisé Chrome ? Firefox, IE et Opera existait déjà ! Et pourtant Chrome a apporté certaines choses (moins lourd que Firefox, plus de notoriété qu’Opera).

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

            Je persiste sur le fait que niveau qualité, jQuery se place à un haut niveau. Même avec 20 ans d’expérience, on continue de faire des conneries, ça fait partie de la nature humaine. La force d’une équipe comme celle de jQuery mais aussi de beaucoup d’autres (voire presque toutes), c’est que, justement, c’est une équipe. Avec des mecs qui passe les uns derrière les autres, qui se relisent, qui se corrigent et qui partagent leurs idées. La qualité de code passe aussi et surtout par là.

            En ce qui concerne ta remarque à propos des « vrais » programmeurs, j’ai limite hésité à virer cette partie de ton commentaire voir à carrément refuser ton commentaire. Ce genre de troll/propos n’a pas place ici et je me sens limite insulté de ne pas être vu comme un vrai programmeur parce que j’aime coder avec jQuery. Pourtant je suis un vrai programmeur et la poo ne m’est pas inconnue.

            Quand au fait de faire soi-même, ton point de vue peut se défendre même si pour moi, à minima, ton exemple ne tient pas la route. Avec Chrome, Google a fait plus que faire un nouveau navigateur. Il l’a blindé de ses propres outils. Recherche instantanée intégrée, synchro via compte gmail, gestion des applications chrome etc… L’outil est bien plus riche que la simple considération de « navigateur ». Chaque navigateur actuel est plus que ça et il y a un intérêt réel à en faire un, plus que d’être un énième concurrent.

Articles liés