Jquery vs Mootools

12/02/2009

Je suis en proie à Jquery depuis quelques semaines que je dois utiliser sur quelques projets. Si vous m’avez suivit sur ce blog, je m’étais penché sur Mootools et nous avons même intégré ce framework dans Copix. Après pas mal de tests et de discussions, j’ai put me faire une idée assez gobale sur ces deux frameworks javascript et j’ai bien envie de vous en parler. Je vous préviens, //c’est un coup de gueule…//

Le cheval de bataille de JQuery est la vitesse. Effectivement, JQuery semble fonctionner plus rapidement que Mootools et ce quelque soit le navigateur utilisé. Cela se joue au milisecondes mais cela peut effectivement être votre critère de choix. Sauf que voilà… si une technologie devait être choisie seulement sur ce critère on pourrait purement et simplement bannir Python, PHP, Bash etc… et tout se faire en assembleur.

La différence de temps d’exécution est d’autant plus presque insignifiante pour la plupart des projets. Dans la quasi totalité des cas que j’ai vu, la différence n’est pas du tout visible. Il fau donc aller un peu plus loin pour faire un choix de framework javascript.

J’ai donc décidé de faire un point sur des exemples standards que nous utilisons beaucoup dans des projets. En l’occurrence je vais porter mes opinions sur: -les selecteurs et modificateurs d’élément -un appel Ajax -une animation -modification de style -maintenance du code

Les sélecteurs permettent de récupérer une référence d’objet se trouvant dans l’arbre DOM, c’est à dire les éléments de votre page. JQuery et Mootools utilise à peu près la même syntaxe mais vous allez vite vous rendre compte de mon dégout pour l’un des deux frameworks.

Prenons l’exemple de HTML ci-dessous: <!-- ... --> <body> <div id="main"> <div id="menu"> <ul> <li>element 1</li> <li>element 2</li> <li>element 3</li> <li>element 4</li> </ul> </div> <div id="status"></div> <div id="content"> <p> Un paragraphe ici... </p> <p> Un paragraphe là... <a href="montest.php" title="Test de lien" class="ajax">Click</a> <a href="autre.php" title="Test de lien" class="ajax">Click</a> </p> </div> </div> </body> Donc ici, un page standard… je vous laisse le soin de mettre les balises d’entête xhtml etc…

Regardons comment fonctionne la sélection d’élément, par exemple récupérons le div “content”: ` //à la JQuery var content = $(‘#content’)

//à la mootools var content = $(‘content’) `

Maintenant admettons que nous voulions récupérer les éléments “li” du div “menu”… ` //à la JQuery var lis = $(‘#menu ul li’)

//à la mootools var lis = $$(‘#menu ul li’) `

Déjà là JQuery est **absurde**. La fonction “\$” (idée de //prototype//) renvoie dans notre premier exemple //un seul élément//, et dans le second cas il renvoie une //collection//.

Mootools sépare les deux méthodes. En utilisant le double dolar “\$\$” vous êtes certain de récupérer une collection ! Mootools défini, comme //prototype// que la fonction “\$” récupère un élément unique via un “id”. Donc ici, inutile de donner le “#”.

Modifion une propriété, par exemple le style de “status”, nous ajoutons 3 styles: -bordure rouge -couleur de fond grise -fonte grasse ` //à la JQuery $(“#status”).css(‘border’,‘1px solid red’); $(“#status”).css(‘background-color’,‘#EFEFEF’); $(“#status”).css(‘font-weight’,‘bold’);

//à la mootools $(‘status’).setStyles({ ‘border’: ‘1px solid red’, ‘background-color’: ‘#EFEFEF’, ‘font-weight’: ‘bold’ }) ` Remarquez la cohérence de Mootools en deux points. D’abord la méthode ne parle pas de “css” - qui normalement désigne la feuille de style, c’est à dire les fichiers css - mais bel et bien de **“styles”**. JQuery appelle sa méthode sans respecter les normes de //setter// et //getter//… et en plus **se trompe de mot**. Je continue sur ma lancée, Mootools permet deux méthodes: -setStyle(name, value) -setStyles(obj)

En bref, le mot “style” au pluriels désigne que l’on ajoute plusieurs styles (envoyés dans un objet mappant la syntaxe CSS). Et c’est valable pour **toutes les méthodes** comme //getElement// et //getElements// etc… En passant ces deux dernières méthodes **n’existent pas dans JQuery** alors qu’elles sont très pratiques et même indispensables.

En d’autres termes, Mootools est bien plus élégant et plus facile à maintenir ne serait-ce que dans sa lecture.

On va modifier les styles de tous les “li”: ` //à la JQuery $(‘#menu ul li’).css(‘color’,‘red’)

//à la mootools $$(‘#menu ul li’).setStyle(‘color’,‘red’) `

Même manière de faire, grosso-modo. On ne polémique plus sur la syntaxe et on passe à la suite.

J’ai envie faire un appel ajax sur tout les liens ayant la classe “ajax”. Un clique va chercher le lien et envoit le résultat dans la div “status”: ` //à la JQuery $(‘a.ajax’).bind(‘onclick’,function(){ $.ajax({ ‘url’: this.href, ‘success’: function (msg){ $(‘#status’).innerHTML = msg } }); })

//à la Mootools $$(‘a.ajax’).addEvent(‘click’,function(){ new Ajax(this.href,{ update: ‘status’ }); },this); `

Je crois que ça se passe de commentaires… Allez, si, je me fais plaisirs. Tiens ? “\$” maintenant il me permet d’appeler des méthodes ? Ok, on a un espace de nom et c’est pas bête en soi… mais pourquoi utiliser “\$” une nouvelle fois ? Mais qu’est-ce que c’est que cette idée de faire un code si affreux ?

De plus, pour l’exemple j’ai été gentil, j’ai pas pris en compte le type de réponse ajax… parce que dans le cas de JQuery il faut spécifier avant récupération quel type de réponse on va avoir… ce qui fait que vous ne pouvez par récupérer deux type de contenu différent.

On commence à atteindre le sommum… et non, vous n’avez pas tout vu.

Je vais maintenant ajouter un élément, un lien, dans le seconde “li” du menu. ` //à la JQuery var elem = $(’Lien’); $(‘#menu li’)[1].append(elem);

//à la mootools var elem = new Element(‘a’).set({‘href’ = ‘http://www.metal3d.org'}).setText('Lien') elem.inject($$(‘#menu li’)[1])

//ou bien en un coup: //edité le 9 mars 2009 après commentaire de efyx var elem = new Element(‘a’).set({ ‘href’ = ‘http://www.metal3d.org', ‘text’ = ‘Lien’ }).inject($$(‘#menu li’)[1])

` Ok, alors quoi que vous pensiez, oui JQuery là on a codé rapidement, mais mon dieu… s’il vous plait… avec une méthode de la sorte autant poser directement le code html dans le “li” avec un vieux “innerHTML”…

Oui, avec Mootools je dois créer un élément et lui assigner des propriété, mais qu’on soit d’accord: on fait du Javascript, pas du HTML ! Imaginez une seconde que je me trompe dans le code HTML que j’envoi dans la fonction “\$” (qui sert encore une fois à autre chose).

D’autant que là, encore une fois, je suis gentil… j’ai mis qu’un petit lien. Le jour où je je balance un tableau je vous raconte pas la tête du code et j’imagine d’ici le développeur qui va reprendre mon script pour ajouter un attribut.

Encore une fois, aucune élégance, aucun respect des normes ECMA… bref JQuery s’éloigne de l’idée que je me fais d’un bon framework.

Alors parlons des évènements, parce que là encore je me suis bien marré en testant. L’un des évènements les plus pratique que j’utilise est le “domready”. En gros, l’arbre DOM est prêt, mais **avant affichage** afin que je le modifie. Deux soucis, le premier venant de la syntaxe: ` //JQuery $(document).ready(function (){ //… })

//Mootools window.addEvent(‘domready’,function(){ //… }) `

Remarquez: pour JQuery c’est le document qui est prêt… pour Mootools on parle bien de “DOM” dans la fenêtre. Vous pensez que ça n’a pas d’importance ? **ERREUR** car JQuery exécute la méthode même si les feuilles de styles ne sont pas encore chargées… Ca vous épate ? moi pas. On a bloqué là dessus avec un collègue, obligé de gérer ce soucis avec un //setTimeout//…

En plus de cela, d’un coup on utilise plus “bind” mais une méthode précise ? Donc pour JQuery on a des évènements et… des évnènements… la différence ? ba le bon chasseur il voit un truc… il tire…

Bref…

En ce qui concerne les animations, je n’ai même pas osé en parler dans ce billet tant l’horreur m’a frappé quand j’ai testé JQuery. Mootools propose d’emblée des techniques de //morphing// CSS, des courbes d’animation proche de celle de Flash et la fluidité est franchement sans conteste.

Et je ne vous parle pas d’étendre la classe d’éléments… Impossible de comprendre comment faire sur JQuery alors que Mootools permet la gestion de classe et d’extension d’objet nativement (extends, implements, merge…). Là encore je ne comprend pas comment un framework peut prétendre être à la hauteur si il ne permet pas l’extension d’objet natif aussi primordial que l’élément DOM lui même !

Je sais que vous pouvez penser que je suis franchement un gueulard qui aime balancer sur des technos qu’il a pas envie d’utiliser, mais vous vous trompez ! Je me suis remis en question quand à mon choix d’avoir proposé il y a quelques temps Mootools à l’équipe de Copix. Vu la réputation qu’avait JQuery je me suis laissé tenté en espérant vraiment trouver mieux, me disant que je pourrais alors implémenter JQuery dans mon framework PHP préféré.

Mais au fur et à mesure j’ai déchanté, jusqu’à être abasourdi par une telle laideur d’implémentation. Je ne comprend pas qu’on puisse coder un framework de cette manière.

Je ne critique pas ici votre choix d’utiliser JQuery, je critique les développeur de ce framework ou plutôt l’implémentation. JQuery est fort d’une qualité: il est différent, permet de coder d’une autre manière et peut donc être plus accessible pour certains. Mais de mon coté, l’optique de JQuery ne correspond pas du tout à mes besoins.

Ne prenez donc pas mal mon post, vous pouvez y répondre.

  • - Edition le 9 mars 2009:**\\

Un autre point que j’ai noté il y a quelques jours: $(document).ready(function (){ //on récupère les éléments li du menu var items = $('#menu ul li'); //on fait un truc avec ? for (i in items){ var item = items[i]; item.css('border','1px solid red'); } });

Selon vous, ça marche ? Et bien non !!! Avec JQuery, les éléments que vous récupérez ne sont pas des élements JQuery… logique ? si vous le dites… vous êtes forcé de repasser par la fontion “\$”:

$(document).ready(function (){ //on récupère les éléments li du menu var items = $('#menu ul li'); //on fait un truc avec ? for (i in items){ var item = items[i]; //on es forcé de repasser par JQuery $(item).css('border','1px solid red'); } });

Avec Mootools, c’est un peu plus logique:

window.addEvent('domready',function (){ //on récupère les éléments li du menu var items = $$('#menu ul li'); //on fait un truc avec ? for (i in items){ var item = items[i]; item.setStyle('border','1px solid red'); } });

Car avec Mootools, quand vous demandez des éléments, on vous les donne prêt à l’emploi… Encore un point noir sur le visage de JQuery.

Ça peut vous intéresser aussi


JQuery toujours pas pour moi

Suite à un vieux post qui s’est terminé par ...


Voip, encore un coup de gueule

Encore un coup de gueule, je sais que ces temps-ci ...


Tri de tableau d'objet javascript

Javascript est riche de méthodes en tout genre qui parfois ...


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

Juguul - 12/02/2009

Intéressant ce comparatif, je voudrais juste faire un mini coup de gueule sur Mootools, qui excellent dans son implémentation, à pour moi fait une erreur : La rétrocompatibilité !!!! Et oui, passer de Mootools 1.1 a 1.2, et vous allez comprendre, que la rétrocompatibilité n’est pas du tout géré. Que qq trucs changent ok, mais la, c’est pratiquement toutes les implémentations qui changent. Mais bon, il pourrait y avoir un script de compatibilité, et il y en a un !!! mais loin d’etre complet, une remarque sur les forums ou autres, et personne ne le prends en compte !

Bon j’aime Mootools, mais sérieux vous faites chier !!!!

Metal3d - 12/02/2009

Tout à fait d’accord sur la question de la rétrocompatibilité. J’ai même eut une discussion sur la question avec digitarald sur le problème et le point de vue des développeurs de Mootools est un peu vague.

Les développeurs de plugins ont pas mal gueulé à ce propos, mais j’admet une chose: les modifications apportées sur les releases qui rendent parfois incompatible le code sont franchement des grosses évolutions nécessaires.

Et clairement, on est pas forcé de passer d’une release à l’autre comme le disait Digit, là où je le critique c’est d’utiliser un numéro de version qui n’est pas adéquat. Clairement, on aurait dut passé en version 2 et non en 1.2 car le principe de développement a changé.

Cela n’enlève rien au fait que la qualité de développement sur Mootools est au delà de JQuery.

En tout cas, merci Juguul de me rappeler cela, j’avais oublié ce problème Mootoolsien :)

Imatt - 27/03/2009

Très belle comparaison, je n’avais jamais réfléchis en profondeur sur jQuery, mais tes arguments sont frappants. Je suis un pro jQuery depuis 1 an, mais je vais tester mootools sans plus attendre.

Merci de nous remettre dans le droit chemin, dès fois on s’endors un peu trop sur nos acquis ;)

archer_1001 - 29/03/2009

Billet très interéssant!

Je cherche justement un framework autre que prototype (que j’utilise actuellement). J’étais tenté par Mootools mais étant donné le succès qu’a JQuery, j’hésitais mais là tu viens de m’aider dans mon choix.

Rev - 20/05/2009

Je suis dans le même cas que archer_1001. J’utilise “prototype-js” pour une application web mais ce framework manque de mise à jour et de plugins. Je cherche donc un framework JS stable, pérenne, et disposant d’une bonne communauté sur le web. Je m’orientais sur Jquery, mais après lecture de ce post, je pense m’orienter vers Mootools.

Effectivement, le temps d’exécution ne fait pas tout. La lisibilité et la logique du code est également très importante.

padapara - 01/08/2009

Après l’argumentaire intéressant de Niaatan, j’attends ta réponse Metal3d.

Peut-être est-tu en vacance mais j’ai vite besoin de faire un choix entre les deux frameworks, car si il n’y avait pas eu ce dernier billet, j’aurais choisi Mootools, mais là… chui’ perdu

juks - 01/08/2009

Salut Metal3d,

déjà +1 pour Niaatan

ton comparatif semblait être une bonne chose dans le fond mais alors tu t’es complétement raté..

en effet tu es bien trop perché dans la MooTools-attitude, tu proposes des méthodes via jQuery qui ne sont mêmes pas les bonnes (par exemple pour la css, ou pour la boucle).

Certes pour la poo, MooTools est plus apte cependant pour le reste tu te mets 2 doigts dans l’oeil. Et puis ta logique euh.. mouai

J’ai commencé par MooTools, aujourd’hui je code exclusivement sur jQuery.

Avant de le critiquer, apprendre à l’utiliser serait un bon début.

y’a plein de docs et de tutos sur internet, je suis sur que google saura t’aider (ton histoire de bind est tellement fun, merci!)

Alahel - 24/08/2009

Je trouve dommage que lors d’une simple comparaison de clarté de code on en vienne à trouver des propos si agressifs … certes, l’auteur n’a pas forcément utilisé JQuery au mieux de ses possibilités, mais il semble qu’il ait abordé les deux frameworks avec une méthodologie 100% objet … technique la plus robuste en programmation. Ayant abordé Prototype, puis JQuery et enfin Mootools, je trouve que JQuery manque effectivement de rigueur, mais il garde pour lui ses performances …

MoAX - 23/09/2009

Un comparatif ? non Juste un article sur framework incompris par un guy fan de mootools.

Metal3d - 09/10/2009

@MoAX non et non ! J’ai utilisé et j’utilise encore à mes dépends JQuery sur des projets pro. Certes je suis un peu aggressif, mais tu es sur un blog et non pas un site d’articles. C’est un post personnel qui donne mon avis. Mais “incompris” je ne te le permet pas !

Plus j’utilise JQuery et plus je me rend compte que ce framework est véritablement mal pensé. J’ai des années de route sur JS et j’ai put en codé des choses… JQuery a ses avantages, notamment une communauté énorme et éclectique, mais la base même du framework est mauvaise.

C’est une question de bon sens, simplement un respect des variables retournées et poser du camelCase serait suffisant pour que je me ravise.

Mais voilà, aujourd’hui ce n’est pas possible, et ça ne le sera jamais puisque l’implémentation est effective.

JQuery est loin de dépasser mootools en terme d’implémentation et je n’ai parlé que ce sujet là. Je n’ai pas parlé des résultats, des possibilité ou encore des plugins, mais simplement de la base même de l’implémentation du framework

Donc ne pas m’accuser d’imcompréhension, merci

oelmekki - 09/11/2009

Bonjour Metal3d,

J’ai longtemps utilisé jQuery et j’utilise aujourd’hui exclusivement Mootools, que je trouve effectivement plus élégant et qui me permet de faire des applications possédant une couche js complexe et très élaborée.

Cela dit, je ne peux m’empêcher de dire que je trouve tes critiques sur jQuery à côté de la plaque.

Tu montres surtout que tu ne le maîtrises pas. Comme cela a déjà été souligné, la plupart des exemples que tu donnes de l’utilisation de jQuery sont fautifs et peuvent être accomplis beaucoup plus simplement/proprement.

Ensuite, il y a les critiques sur le design de l’API. Effectivement, celle de Mootools me semble plus cohérente, mais les choix de jQuery ont été déterminés principalement sur le critère de la concision. C’est une questions de goûts et de couleurs.

Pour ce qui est de la gestion des classes, tu sembles en fait ignorer comment faire du OO en javascript. Javascript est un langage prototypé. Les fonctions sont des objets qui peuvent avoir des attributs. Ce sont elles qui constituent des “classes”. Pour y rajouter des méthodes, il suffit de faire : className.prototype.methodName = function(){ … }. L’interface Class de mootools ne sert en fait qu’à rendre le modèle OO de javascript plus proche de ce qui se fait dans les autres langages. En outre, jQuery fournit deux méthodes pour l’ “étendre” : $.fn.extend() et $.extend().

Mais c’est encore ignorer le but de jQuery et Mootools. Mootools est destiné à compléter javascript pour en faire un full features language.

Ce n’est pas du tout le but de jQuery.

Le but de jQuery est de faciliter la manipulation du DOM, selon le schémas : sélection > modification

C’est ici que porte la seule critique pertinente de ton article : quand on veut injecter un nouvel élément dans le DOM avec jQuery, il faut l’écrire en tant que HTML dans un string. C’est absolument horrible, surtout pour une library dont le but est précisément la manipulation du DOM.

Pour le reste, jQuery fait son boulot : permettre d’écrire rapidement de petits scripts qui font de petits effets.

curieux - 26/03/2010

Actuellement je développe en actionscript 3 sous flash/flex et je cherche un moyen de passer au javascript en conservant les avantages de l’IDE Flash et la syntaxe as3 que je trouve pratique et simple pour la programmation.

Même s’il existe manifestement d’autres moyens d’écrire tes exemples JQuery d’après tes détracteurs, force est de constater que la syntaxe de Mootools ressemble plus à un langage classique de programmation

Je poursuis mes investigations, mais ton article m’aura permis de constater que Mootools semble plus correspondre à ce que je cherche

merci pour l’article

darkelda - 05/05/2010

En tout cas, c’est une très bonne analyse côté syntaxique.

Avant toute chose, je n’ai jamais codé avec ces framework auparavant mais celà m’a permis de faire mon choix comme la plupart des contributeurs.

Mootools m’a l’air de se rapprocher plus de la “logique orienté objet” que jQuery…

Par contre, si vous voulez un vrai comparatif, il y a celui-ci:

http://jqueryvsmootools.com/

Oui c’est en anglais, mais au moins c’est un comparatif et pas UN COUP DE GUEULE sur son blog personnel comme le SIGNALER metal3d.

En tout cas merci pour l’article!

darkelda - 05/05/2010

Au fait, si jQuery est plutôt pour modifier rapidement le DOM alors pourquoi la propriété de style d’un élément en HTML c’est :

mon paragraphe

et non

mon paragraphe

???

Alors pourquoi jQuery utilise $.css??? Pas très cohérent…

Chibani - 31/10/2010

Quand je vois ta façon de coder, je comprends que tu n’apprécie pas jQuery… Tous tes exemples sont optimisables et ne tirent pas parti de la puissance de jQuery. Lis un peu la doc, quelques tutos et tu verra vite que tu t’égares.

FGRibreau - 31/10/2010

@Metal3D et si aujourd’hui (en 2010) tu devais revoir/ré-écrire cet article. Garderais-tu tout tes arguments ?

En ajouterais-tu ?

elo - 25/01/2011

Merci pour cet article.

Je n’utilise aucune de ces librairies (je me suis codé ma propre lib, c’est plus sympa).

Ce que je remarque, c’est qu’elle est plus proche de Mootools que de Jquery.

Je n’utilise pas les $ ou $$ (je trouve ça illogique d’utiliser ce caractère) mais renvoyer une liste d’objets ou un objet STANDARD est un minimum.

Après, je n’adhère pas au $(“#menu ul”), laissons le CSS là où il est ! En Javascript, je fait plutôt : obj({balise:‘ul’, parent:obj({id:‘menu’}))

C’est un poil plus long mais plus propre, plus clair et plus logique.

ombritude - 29/08/2011

merci pour votre article et vos comparatifs, les critiques qui vous sont faites sont stupides et enfantines !!!! continuez :)

joss - 13/09/2011

Bonjour, j’utilise mootools et je developpe sur mootools car l’illogisme de Jquery ne me convient pas. je confirme le grotesque de certaines fonctions, mais je suis d’accord avec certaines remarque c’est beucoup une histoire de gout. l’HISTOIRE est la même pour tous, mais on différente façon de la comprendre. Pour info la version 1.4 de mootools viens de sortir, retrocomp sur la 1.3 uniquement !

Steuf - 19/09/2011

Bonjour !

Je vais y mettre mon petit grain de sel mais je développe depuis plusieurs années sous Jquery et pour la reprise d’un projet je dois gérer celui-ci qui est sous Mootools…

On pourra critiquer sur certains point Jquery, mais toujours est il que la prise en main est bien plus rapide et “naturelle” sous Jquery. Jquery profite aussi d’une documentation complète et clair, on ajoute à cela JquerUI et la plus grande bibliothèque de plugins… Le résultat ça donne une FW simple et intuitif qui n’est peut être pas sémantiquement parfait mais personnellement d’un point de vu professionnel je sais faire la part des choses et je préfère un compromis entre l’efficacité et la “propreté” que de privilégier ce qui est ultra verbeux et difficile à prendre en main.

Donc j’ai du développé sous Mootools et franchement… La prise en main est assez horrible pour une raison: Leur documentation est immonde ! S’y repérer relevé de l’exploit, et comme entre chaque version tout change ou presque le peut qu’on est une version qui n’est plus d’actualité tu peux toujours courir pour trouver la documentation correspondante. Donc au final tu cherches, tu cherches, tu ne trouve pas… Au final tu trouve un exemple qui correspond à tes besoins tu la mets et là paf tu te tape une erreur sans comprendre d’où elle sort… Tu te dis que Mootools n’est pas à jour, (1.2 au lieu de 1.4) alors tu te dis que tu vas la mettre à jour… Et au final tu te rends compte que c’est pire que mieux.

La conclusion elle est simple avec Mootools: Si tu n’évolue pas avec lui tu es obligé de faire de la bidouille et tu n’a plus que tes yeux pour pleurer. Encore pire quand c’est ta première approche du Framework ça ne te donne vraiment pas du tout envie d’aller plus loin.

Comme je le dis parfois sur d’autres projets, aussi bon soit t’il si la prise en main est mauvaise et que la documentation est foireuse tu préfére aller là où c’est moins stylé mais là ou la documentation est clair et tu ne cherche pas 3 heures pour faire telle ou telle chose (totalement basique qui plus est).

chti - 28/09/2011

j’ai voulue utilisé jquery pour être à la mode. impossible de trouver plus simple et plus complet que mootools. un diaporama avec des contrôles et thumb etc c’est vraiment compliqué avec jquery je confirme et me pose la question pourquoi autant de pub autour de jquery

IE et alors ? - 28/12/2012

** commentaire censuré par l’administrateur **

Metal3d - 17/12/2011

Ha je vois qu’on a un champion là…

Je me la pète sur les comparatifs web ? où ça ? je parle de deux frameworks JS là, et je donne un avis “perso” sur une utilisation pro que j’ai depuis… je compte… 10 ans hein.

Ensuite, oui, je suis sur un blog “perso” et je milite pour les standards: donc IE (pour le moment) n’utilisant ni le canvas (sur la version 8) ni le WebGL et CSS 3D (version 9 aussi) je “propose” l’utilisation de Google Chrome Tab, tu sais le truc utilisé par beaucoup de dèveloppeurs web pour éviter (sur des site persos) de devoir tester sur X navigateurs infâmes.

Si tu suis un peu la CSS que j’ai tapé il y’a 3 ans de ça (car j’ai peu de temps pour m’occuper de la refonte du blog) tu verrais que j’utilise des transitions CSS qui n’existent pas sur IE… PS: ce site me sert surtout de tests, donc c’est pas forcément beau, mais je vois que ça fonctionne ou pas, et je vire les options qui gênent au fur et à mesure.

Le leader du marché n’est pas IE au fait, tu devrais te renseigner un tout petit peu…

Et quand à l’insulte, en mode anonyme, tu ferais mieux de nous montrer ton nom qu’on sache à quel point un homme si brave que toi peut avoir les parties intimes assez volumineuse pour s’exposer aussi à la critique.

Enfin, jamais je n’ai dit que c’est une honte d’utiliser IE… mais bon, tu es un petit développeur ne connaissant que ton bon vieux windows, et tu ne connais absolument pas les problématiques WEB professionnelles à ce que je vois.

Ha, ces petit jeunes qui ne connaissent pas le militantisme, ça m’émeut :)

Metal3d - 17/12/2011

Attention, je corrige un truc ou deux: CSS 3D n’est pas standardisé je le sais bien, je voulais parler des futures évolutions ralentis par MS qui pourraient être standard depuis longtemps.

je n’ai jamais dit que jQuery était compliqué, il est plus simple que Mootools

Je répète: le code tapé dans l’article est optimisable, je le sais bien mais l’optimisation demande justement une syntaxe éloignée du JS en lui même.

Je conseille depuis des lustres de n’utiliser AUCUN framework JS pour forcer la main aux dev de navigateurs à se mettre d’accord sur la structure DOM et back des api, et surtout pour soulager et controller au mieux votre code.

Et enfin, ce site est en cours de refonte, mais pour ceux qui ne le savent pas je suis malade depuis plusieurs mois et il me faut bien plus de temps pour bosser sur mon site.

Et enfin, afin de calmer les excités qui insultent, je vais clôturer les commentaires de ce ticket à la prochaine insulte, sinon d’ici mon prochain article plus poussé sur la problématique jQuery.

false - 24/01/2012

Bonne comparaisons malgré quelques erreurs sur jQuery, il y a effectivement plus élégant comme manière de coder, attention à ne pas trop être mootools-fan :)

Etant un développeur MooTools et connaissant également jQuery, mon choix reste MooTools car quand on est habitué à une POO il est difficile de ne plus y penser après. (c’est la raison principale pour moi)

MooTools ne ré-écris pas JavaScript contrairement à jQuery.

Pour ceux qui s’interrogeraient quant au choix d’un framework c’est simple :

  • jQuery est un très bon framework rapide et simple à utiliser mais ce n’est pas avec celui-ci que vous allez progressez en JavaScript, vous connaitrez jQuery, pas JavaScript. C’est un framework pour les webdesigners, pas pour les développeurs. Si vous voulez pas vous emmerdez avec JS, prenez jQuery :)

Mootools est orienté objet, c’est à dire qu’il s’approche plus d’un langage de programmation de type Java ou ActionScript. Il est un peu + difficile à comprendre au départ. L’écriture est plus élégante mais parfois plus longue. Il respecte JavaScript et si vous connaissez MooTools vous aurez déjà une bonne approche de JS. Après le top c’est les “Class”, comme en Java ou en AS :) Vous pourrez à tout moment dans votre code écrire “var monSlider = new Slider();” et ça c’est la grosse Class…

Et arrêtez de penser que le choix d’un framework vous fera passer pour un bon ou mauvais développeur, tout dépend de ce que vous en faites et votre manière de coder :)!

:)

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.