Devrais-je convertir MooTools en jQuery? [fermé]

Question

J'ai une base de code assez grande qui dépend de MooTools v1.11 et que je suis sur le point de convertir en version 1.2. Comme il s’agit d’une refonte majeure, j’ai eu l’idée de passer à jQuery.

Quelqu'un a-t-il des conseils sur la mise à jour de jQuery ou tout simplement sur MooTools?

J'utilise principalement MooTools pour Ajax, le glisser-déposer et certains effets mineurs.

Answer 1

Si vous mettez à jour malgré tout , il peut être intéressant de regarder.

jQuery semble bien en voie de devenir la bibliothèque One True Javascript (étant donné que MS et d’autres ont décidé de l’embrasser), donc si c’est du code sur lequel vous avez l’intention de travailler pendant un moment, c’est probablement un bon idée de changer à un moment donné (ne serait-ce que parce qu'il y aura plus d'endroits où obtenir de l'aide et du code plug-in, car il est très probable qu'il continue à être populaire pendant un certain temps, ce qui contribuera à garantir la flexibilité et la maintenabilité de votre code à long terme) . Donc, étant donné que vous devez le convertir de toute façon, le moment est peut-être bien choisi.

Je pense que jQuery devient le cadre à utiliser est une bonne chose. Ce n’aurait pas été mon choix (j’aime aussi MooTools), mais c’est certainement un excellent morceau de code qui convient parfaitement, du moins avec la compétence de ses concurrents. Je suis heureux de constater toute cohérence, et je transférerai mon code dans jQuery à un moment donné.

Answer 2

Si ce n'est pas cassé. Ne le répare pas.

jQuery peut avoir X ou Y, mais si tout dépend de MooTools, vous aurez peut-être encore beaucoup de travail pour convertir vos MooTools.

Conservez MooTools si vous l’utilisez beaucoup sur votre site. Toutefois, si vous ne disposez que de 2 à 3 pages avec des effets mineurs, le changement en vaut la peine.

Answer 3

Pourquoi faire le changement? J'ai converti les bases de code de 1.11 à 1.2, et c'est assez rapide et facile (et je l'utilise pour plus que quelques effets).

jQuery peut être adopté par les États membres. Selon un site, ses performances sont meilleures dans IE - mais il ne s'agit pas de savoir si cela fonctionne bien avec IE, mais bien de savoir si cela fonctionne bien pour votre site (IE est-il un acteur majeur sur votre site?) ?).

Connaissez-vous jQuery? Si vous ne le faites pas, vous devrez alors réécrire le code à partir de zéro et vous réécrirez complètement votre code.

Ou essayez-vous simplement de trouver des raisons de dire à votre responsable que "nous devrions le faire dans jQuery"? parce que tu veux l'apprendre?

Pour autant que "l'unique cadre véritable" - C'est une affirmation ridicule que seuls les utilisateurs font, pas les développeurs.

Answer 4

Le passage de MooTools 1.1.1 à 1.2.1 n’est pas si grave. http://github.com/mootools / mootools-core / wikis / conversion de 1-11 à 1-2 1-2

Il existe même une couche de compatibilité qui permet au code MooTools 1.1.1 de fonctionner dans les versions 1.2.x. Vous devrez peut-être régler manuellement quelques problèmes ici et là, mais c’est relativement mineur.

Basculer vers jQuery, YUI ou DOJO, ou toute autre chose, nécessiterait de jeter complètement tout le code que vous avez et de le déclarer. Aucun de mes clients ne permettrait jamais ce genre de déchets.

De plus, si vous avez l'habitude de coder avec les classes MooTools appropriées, jQuery peut être un choc pour votre système. Ce n'est pas que jQuery vous oblige à écrire du code illisible et incontrôlable, il est certainement possible de coder du code très lisible et maintenable dans n'importe quelle langue. Mais jQuery n’a pas de système de classes intégré pour vous aider.

Surtout avec une grande base de code, il est important de garder votre code bien organisé.

Je suis assez partial, bien sûr.

Answer 5

Il existe un site décrivant les différences de philosophie jqueryvsmootools.com

Je pense que c'est ce qui se résume à la fin. Une approche fonctionnelle centrée sur DOM ou une approche JavaScript orientée objet.

Answer 6

Comme d'autres l'ont déjà souligné, jQuery est une bibliothèque (pour jouer avec DOM principalement), Mootools (1.2) est un framework JavaScript à part entière qui vous permet d'organiser votre code de manière orientée objet et de le maintenir ainsi facilement. .

Je vous recommande de lire ceci pour savoir vraiment ce qu’il en est vraiment (jqueryvsmootools.com)

Et cet autre lien, pour que vous sachiez tirer le meilleur parti des deux mondes;):

http://ryanflorence.com/object- orienté-jquery-with-mootools-pigs-take-flight /

En fin de compte, cela se résume à ce dont vous avez besoin. Ma recommandation générale est la suivante: si vous avez besoin d'extraire des extraits rapides et de personnaliser votre application Web, jQuery est utile. si vous allez centrer votre développement sur javascript, vous devriez vraiment essayer mootools: le code sera mis à l'échelle et vous devriez mieux vous préparer.

Pour mettre à niveau votre code à partir de Mootools 1.1, vous pouvez utiliser l’aide de mise à niveau. Elle vous aidera à identifier le code en conflit via la console javascript (mootools.net/blog/2009/12/31/mootools-1-1-upgrade -layer-beta /)

[Désolé de n’avoir posté qu’un seul lien actif, c’est ma première réponse]

Answer 7

Cela dépend de votre connaissance de jQuery et de votre échéance. Si vous le connaissez bien, cela prend moins de lignes de code, ce qui signifie moins de bande passante pour vos clients.

Aussi, si vous regardez Sur ce site , vous pouvez constater que dans le navigateur principal, IE, jQuery offre de meilleures performances que Mootools.

Cela étant dit, si tout fonctionne dans Mootools v1.11, pourquoi mettez-vous à jour les scripts? Comme le dit l'affiche précédente, si ce n'est pas cassé ...

Si cela ne fonctionne pas correctement dans Mootools v1.11, comment savez-vous que cela fonctionnera dans Mootools v1.2 ou même jQuery? Il serait dommage de mettre beaucoup de temps de développement et d'avoir certains des mêmes bugs, ou d'introduire de nouveaux bugs à cause du framework que vous utilisez.

Answer 8

À ce stade, Slickspeed devient totalement sans importance, les sélecteurs sont de toute façon trop rapides. De plus, Sly de Herald Kirschner, membre de l'équipe de développement de Mootools, vient de lancer Sly, un moteur de sélection qui bat Sizzle. Le fait que les animations soient le facteur déterminant pour ne PAS choisir les outils mootools laissés par l’une des affiches était fondamentalement arriéré, Mootools est le roi des animations depuis des années. Quoi que vous choisissiez, tout fonctionnera. Mootools a une sensation plus classique qui, à mon avis, me maintient organisé, jQuery est davantage basé sur les fonctions et ne s'aventure pas trop dans les cours. Un augmente les types natifs et l'autre pas, une stratégie différente mais c'est tout.

• Daniel

Answer 9

Je suis assez content de Mootools. J'ai été tenté à plusieurs reprises d'essayer jQuery parce que de plus en plus de gens l'utilisent ces derniers temps, mais je n'ai toujours pas la bonne fonctionnalité OO comme Mootools. Une autre chose que je n'aime pas trop à propos de jQuery est d'obtenir l'identifiant avec la fonction dollar en ajoutant le hashkey (#). Cela peut être problématique si vous souhaitez créer des identifiants HTML à l'aide de la structure. Si j'étais vous, effectuez une mise à niveau vers la dernière version de Mootools. Mootools n’est pas une mauvaise bibliothèque du tout.

Answer 10

Dans votre question, vous avez indiqué que vous utilisiez MooTools pour "Ajax, glisser-déposer et effets mineurs". Bien que Mootools puisse le faire bien (et je risque d’être blâmé de le dire), à ??mon avis, vous ne l’utilisez pas vraiment pour la bonne raison. Nous utilisons Mootools dans nos applications et nous ne pouvons vraiment pas penser à lui substituer JQuery. Si l'objectif est d'écrire du code maintenable à long terme orienté objet que d'autres applications de votre organisation peuvent exploiter, Mootools gagne haut la main.

Et la vitesse du sélecteur est un critère erroné (bien que je pense que Mootools existe déjà). Dans la plupart des endroits de notre code, nous avons déjà des références aux éléments que nous souhaitons modifier. La plupart du temps est consacré à la manipulation du DOM une fois que vous avez l'élément et, lors de nos tests internes (nous tenterons de les publier), Mootools est beaucoup plus rapide que JQuery dans les opérations habituelles. Nos applications sont du type où nous nous appuyons sur les contrôles Mootools précédemment construits (créés par nous ou par d’autres) pour créer des écrans d’application utilisant des données provenant de Web Services.

Answer 11

Asses si vous avez les heures de programmation pour effectuer le transport complet.
    Cela signifie que vous allez réécrire le code à partir de zéro. Cela implique encore une fois que vous devrez passer par le cycle de fonctionnalité, révision, test, correction de bogues, etc. Ceci dit, l'un des problèmes les plus importants des programmeurs peu compétents en JavaScript est que la plupart des codes accédant à des éléments DOM ont tendance à créer des fuites de mémoire (ce qui est le cas de la plupart des développeurs Web). jQuery par nature fait beaucoup pour atténuer cela. Ou plutôt jQuery enlève le JavaScript de JavaScript.
    2ème. L'une des raisons les plus convaincantes de passer à jQuery est que le poids de votre code JavaScript diminuera considérablement. Cela est logique pour une page gourmande en codes côté client. La nature concise de jQuery vous permettra également d’examiner facilement le code.
    La société avec laquelle je travaille (support.com) avait des tonnes de code Mootools. Au début de 2008 (après de longues heures de débats - pour lesquels j’étais opposé au passage à jQuery), nous avons commencé à migrer vers jQuery de manière progressive. Je n’ai pas regretté ce jour.

Answer 12

Cet argument est ennuyeux, Mootools étant O-O, les utilisateurs constituent donc un véritable arrière-plan O-O et apprécient davantage son intelligence que les utilisateurs d'un arrière-plan PHP4 ou HTML.

Answer 13

La seule raison convaincante que je puisse donner pour une telle migration serait si le changement de commutateur réduirait la quantité de code que vous devez gérer et / ou simplifierait les choses. Un tel changement implique généralement beaucoup de travail. Vous souhaitez donc pouvoir revenir en arrière une fois que tout ce travail est terminé et dire "Ouais, ça en valait la peine".

Answer 14

Vous devez choisir ce paramètre en fonction de l'objectif de votre application.

jQuery est incroyablement cool pour les animations, mais j’ai le sentiment que Mootools est plus sophistiqué, donc si l’important est l’application et non les animations, tenez-vous-en à Mootools

La vitesse est également un sujet à ce sujet. À compter d'aujourd'hui, les performances de Mootools sont légèrement plus lentes, mais je préfère ne pas y prêter attention jusqu'à la sortie de Mootools 1.3.

Performances de validation des derniers frameworks sur http://slicktest.perrohunter.com

Answer 15

JQuery est une base de code plus petite avec un support plus large. Si cela répond à vos besoins, cela pourrait être un bon choix. Je dirais que le compromis que vous devez décider est de savoir si l'effort de migration et la courbe d'apprentissage en valent la peine par rapport à l'ensemble de fonctionnalités plus large, à la taille de code plus petite, à la popularité réduite et à la prise en charge de JQuery.

Si le changement entre les versions de MooTools est vraiment aussi important, la migration pourrait bien être justifiée.

Answer 16

L'article mentionné sur le site Web jqueryvsmootools le dit bien:

  

Si jQuery fait du DOM votre terrain de jeu, MooTools vise à faire de JavaScript votre terrain de jeu

Donc, en conjonction avec la réponse ci-dessous "Si cela ne vous empêche pas de le réparer", je répondrais à vos besoins et non à l'opinion publique.

Étant donné que votre site est déjà dans Mootools, vous devez déterminer si jQuery propose tout ce dont vous avez besoin, ce que MooTools ne propose pas. et si le problème de la conversion est moins important que celui de l’extension.

Il semble que jQuery ait la capacité de vous permettre de jouer rapidement avec le DOM, mais tous les trucs extra-sophistiqués et autres domaines de travail (comme Dates) nécessitent un plugin.

Cela m'a également aidé à répondre à ma propre question!

Certains domaines ne se chevauchent pas, ce qui est dommage. Les interfaces graphiques sont faciles à assembler dans jQuery, avec de jolis widgets et animations. Je trouve que les outils MooTools possèdent des ensembles contenant trop peu de fonctionnalités ou sont trop lourds pour une utilisation Web générale.