Gardez vos 2 barils de Mootools, je garde mon baril de jQuery

x.tra

Alors que l’on m’assignait à un nouveau projet à mon nouveau travail, la question du choix du framework javascript à utiliser s’est posée. Mes collègues sont habitués à Mootools et notre talentueuse intégratrice HTML avait inclus du code Mootools dans son découpage.

Le choix s’est donc naturellement porté vers ce framework.

En bon mono-utilisateur de jquery que j’étais, j’ai pris la chose comme une nouvelle opportunité d’apprendre quelque chose. C’est donc avec un certain enthousiasme que je m’y suis attelé.

Après quelques semaines, je commence à avoir mon opinion sur les qualités relatives de Mootools et Jquery. Je suis encore un utilisateur novice et il est très probable que mon avis continue à évoluer.

Parce que je suis un peu feignant, cet article s’organisera comme un commentaire de celui d’Aaron Newton of Clientcide, qu’il a posté sur http://jqueryvsmootools.com/

Vous l’aurez compris en voyant le titre de mon article, mon avis diffère quelque peu du sien.

2 bons frameworks

Jquery et Mootools sont deux frameworks de qualité. Au jeu du « qui utilise quoi », si jQuery affiche une liste très impressionnante de références, Mootools affiche une liste plus réduite mais peut s’enorgueillir de quelques références prestigieuses qui suffisent à convaincre de son sérieux, comme le w3c, vimeo ou netvibes.

Je suis évidemment d’accord avec Aaron Newton sur ce point : aucun des deux n’est un mauvais choix.

The mottos say it all

En effet, les devises en disent long.

[..]Si vous allez sur le site de Jquery, voici ce qui est dit en haut page :

jQuery est une librarie rapide et compacte qui simplifie le parcours d’un document HTML, la gestion des évènements, l’animation et les interactions Ajax pour un développement web accéléré. jQuery est conçu pour changer la manière dont vous écrivez du javascript.

…et si vous allez sur celui de MooTools, voici ce que vous trouverez :

Mootools est un framework javascript compact, modulaire et Orienté-Objet, conçu pour le développeur Javascript de niveau intermédiaire à avancé. Il vous permet d’écrire du code puissant, flexible et compatible multi-navigateurs grâce à son API élégante, bien documentée et cohérente.[..]

Vous ne trouvez pas qu’une des devises se la pète un peu plus que l’autre ? Sérieusement ?…

« .. conçu pour le développeur Javascript de niveau intermédiaire à avancé.».. .

L’important ici n’est pas que cela soit vrai ou non (personnellement, je considère que Mootools est tout à fait utilisable par un débutant). Ce qui est important, c’est que l’équipe de Mootools s’adresse à ceux qui se considèrent comme des développeurs confirmés.

Aaron va même plus loin dans ce sens, en, si je résume, considérant que « si vous être intéressés par Javascript et ce qui le rend intéressant, puissant et expressif, alors [..] Mootools est le meilleur choix ».

Je suis en total désaccord avec ce dernier point. En fait, je pense même qu’au contraire, si vous aimez le javascript, vous ne voulez pas utiliser Mootools. Mais nous y reviendrons plus tard lorsque nous aborderons le modèle objet tel que Mootools le conçoit.

The Learning Curve and The Community

Effectivement, la communauté jQuery est bien plus importante que celle de Mootools. L’auteur oublie sur ce point un effet important : Plus votre communauté est importante, plus vous avez de bugs remontés, plus vous avez de développeurs pour les corriger et améliorer le code, plus vous avez de contributeurs qui développent et partagent des plugins.
Sur la stabilité, la fréquence et l’importance des releases, là encore, jQuery a une énorme avance sur Mootools.

Un example : Peut-être n’ai-je pas de chance mais à peine quelques jours après avoir commencé à utiliser Mootools, je suis tombé sur un bug gênant. Sur la version 1.3.1.1 de Mootools More, le Form validation ne fonctionne pas sur un contrôle select. Essayez simplement d’implémenter un callback sur l’évènement elementFail sur un contrôle select et vous ne recevrez jamais rien dans votre variable element.

Le bug est référencé et corrigé sur le repositorygithub : https://github.com/mootools/mootools-more/commit/358378c5b mais toujours pas dans la version officielle en téléchargement.

What Javascript is Good For

L’auteur nous offre ici une approche succinte du modèle objet prototypal utilisé par Javascript et conclut que “la mauvaise nouvelle, c’est que le Javascript pur ne rend pas ces choses puissantes ni utiles ni accessibles”.

Hein ? Pardon ?

OK, je suis d’accord ici aussi sur le fait que le modèle prototypal est très (trop) souvent méconnu des développeurs. L’excellent article de Steve Yegge sur le sujet et “Javascript, the good parts” du non moins excellent Douglas Crockford, sauront éclairer le curieux sur ces aspects peut-être méconnus de l’approche choisie par Javascript.

Mais comment peut-on décemment soutenir que le langage ne rend pas l’utilisation de ces concepts utile ou accessible ?

Voici comment déclarer un objet en javascript:

var my_object = {
	property: ‘a property’,
	method: function(){
		alert(‘Hello World’);
	}
};

Et voici comment hériter de cet objet:

var tmp = function(){ };
tmp.prototype = my_object;
var my_herited_object = new tmp();

OK, je suis un peu de mauvaise foi. Le dernier code n’est pas forcément des plus évidents. Mais en quoi Javascript le rend-il inutile ou inacessible ?

Mootools makes Javascript itself more fun

Aaron nous explique ici que Mootools s’attache à améliorer Javascript, à le rendre “tel qu’il devrait être”.

D’une part Mootools étend les prototypes des types natifs Javascript pour leur apporter des fonctionnalités manquantes.

Rappelons juste ici que les augmentations apportées à Element servent essentiellement à la traversée et à la manipulation du DOM, domaine où jQuery excelle.

Les autres “améliorations” apportées aux types natifs comme Array ou String sont certes pour au moins certaines les bienvenues, mais ne sont pas pour la plupart l’apanage de Mootools.

JQuery aussi inclue des fonctions manquantes, sans pour autant les intégrer au prototypes natifs.

Enfin, Mootools propose son fameux concept de Class.

L’auteur nous affirme que Mootools n’a pas pour but ici d’introduire un principe objet par classe classique en javascript mais de simplifier l’utilisation du modèle prototypal.

Mais bien sûr. Et la marmotte

Dans ce cas, j’ai une question simple : Pourquoi appeller un object/domaine de nom destiné à simplifier l’utilisation du modèle d’objet prototypal du nom du modèle concurrent ?

En pratique, l’utilisation des Class Mootools est clairement un mimétisme d’un modèle classique en Javascript.

En admettant que la volonté des développeurs de Mootools ait été de faciliter l’utilisation du modèle prototypal, le nom utilisé et son fonctionnement ne peuvent que conduire à la confusion chez le développeur.

J’aime Javascript pour, entre autre, son approche prototypes. C’est parce que j’aime le Javascript que je n’ai pas besoin du système de Class de Mootools.

jQuery ne fournit pas de « modèle d’héritage » pour une bonne raison: il est déjà inclus dans Javascript et fonctionne très bien.
La couche additionnelle apportée par Mootools prête à confusion et me paraît _comme il me semble elle devrait paraître à tout développeur Javascript_, contre-naturelle.

jQuery makes the DOM more fun

Encore un sophisme redondant de l’auteur. jQuery ne serait qu’une “boîte à outils” destiné uniquement à la manipulation du DOM, contrairement à un “véritable framework”, plus abstrait et noble qu’incarnerait Mootools.

Le fait est que cela est en grande partie faux.

La différence est que jQuery s’occuppe de choses utiles. Même si, grâce notamment à node.js, on commence à trouver du Javascript hors du browser, le fait est que l’énorme majorité du code Javascript est actuellement interprété par les navigateurs.

Et la manipulation du DOM est, effectivement, un point très important pour le développeur.

Mais réduire jQuery à cela est mensonger. La couche Ajax, les fonctions utilitaires dont nous avons déjà parlé ou le traitement de callbacks par lots introduit par la version 1.5. sont autant de points qui n’ont pas de rapport direct avec le DOM.

Anything You Can Do I Can Do Better

Passons ce chapitre où l’auteur tente de nous convaincre sans aucun argument que le spectre de Mootools est plus large que celui de jQuery.

J’ai déjà indiqué que je considérais la partie soit-disant spécifique à Mootools comme une surcouche inutile à Javascript.

Mootools Lets You Have It Your Way

Passons là aussi.

Je ne conçois pas qu’on veuille mimer le fonctionnement de Mootools.

Sur la manipulation du DOM, Mootools est incohérent et verbeux.
Sur l’utilisation des classes, tout ceci peut être fait de manière plus simple et plus propre en Javascript natif.

Chaining as a Design Pattern

Où l’on nous explique que l’on peut accéder aux propriétés d’un objet renvoyé par une fonction. Merci, c’est gentil, on le savait déjà.

Reusing Code with JQuery

Ici encore, on cherche à nous faire croire que parce qu’on utilise jQuery, on ne peut que se cantonner à manipuler le DOM.

Désolé Aaron, mais je crée, utilise et hérite des objets dans mon code Javascript. Et tout cela sans Mootools.

Un mot sur ce “qui rend facile pour n’importe qui d’écrire un plugin jQuery – ce ne sont que de simples fonctions”.

Rappelons juste qu’au contraire d’un langage comme PHP, en Javascript, une fonction hérite d’Object, que nous pouvons librement définir et utiliser des objets en son sein ou d’autres fonctions.
Parce que les fonctions sont aussi des clôtures, elles ont accès à l’ensemble des données accessible depuis leur domaine de définition.
Il n’y a pas de limite à la complexité possible d’une fonction. En fait, la totalité du framework jQuery (et oui, j’utilise ce terme à dessein), est défini dans une unique fonction.

Le point sur jQuery UI me semble lui -aussi hors de propos. La manière dont jQuery UI est inclus dans jQuery n’a rien n’à voir avec une quelconque limitation de jQuery. Il s’agit juste d’un choix des développeurs de jQuery UI.

Rappelons tout de même un principe essentiel : Tout ceci n’est au final que du javascript. Tout le monde est libre d’étendre ce qui lui chante de la manière qui lui plaît.

Reusing Code with Mootools

Un mot d’abord sur l’extension des prototypes natifs.

Personnellement, je suis partagé sur la question.

Evidemment, je trouve (trop) dangereux de modifier/étendre le comportement d’objets partagés par l’ensemble du contexte d’exécution et donc y-compris probablement par d’autres scripts et librairies (comme par exemple Google Analytics ou Maps).
D’un autre côté, je comprends la tentation d’avoir sous la main une méthode trim directement accessible depuis n’importe quel String.

Utiliser un prototype hérité n’est pas une solution puisqu’elle impliquerait des casts pénibles.

L’alternative, comme mon choix actuel, est l’utilisation de fonctions externes au type concerné, comme le fait jQuery avec jQuery.trim() par exemple.

Evidemment, on perd en qualité syntaxique en écrivant jQuery.trim( my_string ) plutôt que my_string.trim() mais on se protège au moins d’un codeur fou qui aurait décidé d’utiliser String.trim pour retourner l’heure courante.

Sur l’utilisation des sélecteurs CSS

Une question me tarraude : A quoi sert la fonction $ dans Mootools ?

Elle n’est qu’un alias de document.getElement ById, n’utilise pas de sélecteur CSS et introduit une confusion certaine avec $$.

Rappellons $$(‘#myid’)[0] donnera exactement le même résultat que $(‘myid’).
Est-ce que le but de $ est réellement d’économiser 4 caractères ?

J’en viens à me demander si le but réel de la présence de la fonction $ n’est pas d’entrer en conflit avec d’autres frameworks utilisant cette fonction (jQuery et Prototype).

 

Sur l’utilisation des Domaines de Nom

Terminons sur un point que je n’ai pas encore abordé et évité par Aaron Newton et qui pourtant sont une raison additionnelle majeure qui me fait ne pas aimer Mootools.
Je veux bien sûr parler de l’utilisation des domaines de nom.

Alors qu’un effort constant est mené par jQuery pour limiter son impact sur le namespace de window, se limitant en tout et pour tout à deux variables désignant le même objet: jQuery et $, on ne peut pas en dire autant de la part de Mootools.

Mootools place ses objets sans aucune pudeur dans le namespace global.

On a bien sûr les variables de sélecteurs $ et $$ mais aussi toute une floppée d’autres objets : Element, Class, Slick. Si vous utilisez Mootools More, d’autres objets seront aussi déclarés : Form, Fx etc.

Sérieusement, quel est le risque qu’un autre script utilise une variable nommée Form ?

Assez élevé si vous voulez mon avis.

Pour un framework qui destiné aux “développeurs de niveau intermédiaire à avancé”, je trouve qu’il s’agit d’une bien grosse erreur de débutant.

Conclusion

Vous l’aurez compris, je ne suis pas fan de Mootools. JQuery n’a évidemment pas besoin de moi pour continuer à être le framework dominant.

Rappellons un point qui a pu s’évanouir pendant la lecture de ce billet : Mootools n’est pas un mauvais framework.

Le simple fait que netvibes ou le w3c l’utilisent devraient suffire à s’en convaincre.

Mais le fait est que j’ai quelques points de désaccord avec Mootools et la présentation qu’en fait Aaron Newton.

Je trouve Mootools arrogant, trop buggué et pour une large part inutile, voire contre-productif.

Oui, ceci est orienté et prosélyte _je passerais mon temps autrement qu’à rédiger ce billet si je ne voulais pas être lu.
À mon sens, Mootools tente de faire sa promotion en usant de l’argument corporatiste « Mootools est pour les 31337 ; jQuery est pour les Noobs.

Je trouve cet argument faux. Et je n’aime pas le corporatisme. Les véritables 31337 sont ouverts au monde.

Vous pouvez avoir de bonnes raisons de continuer à préférer Mootools à jQuery (ou n’importe quel autre framework) mais ne tombez pas dans ce piège grossier.

PS  : Si vous voulez en apprendre plus sur Javascript, je vous invite à consulter les diverses publications de Douglas Crockford.

  1. I work with jQuery, Mootools and sometimes YUI.

    Every time I am given the choice I will avoid Mootools. One of the major reasons for this is the forced use of the un-Javascript like Class() constructor. The adoption of this approach severely limits flexibility and the ability to resolve problems in legacy code.

    If I want a quick solution I’ll use jQuery which offers good documentation and a professional approach with lots of examples.

    If I want a solution soundly based in solid programming architecture I’ll use YUI.

    MooTools has always been the shakiest of the JS frameworks in my opinion and every time I have contact with it I find my fears confirmed.

  2. Je développe depuis un bon moment en javascript en utilisant jQuery et son système de plugin. Depuis peu de temps, je m’essaie à Mootools, j’y ai développé quelque « classes ». J’ai lu pas mal d’articles de comparaisons (ou pseudo-comparaisons) des deux frameworks (oui, pour moi aussi jQuery est bien un framework). Y’a du bon, et beaucoup de mauvais.

    Je suis dans l’ensemble d’accord avec cet article. J’ai aussi ressenti la même chose concernant Mootools qui s’annonce pour les non-débutants réduisant jQuery aux débutants. Souvent les développeurs utilisant Mootools dénigrent jQuery, mais pas l’inverse. Pour moi, jQuery et Mootools n’ont pas les même approches et pas le même but. On peut pas vraiment les comparer.

    J’ai cependant deux choses à dire. La première est que j’aime le concept de « classe » de Mootools. Ca me plait, vraiment. Sans doute parce que je suis à la base un développeur php qui a commencé directement par de la POO et enchainé avec Java en cours. Il simplifie aussi (et rend moins moche ?) l’héritage comme le permet le JS.

    Ensuite, je constate également que j’ai du mal de bien structurer mon code avec jQuery. Et je ne parle pas du code au sein même d’un plugin mais de l’ensemble du code d’un application web. C’est peut-être un problème venant de moi et pas de jQuery. Je n’ai cependant pas ce problème avec d’autres langages ou frameworks.

    Si je me suis intéressé à Mootools, c’est d’une part pour remplir ma curiosité du fait qu’on en parlait beaucoup et parce qu’il est intéressant de se remettre (et ses choix) sans arrêt en question, surtout en informatique. Mais pas uniquement. Je voulais voir si Mootools pouvait m’aider à structurer mon code pour un application web fonctionnant en grande partie en JS. Et j’ai cette impression que oui. Maintenant, je suis encore relativement jeune dans Mootools et peut-être que mon avis changera.

    • xavier
    • 26 septembre 2012

    Pour ma part, j’ai utilisé pas mal de framework différents pour le javascript. Pour avoir pratiqué Jquery et mootools, je suis resté, pour bien des raisons sur mootools.

    Quand il a fallut faire des gros CMS sur mesure, des backoffice complexes, des intranet, j’ai pu voir les limites de JQuery. Dès j’ai voulu faire une application entièrement en objet et bien structuré, j’ai dû fuir JQuery qui ne le permettait pas (ou alors qui le permettait, mais de façon sale à mes yeux).

    Je ne suis pas d’accord sur beaucoup de points sur l’article, car là, j’ai l’impression que l’auteur compare les framework pour faire du web de site vitrine ou juste embellir l’affichage à coup d’ajax et de plug in. Dans ce cas, n’importe quel framework peut être satisfaisant.

    Pour des phrases comme ça :
    Rappellons $$(‘#myid’)[0] donnera exactement le même résultat que $(‘myid’).
    Est-ce que le but de $ est réellement d’économiser 4 caractères ?
    Je pense que c’est surtout que le document.id(‘tonid’) qui a remplacé $(‘tonid’) fais référence directement à getElementById plutot que de parcourir tous les noeuds avec une expression régulière pour retrouver ce que l’on cherche.

    Après pour tes exemples d’héritage en javascript. On peut tout refaire en javascript. pourquoi faire un $(‘#tonid’).html() en Jquery alors que javascript permet de faire document.getElementById(‘tonid’).innerHTML ? C’est parreil pour les class et mootools. On a une syntaxe propre, un développement dédié à ça, les avantages du framework (le jour où ça évolue ou s’optimise, pas besoin de reprendre ton code) etc…

    Donc pour moi, je préfère la syntaxe de mootools, la structure et rigueur à adopter pour développer en object. Mais si c’est pour faire 3 appel ajax dans un coin et de la validation de formulaire, Jquery sera plus simple à mettre en place pour les novices de mootools ou du js qui sont plus accessibles et plus simple si on ne creuse pas pour faire une usine à gaz.

  3. En dehors des multiples bugs de mootools et de sa faiblesse à maintenir une rétro-compatiblité, c’est surtout 2 points qui me choquent:

  4. l’injection du paradigme POO Objet orienté Classe
  5. l’extension des prototypes natifs js
  6. Concernant le premier point, utiliser des classes en Javascript est comparable à vouloir faire de la programmation fonctionnelle en PHP. On peut tricher pour y ressembler mais on va dans ce cas contre la logique de fonctionnement du langage.
    cf la conclusion de Douglas Crockford sur le sujet: http://www.crockford.com/javascript/inheritance.html

    Concernant le deuxième point: http://nodeguide.com/style.html#extending-prototypes

  1. Aucun trackback pour l'instant