JQuery toujours pas pour moi

05/09/2012

Suite à un vieux post qui s’est terminé par une horde de pas mal de fans de jQuery insultants, j’ai évité de continuer à commenter et je décide de refaire un article. Deux ans se sont écoulés, et ma vision de jQuery se déteriore de plus en plus… J’ai admis certaines critiques, mes exemples n’étaient pas forcément les plus adéquats et mon entrain à défendre un point de vue n’a pas été suivi par une explication claire. Du coup, voici un point de vue plus “technique” et plus poussé sur le “pourquoi je n’aime pas du tout jQuery”

Pour appuyer mes remarques et mon avis, je vais me baser sur des discussions que j’ai eut depuis 2 ans. Que ce soit après ma conférence donnée sur JS ou avec des collègues, j’ai noté les remarques, et je vous redonne texto ce que j’ai répondu ou ce que j’ai tenté d’expliquer.

En plus de ces remarques, je vais vous montrer aussi les points principaux qui me font vraiment une poussée allergique à ce “framework” Javascript.

Sémantique

Commençons par ce qui m’orifie le plus, à savoir cette sémantique qui me fait palir.

Prenons un exemple tout bête: $('#element').load(handler)

Non mais vous plaisantez ? quand je lis ça je me dis que “load” ça charge un truc. Bha non ! là c’est l’évènement “onload” qui appelle le handler. Une sémantique pareille me choque vraiment, surtout que:

//pris de la doc... $('#result').load('ajax/test.html');

Ce coup-ci load charge bien un truc… la page “ajax/test.html” est récupéré via un XHR (XHttpRequest, et pas “Ajax”, on va y venir…) et le contenu est inséré dans l’élement…

Vous pouvez me dire ce que vous voulez, utiliser un nom de méthode pour deux opérations qui n’ont rien à voir, c’est absurde et pas propre. Vous en voulez un autre, bougez pas.

La méthode “click” par exemple. En premier lieu, moi quand je lis ce nom, je me dis “tiens c’est cool, une fonction qui simule un click”. Et j’ai pas tort en fait. Car si je fais:

$('#toto').click()

alors je simule un click. Je ne fais que répéter la doc:

“In the third variation, when .click() is called without arguments, it is a shortcut for .trigger(“click”).”

Mais si je mets un handler en paramètre, alors tout le comportement est différent, car dans ce cas la fonction “click” enregistre un “event listener”.

Deux comportements purement éloignés, qui sont bien séparés dans tous les autres framework JS. On définis plutôt une méthode “onclick” et “click” qui font deux choses bien distinctes.

Terminologie hasardeuse

jQuery a vraiment un souci avec les termes. Quand je lis le code qu’on pond, j’ai l’impression de parler comme un petit débutant qui connait rien au HTTP, HTML, CSS et JS… je vous explique.

Savez-vous ce qu’est un CSS ? Cascading StyleSheet, ce qui signifie “Feuille de style en cascade”. Autrement dit, une CSS est une arborescence qui définit des styles pour des éléments dissociés par des attributs (class, type…), des identifiants (id), des états (active, hover, visited…) et en les repérant par leur hiérarchie dans le DOM. C’est un standard clair, qui évolue.

Chaque propriété d’un élément repéré est un **style**. On est d’accord ? je l’espère… parce que les auteurs de jQuery ont une autre définition. Pour eux, un CSS est un style… Si si…

Je vous montre:

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

Vous me direz “ouais tu pousses, en fait on change la CSS pour les éléments de classe classe-element “. Non ! car:

$(this).css('border','1px solid black')

ce code change le **style d’un élément unique**, et si ça suffit pas, regardez avec Firebug ou la console de Chrome/Chromium pour vous rendre compte que l’attribut touché est “style” et **non pas la feuille de style**. Je chipotte ? si aujourd’hui vous voyez un framework dans un autre langage, pour une autre technologie que le web, je vous assure que vous seriez choqué.

Ici, on dit que “CSS” permet de modifier le style de l’élément. C’est juste une erreur me diriez-vous. Et bien non. Les auteurs de jQuery ont vraiment du mal avec les terminologies, car pour eux on peut faire du “Ajax synchrone” avec du JSON.

Rappel: Ajax = Asynchroneous Javascript And Xml

Dire que vous faite de l’Ajax synchrone, c’est comme dire que vous faites de la photo avec une toile, des peinceaux et de la peinture… c’est vrai quoi, la photo et la peinture c’est exactement pareil, on ne va pas chipoter hein !

Alors pour reprendre les choses clairement, si vous faite un appel HTTP en javascript, que ce soit synchrone ou non, avec du JSON ou non… c’est ce que nous appelons une “requête HTTP”, ou “Http Request”. C’est d’ailleurs pour cela que l’objet standard JS se nomme XHttpRequest (on dit aussi XHR), et que les autres frameworks JS l’appellent de la même manière… Mais apparement, jQuery veut se démarquer avec des termes erronnés. Ou alors, ce que je pense fortement, c’est qu’à la base jQuery faisait du HTTPRequest en mode asynchrone par défaut, et qu’un jour les développeurs se sont rendu compte qu’on pouvait faire des appels synchrones. Comme pour “css”, ils ne se sont pas posé la question et ont ajouté l’option “synchrone” à une terminologie qui veut dire “asynchrone”: Ajax.

Ce qui me choque, c’est que jQuery est arrivé après Prototype et Mootools, et eux ont fait cette distinction. Sauf qu’au lieu de respecter un standard de dénomination, les auteurs de JQuery ont décidé de prendre des termes “bateaux” pour monsieur Michu qui décide de développer sans connaître Javascript à la base. On y reviendra après.

Vous me trouvez sarcastique, je ne m’en cache pas. C’est pas aggressif, c’est juste que je tente de défendre ces idées depuis des années et que je reste dépité à entendre des gens défendre des erreurs pareils. Bref, continuons.

Sélecteurs illogiques

J’adore les selecteurs. Non là je ne suis pas ironique ! Que ce soit sur Prototype, jQuery, Mootools, etc. l’utilisation des sélecteurs me plait.

Mais… là où jQuery m’enrage, c’est cette utilisation de “\$” pour tout et n’importe quoi. Et surtout qu’il fait une chose infâme quand on bosse sur du DOM, laissez-moi vous expliquer.

On m’a par ailleurs sorti: “attend mais Xpath tu n’aimes pas ?” Mais bien sûr que si ! Je me répète, j’adore les selecteurs, mais encore faut-il que le framework sache les utiliser dans les règles. Je vous donne un exemple tout bête. Un élément peut avoir un “id” (identifiant) qui **doit être unique**. En JS pure, on utilise alors la fonction “getElementById” qui récupère **un et un seul élément**, c’est-à-dire l’élement qui a cet ID.

Avant de passer à la suite: oui merci je connais querySelector et querySelectorAll qui utilisent la même syntaxe que jQuery pour les sélecteurs, et je n’aime pas…

Revenons à mon souci: Si deux éléments ont le même ID, alors c’est une erreur de votre part. Vous devez corriger le DOM.

Sauf que voilà… JQuery ne sait pas ce que c’est que de retourner un seul élément. Il retourne toujours une collection, que l’élément soit unique (via un id) ou pas.

Alors comparer cela au comportement de Xpath, excusez-moi mais ça me fait mal ! Car Xpath retourne un élement unique et non une collection si vous sélectionnez un élément qui doit l’être. Point barre. Et querySelectorAll fait pas mieux là dessus… Cherchez pas à me vendre que le code suivant est normal:

var uid = $('#id-unique')

Ici, “uid” est une collection, avec un seul élément à l’intérieur. Inutile de me retourner une collection.

Tiens je reviens sur ce que j’ai dit, finalement querySelector est pas bête, car lui il me retourne un seul élément, et querySelectorAll me retourne une collection, je sais donc choisir entre deux cas. Ho mais attendez…

Prototype et Mootools (pour ne citer que ceux ci) font une distinction importante entre une collection et un élément, ils ont utilisé une fonction séparée pour cela:

-\$ pour un élément identifié par un id -\$\$ pour une collection, sélectionnée via des selecteurs CSS

Marrant hein, 7 ans plus tard les moteurs JS récents utilisent aussi deux méthodes de sélections: querySelector et querySelectorAll.

Mais attendez la suite, vous allez voir que pour jQuery, un élément ayant un id n’est pas forcément unique, selon le cas. C’est juste la section suivante.

4 méthodes, 2 comportements, aucune logique DOM

Qu’est ce qui est passé par la tête des développeurs de JQuery quand ils ont développé les méthodes “find”, “children”, “parent” et “parents” ?

Tout d’abord, le truc qui me choque: find et children. Le premier trouve tous les déscendants d’un élément selon un sélecteur, alors que children fait pareil mais pour **seulement le premier niveau**. Admettons, ça ne me choque pas trop jusque-là. Mais par conséquence, pourquoi “parents” peut remonter de plusieurs niveaux ? On a deux méthodes inversement liées (parents, enfants) qui n’ont pas la même logique de sélection.

Et toujours avec cette fichue collection par défant, parent() vous retourne un seul élément (normal hein) mais dans une collection…

Si ça n’était que cela, je dirai “ok, pourquoi pas, après tout c’est une dénomination”. Mais là où ça marche plus, c’est quand je vois ça:

<!-- 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>

On est d’accord que c’est une erreur, on a 3 fois le même “id”. JQuery est pas trop débile et sait que “\$(’#toto’)” retournera un seul élément, en l’occurence le premier, et à la limite ça me convient.

Mais par contre, avec children, on en a 3 !

Testez: alert($("#toto").length) alert($("#foo").children("#toto").length) alert($("#foo").find("#toto").length)

Vous pouvez voir ici: http://jsfiddle.net/metal3d/9KDA4/1/

C’est quoi cette implémentation ? trois cas possibles ?

On se retrouve avec des comportements illogiques.

Tout passe par \$, merci la POO

Et pour revenir au cas du fameux “\$“, on va prendre un exemple de handler de click. Dans cette méthode, “this” correspond bien à l’élément cliqué, mais pas “\$(this)” qui lui est une collection contenant un seul élément (celui qui est cliqué)… Cela a une impacte sur la logique: puisque le handler est appelé par jQuery, il y a peu de raison (perso j’en vois pas) pour que “this” ne soit pas au moins l’objet jQuery contenant l’élément. Parce que forcer l’utilisateur à taper “\$(this)” pour avoir les méthodes spécifiques au framework… je ne vois pas l’intérêt.

Et en en vient à ce qui me dépite le plus…

Ce fichu “\$” sert à tout dans jQuery: sélecteur, espace de nom, bind d’évent du document… tout y passe. Du coup, quoique vous fassiez, créer un XHR, une collection, une collection, c’est un objet “jQuery” (mapé en \$).

Impossible de faire des classes, et ne venez pas me parler de \$.extend parce que tout développeur qui a bossé avec des langages objets ne peut honnêtement me dire que cette méthode est digne de ce nom.

Alors que Prototype, Mootools, Dojo, etc, vous permettent de bosser avec des classes, jQuery vous demande de faire du code pas beau pour tenter de faire des héritages, des proxy et on oublie l’implementation. Impossible de classifier des objets par classe. Et c’est là que le “code less, do more” me fait sourire, car pour faire du code un peu sérieux, on est obligé de coder beaucoup plus pour contrôler tout le code, alors que JS est un langage Objet et qu’on pourrait faire du code plus propre, plus pro, et maintenable.

Franchement, regardez du code dans d’autres framework, par exemple en Mootools (que j’aime beaucoup):

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

Comprennez bien que dans Mootools, Prototype, etc. la fonction “\$” ne sert que de sélecteur ! l’espace de nom est un élément du document. Cela permet de faire des classes, des implémentations, sans avoir des “\$” partout.

Masquage du JS

Je reviens à M. Michu qui code en JQuery sans connaitre le javascript. D’une, **non je ne critique pas tous les utilisateurs de jQuery en pensant que ce sont des débiles**. Que ce soit bien clair, jamais je n’ai pensé cela ! On me l’a ressorti ce matin, ça commence sérieusement à m’aggacer que “du moment où on a une vue critique d’un framework” (surtout que, désolé, mais je connais très bien JS et d’autres frameworks) alors ses utilisateurs se voient automatiquement pris pour des cons.

Ce que je critique, ce n’est pas le fait de ne pas connaître JS. C’est le fait que le framework masque fortement le langage. C’est le cas pour beaucoup de frameworks de pas mal de langages. Je vise particulièrement PHP et eZ Publish qui ont vraiment tendance à sucrer le langage et forcer les intégrateurs à coder dans les templates.

Le vrai souci ici, c’est que la puissance du langage est littéralement court-circuitée par le framework. C’est beaucoup moins le cas pour Prototype par exemple qui a gardé (justement) les notions de prototypage de classe. Mootools a une syntaxe très claire de création de classe et garde ses méthodes proches du langage d’origine.

Or, avec jQuery, vous ne faites pas de JS, mais du jQuery. Et c’est selon moi très dommage.

Une note positive quand même ?

Mais évidemment ! Si je suis aussi “agressif” envers jQuery c’est surtout parce que beaucoup de projets pro utilisent ce framework sans avoir de réflexion a priori. jQuery est un excelent framework pour des interfacages rapides, monter un ou deux caroussels et utiliser des systèmes “basiques”. C’est parfait pour un blog, un site non complexe et ne demandant pas beaucoup d’interactions. Parfait parce que **simple** et ne demandant pas beaucoup de code pour une utilisation standard.

Mais si votre interface a besoin d’évolutivité, de maintenance, demande beaucoup de code pour interfacer dynamiquement le site, alors utilisez un framework plus orienté POO, plus professionnel et moins gadget.

jQuery a eut le mérite de proposer une implémentation vraiment facile à utiliser, rapide à mettre en oeuvre et ne demandant pas de lire de la doc constamment. Mais avant de choisir par défaut jQuery parce que “vous le connaissez bien”, testez d’autres frameworks et faites-vous une idée.

Le bilan de 7 ans à utiliser 5 frameworks m’a donné cette vision:

-jquery != js, = gadget super simple et efficace en mode standard -prototype, mootools = POO, fiable, propre et modulaire -dojo = implémentation supra modulaire, proche de JS standard (oui, innerHTML ça marche hein) -extJS = on se tape des UI pour faire une application, pas un site

Mais:

-tous les frameworks ont tendance à faire oublier la puissance de JS et du DOM -trop de développeurs oublient que la plupart des UI qu’ils font sont faisables en CSS + un JS basique simple -un framework JS ne doit être utilisé que si, et seulement si vous perdez du temps à le faire en JS simple

Maintenant, vous pouvez penser ce que vous voulez, j’en ai discuté lors des conférences que j’ai données, et je sais que je ne suis pas du tout le seul à penser que jQuery devrait franchement être utilisé à moindre mesure… et que trop de développeurs ne s’intéressent pas assez aux autres technologies. C’est mon opinion, voilà tout.

Ça peut vous intéresser aussi


Jquery vs Mootools

Je suis en proie à Jquery depuis quelques semaines que ...


Namespace Javascript

Javascript a souffert pendant très longtemps d’une image de ...


Les closures javascript et la notion de classe

NodeJS, JQuery, Mootools, HTML5… le javascript s’est imposé. Mais un sujet encore ...


Mootools plus rapide que JQuery

C’est Thomas, un ancien collègue, qui a fait tomber ...

Merci de m'aider à financer mes services

Si vous avez apprécié cet article, je vous serai reconnaissant de m'aider à me payer une petite bière :)

Si vous voulez en savoir plus sur l'utilisation de flattr sur mon blog, lisez cette page: Ayez pitié de moi

Commentaires

Ajouter un commentaire

MathRobin - 17/09/2012

Salut, Malgré mon statut de chroniqueur francophone jQuery (voire mon blog), je suis obligé d’admettre qu’un certain nombre de tes arguments sont justes. jQuery n’est pas parfait et tu en soulignes très bien certains défauts.

Quand à ton dernier paragraphe, je mettrais seulement un petit frein à la phrase “tous les frameworks ont tendance à faire oublier la puissance de JS et du DOM”. As-tu jeté un oeil à AngularJS ? Le DOM y a une place prédominante et le JS n’est dissimulé qu’au minimum pour simplifier certains aspects mais typiquement, les sélecteurs ne reposent que sur le natif. C’était justement la volonté de Google avec AngularJS, couper avec les mauvaises pratiques/habitudes des autres frameworks JS.

forresst - 18/09/2012

Très bon article, tes arguments démontrent bien les différents défaut de jQuery. Le principal atout de jQuery (et pour les autres frameworks que tu cites), c’est qu’il permet de gérer la comptabilité sur les différents navigateurs à votre place. C’est un gain de temps … Ton avis est aussi indispensable pour faire progresser ce framework.

Yacine Rezgui - 21/09/2012

Comme l’ont dit MathRobin et forresst, jQuery n’est pas parfait et certaines critiques sont justes mais je trouve que tu critiques (je sais je me répète) un peu trop du fait que tu as toujours eu un a priori dessus.

J’ai commencé à programmer en JS depuis 7 ans. Entre le JS à l’ancienne (il y a 7 ans) et la facilité qu’a apporté jQuery, je ne peux que le défendre. Même PrototypeJS de son temps (son âge d’or) n’était pas aussi simple que jQuery.

Après je conçois que jQuery n’est pas fait pour une webapp utilisant énormément du JS. Un framework comme BackboneJS apporte un réel plus par rapport à lui.

Twitter et Microsoft utilisent jQuery en production sur de gros sites web voire leur site web principal et je ne crois pas qu’ils l’ont choisi au hasard ou par facilité mais après avoir sûrement effectué un comparatif rigoureux à ce niveau.

Et comme MathRobin l’a dit, regarde du côté d’AngularJS, tu auras sûrement un coup de coeur :)

Jeff_ - 24/09/2012

Je suis totalement d’accord avec toi pour 99% des trucs (voir plus bas) cependant j’ai juste envie de te dire «so what ?» et «where is your patch ?» parce qu’on sait plus ou moins tout ça, que ça n’apporte rien (même si je sens que ça t’a fait du bien) et que c’est libre !

Je rejoins par ailleurs Yacine pour Angular.

jQuery est un outil qui se veut versatile, aussi accessible que puissant et rapide.

Ton billet me fait penser à ceux qui fustigent PHP et le comparent à Python ou Ruby à grands coups de «wtf». PHP comme jQuery servent principalement à une chose : résoudre un problème… et ils font ça très bien.

Après concernant le fait que $ renvoie toujours une collection, je préfère de très loin : mon sélecteur change et n’est plus un #id ? j’ai juste à changer mon sélecteur (et pas le code qui le suit), et je n’ai jamais à me demander ce que ça renvoie : ça renvoie une collection.

Mais effectivement, tu as grandement raison, un peu plus de cohérence ne nuirait pas, mais, franchement : qu’est-ce qui est important ? la cohérence du nommage des fonctions ou que le job soit fait ?… on est d’accord :)

Kershin - 24/09/2012

Mouais, certaines critiques sont un peu faciles je pense.

Certes, il est possible d’écrire du jQuery de manière dégueulasse et confuse:

”$(‘#element’).load(handler)” est en effet permis, mais totalement pas recommandé.

”$(‘#element’).on(‘load’…” est carrément plus approprié et explicite.

Maintenant, certaines appellations et principes de fonctionnement sont carrément hasardeuses, on en convient. On peut se souvenir aussi que PHP, dans son genre, a fait pas mal aussi, avec la nomenclature bordélique de ses fonctions, l’ordre de paramètres au petit bonheur la chance…

Ceci dit, il est probable que pas mal de ces incohérences soient rectifiées dans les prochaines versions. Du moins, je l’espère car le jQuery en vaut largement la peine.

Nicolas Froidure - 24/09/2012

Je n’aime pas du tout JQuery, notamment pour ses aspects bidouillage de designer.

Mais on ne peut que constater son succès qui est d’ailleurs frustrant car de nombreux scripts qui étaient présents sur JQuery et Mootools ne supportent plus Mootools.

Au final, on commence à perdre du temps car le moindre petit carrousel doit être écrit pour avoir quelque chose à jour.

Bref, c’est dommage, JQuery occupe le devant de la scène et masque de nombreux frameworks bien mieux conçus. Mootools est un exemple flagrant.

max837134 - 08/10/2012

Salut, je suis absolument d’accord avec vous, je ne pense pas que vous pinailliez (citation).

Certains codeurs aiment (ont besoin) d’une logique forte (typage, optimisation, etc.), c’est d’ailleurs ce que j’apprécie avec l’AS3 et c’est ce qui me déçoit dans nombre de langages et frameworks.

Il semble évident qu’un langage ou un framework soit à ses débuts bancal, hésitant, insatisfaisant, mais après quelques années, après des retours utilisateurs, après réflexion (comme par exemple le passage de l’AS2 à l’AS3, totalement différent), celui-ci évolue et mérite ainsi ses lettres de noblesse, c’est-à-dire qu’il soit largement diffusé et utilisé. jQuery a ses lettres de noblesses, mais pourquoi ? Javascript aussi (TypeScript arrive, ouf! enfin!), mais pourquoi ?

Du beau et bon code ne se limite pas (et cela ne devrait même pas être considéré) à réduire la longueur des mots (utilisation par exemple de $).

L’AS3 (que je maîtrise le mieux) affiche par exemple des performances inégalées (…) même si les scripts sont plus lourds ou plus nombreux que ceux installés nativement par les mecs d’adobe : c’est que leur interprétation est plus rapide car le travail aura été mieux pensé (par exemple les classes de chargement et de tween réalisés par jack doyle/greensock).

Donc, préparation, essais, réécriture, essais, réécriture, essais, etc., écoute des retours utilisateurs, réécriture, essais, etc.

Bonne continuation et bon courage Max

Metal3d - 12/10/2012

Je peux malheureusement pas répondre à tout le monde mais je vais juste préciser mes propos (qui sont parfois mal compris je pense).

Je suis ouvert à vos remarques, et je suis même heureux d’avoir des avis opposés. Merci avant tout pour ces retours.

Ce que je reproche réellement à jQuery est sa syntaxe, et effectivement je ne propose pas de patch… parce que d’autres librairies sont là. jQuery, à la limite, comme le disent certains dans leur commentaires, je pourrais dire “and so what ?”, car je peux ne pas l’utiliser.

Et pourtant, voilà ma vraie remarque: en fait je ne critique pas tant que ça jQuery, mais l’absence d’utilisation d’autres framework JS par les développeurs Web. Ce parce que jQuery a une bonne stratégie de com’. C’est comme dire “Apple c’est trop bien” sans jamais se poser la question de voir si autre chose existe à coté. Il y a un manque de visibilité, de tests et d’implémentation dans notre monde de développeurs Web.

Oui, mon billet fustige jQuery comme si je comparais PHP à Python ou Java à C++.

Mais je pense que je ne suis pas dans le faux à donner un avis “autre” que les fans de jQuery, tout comme ceux qui défendent un langage en l’opposant à un autre, car un avis de développeur apporte sa pierre à l’édifice. Je reste humble, croyez moi, je ne connais pas tout de jQuery, et je sais pertinemment que je ne suis pas assez bon orateur pour faire changer d’avis des miliers d’ingé. Mais si mon avis peut appuyer un peu des choix, alors je pense que je ne me trompe en expliquant pourquoi je n’aime pas vraiment jQuery dans beaucoup de cas.

Mon billet n’est qu’une réflexion, pas une attaque (je sais que le ton que je donne peut donner un aspect négatif, je vais retravailler un peu ma manière de rédiger;) ) mais croyez moi, je respecte vraiment les auteurs de telles librairies.

Voilà, je souhaite simplement pousser un peu dans le sens “testez voir aussi Mootools ou Dojo, voyez si ce n’est pas plus adapté que jQuery”, parce que depuis des années que je m’amuse avec plusieurs librairies, et que je travaille dans des équipes de dev qui sont fans de jQuery, je suis souvent surpris par les arguments avancés.

Encore une fois, je vous remercie de débattre avec moi dans le respect, je suis content que ça ne parte pas en troll :) (et je suis pas ironique là hein)

Metal3d - 12/10/2012

@N-D Non, Mootools ne surcharge pas le scope depuis pas mal de temps. Cela a changé depuis quelques versions déjà. Et je préfère la verbosité clair que du langage SMS pour coder ;)

@Calvein “prototype, mootools = POO, fiable, propre et modulaire” –> oui tout à fait, je ne dis pas que mootools et prototype sont “en l’état” des solutions qui tournerons parfaitement à l’avenir, mais je dis que leur implémentation POO est plus fiable par rapport à ce que propose jQuery (à coup de $.proxy par exemple).

Soyons clair, je ne dis pas que jQuery ne marche pas, je dis qu’on l’utilise à mauvais escient dans trop de cas, trop de sites… je ne me vois pas coder un OS en Perl, tout comme je ne code pas un script rapidos en C++… comprenez bien mon point de vue

rivsc - 24/10/2012

Bon article. A l’époque j’avais fait le choix de jQuery car j’avais comparé les composants existants, tout ce dont j’avais besoin existait en tant que plugin jQuery. C’est ce qui à fait mon choix (je ne pense pas m’être fait attrapé par le marketing jQuery :-)).

Sinon pour click() ça ne me choque pas (get / set comme dit N-D, suivant s’il y a des params) par contre c’est vrai que load() me choque plus car c’est la nature du paramêtre qui change le comportement.

Pour css() c’est pareil ça ne me choque pas, il aurait pu appeler la méthode “style”. Tout le monde comprend.

Le fait que le selecteur jQuery renvoie une collection ne me gêne pas. Que devrait-il se passer si aucun élément n’était matché ? Undefined plutôt que [] ? Du coup le chainage de fonction pèterait. C’est peut-être pas une bonne pratique mais qu’est ce que c’est pratique.

Après le but d’un framework est d’accélérer le dev / d’ajouter des fonctionnalités et là je pense que jQuery fait son boulot.

Laurent - 30/11/2012

Je suis assez d’accord mais JQuery on ne le prend pas pour faire le plus propre possible.

On le prend pour plusieurs raisons: -C’est facile à utiliser -C’est très noob friendly (tutos, examples etc beaucoup plus que les autres frameworks) -Il y a beaucoup plus de plugins que les autres frameworks, du coup, ça fait gagner un temps fou…

A l’époque, j’utilisais Mootools et c’est vrai que je le trouve mieux designé et plus agréable à coder mais JQuery et ses plugins ont un énorme avantage…

Nico - 06/11/2013

Le truc c’est qu’à la base Jquery a été fait justement pour faire du Jquery sans se soucier de la complexité du JS, donc autant laisser l’outil tel quel il y en faut pour tout le monde.

Je suis complètement d’accord sur le fait qu’à un moment il faut aussi se décider à regarder d’autres façons de faire plus proche du langage (JS) et des paradigme.

Ajouter un commentaire

(*) Votre e-mail ne sera ni revendu, ni rendu public, ni utilisé pour vous proposer des mails commerciaux. Il n'est utilisé que pour vous contacter en cas de souci avec le contenu du commentaire, ou pour vous prévenir d'un nouveau commentaire si vous avez coché la case prévue à cet effet.