Logo_jQuery

Réaction à « jQuery toujours pas pour moi »

Flattr this!

Il y a peu, dans ma chronique hebdomadaire sur jQuery, je parlais d'un billet de metal3d où il critique ouvertement jQuery. De façon plutôt réfléchie d'ailleurs. Je vais donc répondre ici à son billet. Evidement j'ai choisi de défendre les couleurs de jQuery, mais pas que. Certains de ses arguments ne peuvent être remis en cause puisque cohérents. Dernière précision, dans les commentaires de la chronique, on m'a demandé si ces points avaient été abordés par l'équipe. Honnêtement, je n'en sais rien mais je suppose que oui.

Sémantique

Premier point abordé, voici deux lignes :

$('#element').load(handler);
$('#result').load('ajax/test.html');

Le reproche qu'il aborde est assez simple et pour le coup, très justifié. La première ligne est un alias (voir doc) de :

.bind('load', handler)

Quand à la deuxième ligne, elle sert à charger le fichier ajax/test.html (voir doc).

Le problème ici est donc que sur un élément, avec une seule méthode, on peut aussi bien attacher un évènement que charger un fichier. "c'est absurde et pas propre", je le cite. Et je suis d'accord avec lui. Il y a bien trop d'alias dans tous les sens dans jQuery. Ça encourage les mauvaises pratiques, ce n'est pas cohérent, et ça alourdit pour rien le framework.

Terminologie hasardeuse

L'auteur signale ceci :

$('.class-element').css('color','red')

Ici on change le CSS de class-element. Si on veut être vraiment respectueux des termes, on devrait dire "je change le style de class-element". Certes, il chipote mais à raison. C'est grâce à ce genre d'erreurs qu'on se retrouve avec des librairies au lieu de bibliothèques ou des expressions régulières et non rationnelles.

Cependant, point plus important, l'auteur soulève un autre point. C'est l'attribut style qui est affecté et non la feuille de style. Il trouve ça choquant. Je dis que ça me semble plutôt normal. Certes, touché au DOM, c'est pas terrible, mais c'est dû aux limitations de JavaScript. Si je ne me trompe l'instruction JS native fait la même chose :

var element = document.getElementById('id-element');
element.style.backgroundColor = "black";

Pour moi ce point est clairement une méconnaissance de l'API DOM (à la condition bien entendu que je ne me trompe pas sur mon contre-exemple).

Pour terminer sur le point de la terminologie, l'auteur soulève le point qu'avec jQuery, vous pouvez faire de l'Ajax Synchrone (voir propriété async). Ce qui est effectivement un non-sens face à la définition de l'acronyme Ajax : Asynchronous JAvascript Xmlhttprequest. Nous aurions donc des requêtes asynchrones synchrones. Et c'est effectivement possible en jQuery. Je n'en ai jamais eu l'usage puisque c'est bien un non sens. Cependant, depuis jQuery 1.8, cette capacité est devenue deprecated.

Coté terminologie, je suis d'accord avec une partie de ses reproches, certains les trouveront mineurs, mais après tout, quand on voit des gamins prétendument "experts web" débarquer et affirmer avoir appris le langage jQuery plutôt que le JavaScript, finalement, mieux vaut être tatillon.

Sélecteurs illogiques

Ici le grief principal de l'auteur, c'est que lorsque vous sélectionnez un élément par son id, vous récupérez quand même une collection d'éléments. Alors certes, une collection avec un seul élément, mais une collection quand même. C'est vrai que c'est un peu débile. Mais d'une certaine façon, je suppose que ça permet une mise à plat des sorties du sélecteur. Plutôt que sortir un coup un élément et le coup d'après sortir une collection, autant tout le temps sortir une collection.

Vu la façon de créer des plugins pour jQuery, c'est là que ça prend tout son sens. Vos méthodes s'applique à tous les éléments sélectionnés, qu'ils soient un ou plusieurs. Plutôt que de devoir chercher d'abord si c'est une collection ou non puis d'y appliquer un traitement. C'est une façon de voir les choses qui peut se défendre même si l'auteur n'a pas tort, il y a un paquet de cas où c'est débile.

Pas de rose sans épine, cette façon de faire à ces défauts parfois douloureux mais un paquet de cotés pratiques. Après il est vrai que ça peut induire des débutants en erreur, faisant croire qu'on peut avoir une collection d'éléments ayant le même ID. Ça c'est pas terrible.

Précisons dans cette partie, quitte à chipoter, que le moteur de sélection de jQuery s'appelle Sizzle et est indépendant de jQuery. Dans la théorie, parce que peu d'autres frameworks s'en servent et Sizzle est développé par des membres de la core team de jQuery...

4 méthodes, 2 comportements, aucune logique DOM

Dans la sélection sous jQuery, on dispose de find, children, parent et parents :

  • Find peut chercher via sélecteurs dans tous les enfants et dans toute la profondeur des arborescences une collection d'éléments correspondants ;
  • Children cherche de façon similaire mais uniquement dans le premier niveau d'enfants ;
  • Parent vous retourne l'élément DOM parent de votre élément courant, mais dans une collection (même problème qu'au dessus) ;
  • Parents va fouiller dans les éléments parents ceux correspondants à votre sélecteur.

Pour l'auteur, children et parents sont sémantiquement les compléments mais pas dans leur fonctionnement. Là honnêtement, je ne sais trop quoi dire. Peut-être trop de méthodes ? Peut-être devrait-on juste pouvoir fixer le nombre de niveaux de DOM pouvant être franchis ? Plutôt que d'avoir 4 méthodes nommées de façon assez sémantiquement incorrects.

Autre point beaucoup plus "critique" à mon sens, l'auteur suggère le code HTML incorrect suivant :

<!-- on fait n'importe quoi -->
<span id="foo">
    <div id="toto">toto 1</div>
    <div id="toto">toto 2</div>
    <div id="toto">toto 3</div>
    <div>
         <span id="toto">un span toto 4</span>
    </div>
</span>

Exécutons maintenant ces instructions :

console.log($("#toto").length) // 1
console.log($("#foo").children("#toto").length) // 3
console.log($("#foo").find("#toto").length) // 4

On peut le voir le résultat fait peur. Ici on découvre que children et find ne savent pas que des ID sont forcément uniques. Je suis d'accord avec metal3d, ça craint. Saut si on admet qu'une situation aussi conne finalement n'est que la responsabilité du développeur. Ça lui apprendra à coder avec ses pieds. Le problème de réagir comme ça serait qu'on ne décourage pas vraiment les mauvaises pratiques ...

Tout passe par $, merci la POO

Bon là on ne peut que le lui accorder, $ c'est l'élément magique dans jQuery, le MacGiver du framework. Et c'est vrai aussi avec Prototype si je ne me trompe pas (l'auteur prétend le contraire ceci dit). Je n'ai pas le souvenir de "classes" dans Prototype. Est-ce que la volonté de réduire au maximum le nombre de variables globales n'a pas été poussé un peu trop à l’extrême ?

On perd en respect de la POO pour gagner en simplicité d'écriture. Ceci dit, le terme "classe" est un non sens à lui seul en JS. Le langage lui-même ne s'embarrasse pas de cette notion, pourquoi vouloir la simuler, alourdir un framework et tromper les développeurs sur la réalité du langage plutôt que simplement coller aux concepts de celui-ci et au passage éduquer les développeurs.

Il donne un exemple sous Mootols qu'il trouve plus propre :

$("element").addEvent('click', function (){
    this.setStyle('color','red')    
});

Auquel je réponds avec la version jQuery qui ne me semble pas plus sale :

$("element").on('click', function (){
    $(this).css('color','red');
});

Masquage du JS

Effectivement, jQuery cache pas mal le JS natif, et c'est vrai, il y a des cas où c'est pas terrible, mais il y a quand même pas mal de cas où son coté polyfill est très pratique. Clairement, si on veut apprendre le JS en apprenant directement jQuery, on risque fortement de finir dans le mur en mélangeant les deux. Mais quand on connait déjà bien le langage, on peut vite en arriver à savoir quand utiliser le framework ou non. Encore une fois, c'est une question d'apprentissage du langage avant l'apprentissage d'un framework. Pour moi, cette critique convient à TOUS les frameworks dans tous les langages. Dans une mesure plus ou moins importante.

Une note positive quand même ?

Je suis d'accord avec lui sur le fait que faire une grosse appli avec jQuery, ça peut vite virer à l'enfer du coté de la maintenabilité.

Par contre, que tous les frameworks oublient la puissance du JS et du DOM, cette affirmation n'est plus vraie depuis la sortie d'AngularJS qui remet en avant le DOM. Et accessoirement qui éjecte notamment Sizzle de jQuery tout en se servant de ce dernier pour un paquet de méthodes de manipulation du DOM.

Autre critique de sa part : beaucoup de choses sont faites avec JavaScript/jQuery alors qu'elles pourraient être faites avec CSS. Il a raison. jQuery UI est un bel exemple de bonne grosse prise de tête parfois. Pour le coup, j'y préfère les éléments simplistes de Twitter Bootstrap. Les gars, quand vous faites vos applis, ne faites pas tout en JS, pensez aussi au CSS. En gros, refourguez le boulot d'intégration à l'intégrateur et restez des développeurs 😉

###

Voilà, j'espère avoir apporté une réponse constructive à son article. Comme promis, il y a des choses où je suis d'accord, d'autres non. L'idée est de rester objectif. jQuery est un bon framework mais vous ne devez pas le voir comme le meilleur. Il y a des cas où il est très utile, des cas où on pourrait s'en passer en forçant un peu, des cas où il est clairement inutile. Comme tout framework. Le conseil reste simple et toujours le même quand ils 'agit de dev : ne faites pas les idiots, soyez pros, réfléchissez à ce que vous allez faire avant de le faire.

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

    Le problème ici est donc que sur un élément, avec une seule méthode, on peut aussi bien attacher un évènement que charger un fichier. « c’est absurde et pas propre », je le cite. Et je suis d’accord avec lui. Il y a bien trop d’alias dans tous les sens dans jQuery. Ça encourage les mauvaises pratiques, ce n’est pas cohérent, et ça alourdit pour rien le framework.

    Si je ne dit pas de bêtise et si j’ai bonne mémoire, je pense que ce genre d’alias poubelle va disparaitre lors du grand nettoyage prévu pour la version 2 en espérant qu’ils ne vont pas balayer trop de chose.

    Autre critique de sa part : beaucoup de choses sont faites avec JavaScript/jQuery alors qu’elles pourraient être faites avec CSS.

    Je suis 100% d’accord tout faire avec JavaScript/jQuery est une très mauvaise pratique, avec les css on fait pas mal de chose et plus est en css3 c’est d’autant plus amusant, même si la compatibilité doit être importante.
    Je suis contre l’idée de rester compatible avec des navigateurs complètement dépassés, la plupart sont gratuit et ne nécessite qu’une chose (un téléchargement et une installation).

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

      Le problème de la 2.0 et de son grand nettoyage, c’est justement cette perte de compatibilité. Typiquement, dans ma boite, on ne basculera pas dessus avant un long moment après sa sortie. Le retrait du support d’anciennes versions de IE est un très gros problème pour nous.
      Autant en interne et donc sur un environnement technique maîtrisé, on sait que toutes les machines disposent des dernières versions de Chrome et de Firefox. Mais coté clients, sur la partie non-connectée, on a quand même pas mal de logique JS (des formulaires essentiellement). On doit gérer tous types d’écrans. On a de tous les navigateurs, y compris des IE 6.
      Exemple : J’ai bossé pour un très gros éditeur de logiciels (Dassault Systèmes, plusieurs milliards de CA, plus gros éditeur français) et le seul navigateur officiellement supporté il y a encore 3 ans était IE 6. Pourquoi ? La raison est simple. Toutes les applis, tous les systèmes de sécurité ont été pensé à l’origine pour IE 6 (certains trucs ont plus de dix ans d’ancienneté). Migrer vers un autre navigateur ou une nouvelle version implique la vérification de tous les systèmes, tous les logiciels, la formation des employés (on était plusieurs milliers dans une bonne quinzaine de pays de mémoire). C’est un coût énorme. Donc pas forcément prioritaire, surtout en « temps de crise ».

      • DamsFX

        Rien n’empêche de faire cohabiter 2 navigateurs.
        J’invite mes clients « liés » à IE6 par leur application métier à installer en // un navigateur moderne pour leur surf quotidien (si possible – pas du IE).
        mon snippet préféré :

        Votre navigateur est obsolète !
        Afin de profiter pleinement des fonctionnalités de ce site, nous vous invitons à installer un navigateur récent ou à installer Google Chrome Frame.


        Ensuite il faut aussi éduquer les clients et bien leur faire comprendre que des compromis sont à faire entre compatibilité et modernisme (fonctionnel ou visuel)

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

          On est d’accord sur la possibilité de travailler avec deux navigateurs. Mais, encore une fois, la capacité à convaincre un client ou DSI dépend de sa taille. Il y a beaucoup de boites qui font clairement les feignasses. Mais d’autres boites où ça n’a rien de simple du simple fait de la taille de la boite et où tout le monde ne peut techniquement/intellectuellement pas mettre la main à la pâte pour installer un autre navigateur. D’où l’idée à mon sens, que la mise à jour auto silencieuse des navigateurs est une bonne chose. Y compris pour IE 9 qui est sincèrement un bon navigateur si tu ne penses pas développer dessus (l’utilitaire de débogage mérite encore du travail).

          • DamsFX

            tout le monde ne peut techniquement/intellectuellement pas mettre la main à la pâte pour installer un autre navigateurLOL ;o)
            Pour IE9, je suis effectivement content d’avoir un utilitaire de débogage intégré qui est au moins le mérite d’être là – ça fait gagner du temps – que je perds aussitôt à déboguer pour les plates-formes mobiles !! :o(

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

            C’est vrai que les plateformes mobiles, ça manque encore mais bon, ça va venir avec le temps. Ceci dit, sur IE 6 et +, t’avais un outil pas trop mal qui s’appelle la DebugBar qui compensait pas mal les manques. Mais bon, forcément, comparé à un Firebug ou mieux à un Dev Tools, il ne casse pas des briques. Adapté au niveau du navigateur auquel il est rattaché, ce qui est déjà pas mal.

  • http://www.yrezgui.com Yacine Rezgui

    Je te rejoins dans tous les points.
    Mais depuis que je développe avec AngularJS (il n’y a pas à dire, c’est vraiment mon coup de coeur du moment), je reviens de plus en plus vers du JS Vanilla. QuerySelector facilite beaucoup la tâche (à voir si à l’avenir, on pourra ajouter des sélecteurs personnalisés comme avec jQuery) et aussi du fait que les navigateurs modernes ont de plus en plus de part de marché.
    Pour te dire, je suis en train de développer une webapplication et j’ai fait le choix de zapper complètement les navigateurs < IE9.

  • Reivax

    Je ne suis pas trop d’accord avec ton contre argument sur l’utilisation de de la méthode .css dans « terminologie hasardeuse ».

    Tu dis qu’en javascript on fait la même chose, oui, sauf qu’en javascript, la propriété est bien ‘style’ quand on écrit :
    element.style.backgroundColor = « black »;

    en JQuery, au lieu d’écrire
    $(‘.class-element’).css(‘color’,’red’)
    il serait mieux d’écrire
    $(‘.class-element’).style(‘color’,’red’)

    Là on saurait de quoi on parle… On change le style, pas la style sheet.
    C’est un parfait exemple de terminologie hasardeuse :)

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

      Il est vrai que vu comme ça, c’est un peu foireux. Ils ont voulu aller à l’économie de caractères, ça induit quelque peu en erreur.

  • http://blog.escarworld.com rivsc

    Je vais citer mon commentaire de metal3d.org par rapport aux collections retournées par le selecteur jQuery.

    Que devrait-il se passer si aucun élément n’était matché ? Undefined plutôt que [] ? Du coup le chainage de fonction pèterait.

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

      Là retourner une collection vide à un sens. A mon humble avis. Non seulement parce que ça péterait le chaînage, même si il est à la responsabilité de chacun de vérifier ce qu’il fait au fur et à mesure de sa progression. Mais aussi parce que techniquement, aucun résultat ne veut pas dire qu’une collection vide est un non-sens.

  • http://jelix.org Laurentj

    Pour continuer sur les histoires de terminologies :

    >Pour moi ce point est clairement une méconnaissance du langage

    Sauf que le DOM n’est PAS un langage, tout comme DOM n’est PAS Javascript. DOM est une API. Javascript est un langage. Et DOM n’est pas spécifié dans le langage Javascript.

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

      Tu as totalement raison. J’ai édité l’article en conséquence même si ça ne change pas le fond de ma réponse.

  • http://manu.habite.la/ Leimi

    Le coup des alias et des noms de fonctions qui peuvent induire en erreur je suis d’accord. Après, le comportement illogique devant un code totalement erroné, c’est vraiment, vraiment chercher la petite bête 😉

    Après, pour la comparaison avec Prototype, faut avoir en tête que les 2 bibliothèques n’ont pas vraiment le même bagage. Prototype est un réel framework qui te facilite la vie pour le DOM mais aussi dans ton code en général avec bcp de méthodes ajoutées pour les tableaux, les objets, etc.. et oui, il t’aide un peu à structurer ton code avec les classes faciles à créer. Prototype se suffit à lui même.
    jQuery se contente plutôt de te faciliter (grandement :p) la vie avec le DOM et pas beaucoup plus. Si tu veux un peu d’aide côté fonctionnel, il faudra le coupler à Underscore pour toutes ses fonctions bien pratiques qu’on retrouve dans Prototype. Si tu veux plus de structure, pourquoi pas ajouter Backbone.

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

      Sur le comportement illogique face à un code erroné. Je t’avoue ne pas savoir quel camp choisir. D’un coté il en va de la responsabilité de chacun de faire son boulot correctement et donc de ne pas se mêler des affaires des autres. Mais de l’autre coté, en tant qu’outil populaire et très souvent utilisé comme aide à la formation, assister l’utilisateur en lui signalant qu’il fait n’importe quoi ne me semble pas dénué de sens non plus.

      Pour ton deuxième paragraphe, on en vient encore au fait que oui, effectivement, jQuery n’est pas meilleur que Prototype et inversement. Tout dépend de ce dont on a besoin. Clairvoyance que n’ont pas tous les développeurs… malheureusement.

  • http://www.1adesign.fr/index.php Vivien

    > Autre critique de sa part : beaucoup de choses sont faites avec JavaScript/jQuery alors qu’elles pourraient être faites avec CSS

    Oui sauf que le support des CSS est tellement aléatoire que c’est souvent bien plus sûr de passer par jQuery pour des effets un peu complexes (je parle pas d’attribuer un background-color hein). D’où son utilisation abusive dans ce genre de cas, forcément. :)

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

      Comme pour tout, on en revient toujours au même problème, l’incapacité à atteindre le juste milieu 😉

  • https://twitter.com/cGuille cGuille

    Bonjour :)

    Attention, j’ai l’impression que l’un comme l’autre, vous avez mal compris cette histoire de synchrone / asynchrone.
    Il faut bien avouer que c’est trompeur, mais cela désigne deux choses différentes.

    Le asynchrone de AJAX fait référence au caractère asynchrone de la requête HTTP : il s’agit de faire une requête sans recharger la page.

    Or, le synchrone / asynchrone proposé par jQuery (mais aussi par l’objet XMLHttpRequest natif, cf. le paramètre « async » de la méthode open()) fait référence au caractère synchrone ou asynchrone de la fonction qui lance cette requête.

    Ce n’est donc pas du tout incohérent de parler de requête AJAX asynchrone, même si cela parait étrange. Ce n’est pas un non-sens comme vous l’avez dit tous les deux.

    Bon, AJAX reste une terminologie douteuse de toute façon (pourquoi ils ont foutu XML dans le nom ? Même chose pour XMLHttpRequest).

    Cordialement.

    • https://twitter.com/cGuille cGuille

      Erratum: Dans mon précédent commentaire, il fallait bien évidemment lire « parler de requête AJAX synchrone » et non « parler de requête AJAX asynchrone », bien que cela soit également correct.

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

      Pourquoi XML ? Parce qu’originellement tes retours étaient obligatoirement formatés en XML. Mais ça a très vite changé. Quand à ta remarque, elle est juste mais la preuve en est que si même moi qui utilise plus qu’activement jQuery depuis des années continuent de régulièrement d’en oublier ce principe, c’est bien qu’il y a un problème.

      • https://twitter.com/cGuille cGuille

        Quand à ta remarque, elle est juste mais la preuve en est que si même moi qui utilise plus qu’activement jQuery depuis des années continuent de régulièrement d’en oublier ce principe, c’est bien qu’il y a un problème.

        Et quel est ce problème ? Ça ne serait pas juste que tu n’utilises jamais cette option ?

        Ce « problème » (si il y en a un) n’a de toute façon aucun rapport avec jQuery. La méthode ajax() est une surcouche à l’utilisation de XHR, il est 100% logique et sensé qu’il offre les possibilités de XHR.

        C’est quand-même fou que je me retrouve à défendre jQuery, mais là-dessus il n’y a vraiment rien de choquant.

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

          J’avoue n’en avoir jamais eu l’usage. Après oui, on est d’accord qu’il est parfaitement logique que ajax() offre tout ce qu’offre XHR.

          • Boucman

            Un petit exemple d’utilisation.
            J’ai un formulaire que je valide avec jQuery Validate et j’ai besoin de faire un validation côté serveur et dans ce cas le synchrone est obligatoire.

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

            Tu ne t’y prends pas de la bonne façon là, de mon point de vue. Le bouton submit est à oublier quand on dev avec Ajax. Il est plus logique de mettre un bon vieux bouton avec une fonction qui réagira au clic. Celle-ci informe l’utilisateur que le traitement de son formulaire est en cours, lance la requête et s’arrête. Le callback de la requête en cas de succès déclenche le submit du formulaire. Comme ça pas de risque d’erreur dans ton code JS qui accepterait un submit non désiré pour un bogue dans le code de la première fonction.

  • http://kyoku57.org Kyoku57

    Je suis content de te voir dire que le concept de classes est assez étranger à Javascript. N’empêche que beaucoup de frameworks et librairies tentent systématiquement d’offrir des méthodes de conversion pour passer des classes aux prototypes (Dojo, Classy, etc …). Pourtant, l’effort pour passer de l’un à l’autre n’est pas insurmontable : deux/trois pièges à éviter mais on peut très bien s’en sortir une fois compris.

    Faire de la POO avec JS, c’est un peu comme si tu achetes un appareil à raclettes, pour y faire cuire des steaks .. bon, tu peux, mais ce n’est pas trop fait pour à l’origine.

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

      La POO « classique » (soit classes, interfaces, …) soyons clairs sur les termes. Parce que JavaScript reste un langage objet, prototypal mais objet. Et on est d’accord, l’effort n’est pas très important pourtant.

      • http://kyoku57.org Kyoku57

        Tu fais bien de préciser, tu as raison 😉

  • http://www.geek-directeur-technique.com Amaury

    Concernant l’AJAX synchrone, il y a effectivement une légère incompréhension quant au caractère asynchrone de cette techno − comme cela a déjà été dit en commentaire.

    Maintenant, à quoi ça peut bien servir concrètement ? J’ai un exemple.
    Sur les sites que nous réalisons dans mon entreprise, les pages chargent un unique fichier « load.js ». Dans ce fichier, il y a une série d’instructions $.getscript() qui servent à charger un fichier JS chacune. Comme l’ordre de chargement des fichiers JS est important, on commence par activer le chargement synchrone (qui est désactivé à la fin du fichier).
    En production, le contenu de ce fichier est remplacé par un concaténation minifiée des contenus de tous les fichiers JS. Comme ça, un seul fichier est chargé par le navigateur.
    Mais pour le développement, c’est super pratique d’avoir chaque fichier chargé individuellement.

    Donc voilà un bon exemple qui montre que l’AJAX synchrone peut être utile (parce que, encore une fois, on a un objet par fichier JS, et pour la gestion des namespaces il est important que les fichiers soient chargés dans le bon ordre).

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

      J’ai mis en place une solution un peu différente pour le chargement des scripts selon l’environnement.
      En fait, j’ai conçu un outil de build qui a pour instruction en développement de seulement concaténer les fichiers dans l’ordre souhaité. Pendant qu’en production, il minifiera après avoir concaténé. En développement, l’outil ajoute au fichier de sortie des commentaires indiquant notamment le nom du fichier avant chaque fichier intégré. Ainsi, on peut à la fois garder l’idée de l’ordre, en ayant un seul fichier et tout en pouvant déboguer très facilement.

      • jbdemonte

        gruntjs est la pour ca :)

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

          J’essaie de passer carrément à Yeoman mais pour le moment, j’ai un souci avec l’installation de Phantom qui bloque tout le bazar.

          Et on est en train de transiter pas mal de choses du coup on a maintenu un existant pour ça. Histoire de pouvoir se concentrer sur d’autres trucs encore plus critiques. Oui, on remonte de très loin mais on industrialise un maximum^^

          • jbdemonte

            😀 je connais ce probleme d’industrialisation de vieux trucs 😀
            Pb avec Phantom ? etonnant, mail moi en cas

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

            Faut que je réessaie, j’ai pas eu le temps depuis l’époque où c’est sorti :s

      • http://www.geek-directeur-technique.com Amaury

        Oui, mais avec ton système, tu dois générer un fichier.
        Alors qu’avec le mien, on ne génère quelque chose que lorsqu’on met en production. Ce qui fait que pour développer, on peut modifier tous nos fichiers JS sans avoir besoin de lancer une commande particulière à chaque fois. C’est quand même très pratique.

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

          Je dois admettre que mon process de build est un poil plus long du coup quand on est en dev. Ceci dit, avec PHPStorm, je t’avoue que je le vois à peine passer. Juste une commande différente de Ctrl+S à passer 😉

  • Olivier El Mekki

    Ma réponse à cet article : https://gist.github.com/oelmekki/3994312

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

      Hello ! Vu, je le lis aussi tôt que possible. En tout cas, il est très intéressant que la discussion continue :)

  • dcz.switcher

    Totalement d’accord avec la remarque sur l’utilisation du CSS qui doit être préférée au JS
    L’exemple le plus parlant pour moi est pour le layout.
    Par exemple, pour placer un conteneur à droite de la fenêtre sur une hauteur de 100%, au lieu de se jeter sur le JS avec des écouteurs sur le resize etc., un peu de CSS et ça tournera aussi bien (sinon mieux)
    après, si le site doit fonctionner sur ie7 et -, ça devient plus sportif.

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

      Plus sportif mais pas impossible, les cas extrêmes peuvent nécessiter des solutions extrêmes. Mais pas les situations « normales », on est d’accord.

  • http://www.wewereweb.be Mathieu Hautenauve

    Côté sélecteur, en plus des 4 dont tu parles, il existe aussi .closest(…), qui est l’équivalent de .parents(…) mais en sélectionnant le premier (plus proche) correspondant.

Articles liés