8
votes

Quelles sont les différences actuelles entre jQuery et prototype?

Je construis un site Ruby sur Rails au cours des derniers mois et je n'ai utilisé qu'une petite quantité de fonctions javascript intégrées. Cependant, je ferai beaucoup plus de développement JavaScript dans les prochaines semaines et des mois et je débris sur quel cadre JavaScript pour aller avec.

D'une part, JQuery semble être le plus populaire, mais encore un prototype est déjà intégré à des rails. J'ai également lu un groupe d'articles en ligne d'il y a quelques années en train de parler de la façon dont JQuery est plus concis à certaines choses mais négligentes sur d'autres et donnant diverses autres opinions.

Donc, mes questions sont aux personnes qui ont utilisé les deux (de préférence récemment) :

  • Quelle est la différence d'utilisation du prototype et de la jQuery d'un pure JavaScript et d'un point de vue de Ruby sur rails?
  • Y a-t-il une différence significative entre eux ou sont-ils maintenant assez proches les uns des autres en termes de fonctionnalité et de rédaction de code?
  • Quelle est la hauteur du coût de commutation en termes de choses qui doivent être relacieuses et que le code doit être réécrit?

    merci


0 commentaires

4 Réponses :


13
votes

Discussion précédente

Beaucoup, sinon toutes vos questions ont déjà été discutées. Voir le Recherche ou:

  • Comment allez-vous continuer à changer un site de prototype sur jQuery
  • prototype, dojo ou jQuery?
  • Pourquoi tout le monde aime JQuery plus que prototype / script.aclo.aclo.us ou mootools ou quoi que ce soit?
  • Est-il vrai que JQuery + Rails est problématique?
  • Utilisation de jQuery dans les rails

    commutation du prototype à jQuery

    Je suis en train de passer de Protoype à JQuery, principalement pour des raisons de performance (j'ai vu trop de points de repère avec prototype toujours arrivé à JQuery, mousse et dojo.) Je dirais que le coût de commutation n'est pas horrible , parce que la plupart des concepts de base (sélection, effets, ajax) sont très similaires. Cependant, toutes les lignes de code de prototype doivent être soigneusement réécrites - soigneusement surtout parce que de nombreuses assistantes fonctionnelles et constructions ( $ $$ ) semblent trompeuses.

    Si votre code contient de nombreuses constructions chaînées complexes pouvant être disponibles à JQuery, mais fonctionner différemment, la migration peut devenir une tâche très encombrante. Si vous n'utilisez que la sélection rapide de l'élément, des effets et un peu d'Ajax, pas tellement.

    De toute façon, préparez-vous à une phase d'apprentissage intense. Les constructions de JQuery sont petites et intelligentes, mais sont terribles à lire IMHO (et d'avoir l'air terrible par rapport à un bloc de JavaScript natif, mais c'est une discussion différente). Il faut définitivement du temps pour se familiariser avec la syntaxe et les principes si vous venez d'un cadre différent ou de JavaScript natif.


0 commentaires

3
votes

Il y a une très grande différence à la manière dont vous travaillez avec JQuery par rapport au prototype, une fois que vous vous êtes habitué aux nuances des cadres, il devient assez facile de basculer entre l'un d'eux.

Le plus grand obstacle au début est le fait que le prototype se comporte tout de suite dans le DOM. Dès que vous l'inclurez dans la page, tous les éléments DOM que vous recherchez auront la fonctionnalité de prototype attachée à celle-ci. Avec JQuery, il laisse tous les éléments seuls jusqu'à ce que vous accédez à un avec le sélecteur JQuery $ ('CSS-Class'). L'objet que vous recevez de cet appel aura les méthodes jQuery attachées.

Si vous voulez vous fatiguer à JQuery, vous pouvez tout laisser à l'aide de prototype et inclure jQuery et appelez jquery.noconflic (); http://docs.jquerery.com/core/jquery.noconflic . Cela donnera à la méthode «$» de retour au prototype et vous permettra d'utiliser JQuery en appelant plutôt JQuery ('CSS-Class').

Si vous souhaitez sauter complètement dans JQuery, je vous recommanderais d'utiliser le plugin Jrails ( http://github.com / Aaronchi / Jrails ). Il remplacera tous les aidateurs AJAX et les avoir utilisez jQuery au lieu de prototype. Je l'ai fait dans un certain nombre de projets et n'avez jamais eu de problèmes.

À la fin, vous devriez simplement jeter un coup d'œil au prototype et à jQuery et à voir lequel convient à votre style de codage. Vous pouvez accomplir les mêmes choses avec les deux cadres, c'est juste une syntaxe légèrement différente et une façon de penser pour chacun.


0 commentaires

2
votes

JQuery est plus efficace pour les petits effets de clients intelligents. prototypejs est plus efficace pour le développement JavaScript profond.

jQuery a une foule de plugins pour des effets d'interface utilisateur robustes. prototypejs a une bibliothèque complète pour les énumérables, les fonctions, les hachages.


5 commentaires

Qu'est-ce qui vous fait dire que le prototype est plus efficace pour le développement JavaScript profond? La bibliothèque elle-même est plus efficace? Vous en tant que développeur sont plus efficaces?


Presque tout dans JQuery est lié à la DOM. Mais prototypejs propose de nombreuses méthodes de fonction incroyablement utiles (curry, enveloppe ...: API.Prototypejs.org/ Langue / Fonction.html ) et un objet énumérable avec une API merveilleuse (invoquez, cueillette ...: API.Prototypejs.org/Language/Enumérable.html )


Donc, ce que je veux dire par "est plus efficace pour" est "offre des fonctionnalités avancées pour" et donc "nous rend plus efficaces pour".


D'accord, c'est ce que je pensais que vous vouliez dire, je voulais juste être sûr :). Concernant les fonctionnalités les plus avancées, Sadscore.js ( documentCloud.github.com/underscore ) a beaucoup de ce que vous avez mentionné et maille bien avec JQuery. Je crois qu'il y a aussi un plugin énumérable pour flotter jQuery, bien que je n'ai jamais vraiment ressenti le besoin de tout cela.


Underscore.js a fière allure. Je suppose que le développement de JQuery de Ruby On Rails serait moins étrange avec cette bibliothèque.



9
votes

La réponse de Pekka est excellente, mais une chose à ajouter est que les rails se déplacent fortement dans la direction d'être le cadre javascript agnostique. Bien que lorsque les rails soient sortis pour la première fois, son intégration Ajax était innovante, le paysage JavaScript a radicalement changé depuis, et l'intégration des rails ne respecte plus les meilleures pratiques. En tant que tel, l'intégration prototype ne doit pas être considérée comme un facteur majeur aujourd'hui sur les rails 2.3, et il sera encore moins important dans les rails 3.0 qui seront probablement libérés dans les prochains mois. J'ai récemment lu un article intéressant décrivant Quelques-uns des changements les plus importants dans l'intégration JavaScript des rails dans des années.

Mon projet actuel comporte des milliers de lignes de code de prototype hérité, mais nous avons récemment commencé à utiliser JQuery parce que ses avantages étaient trop grands pour passer. Mes impressions:

prototype est un cadre mature qui fait un très bon travail en train de diffuser des différences de navigateur et de fournir une fonctionnalité très bien équilibrée. Malheureusement, il est un peu lourd avec ses modifications apportées à l'environnement JavaScript par défaut et ne voit pas le développement rapide et n'a pas d'écosystème de plugin significatif.

jQuery est un nouveau cadre capable de tirer parti des enseignements des premiers-cadres javascript tels que le prototype de créer quelque chose de plus modulaire, moins inexigrant et de manière significative plus puissante et concise. J'aime toujours le prototype, mais l'écosystème de la manipulation et du plugin de JQuery's Dom est trop beau pour ignorer plus. Si je commençais un projet Greenfield, je devrais aller avec JQuery parce que cela semble être où l'innovation se passe (au moins entre ces deux choix).


0 commentaires