Prototype VS jQuery - Forces et faiblesses?
Je ne veux pas ouvrir un autre "Encore un autre Js VS Js".
Je suppose qu'en fin de compte Prototype et jQuery sont tous deux JS et ont presque les mêmes méthodes et fonctions et nécessitent presque les mêmes lignes de code pour des tâches identiques.
Pour une vraie application Internet riche, quelles sont les forces réelles et quelles sont les faiblesses dans Prototype vs.
Au départ, j’ai aimé l’idée des éléments d’extension de Prototype avec des méthodes nouvelles ou modifiées.
Cependant, j'ai découvert un certain nombre de raisons pour lesquelles c'est une mauvaise chose (TM)
Faites des recherches sur Google et vous trouverez probablement d'autres raisons, mais la raison principale est qu'il ne peut pas être garanti que Prototype "jouera bien" avec d'autres frameworks ou bibliothèques, car d'autres bibliothèques s'attendent à ce que le comportement des éléments et des méthodes soit "standard", et à cause de ce que fait Prototype, vous pouvez trouver un certain nombre de choses qui sont brisées par celui-ci.
L'exemple le plus récent que j'ai découvert est celui du vissage de prototypes avec JSON et de stringify. J'utilisais EasyXDM et cela ne fonctionnait tout simplement pas dans certains cas où la bibliothèque prototype.js était chargée. Alors que j'écrivais un framework destiné à à d'autres , et que je n'avais donc aucun contrôle sur le contenu de la page, je devais tout créer et tout faire dans un IFRAME afin de garantir des fonctionnalités telles que prototype.js. pas faire des ravages avec ce que j'essayais de faire.
... donc jQuery gagne haut la main pour moi, car je ne pense pas que ce soit juste pour un framework de visser automatiquement avec le comportement standard du DOM et du javascript. VOUS devriez avoir le contrôle de ces choses, Prototype vous enlève une partie de ce contrôle ....
J'utilise jQuery sur prototype également, il suffit de regarder en haut de cette page pour savoir pourquoi:
jquery a tagué des questions : 531,752
prototype tagué question : 2 465
Mis à jour le 22/09/2014, le 14/12/2011 jQuery - 135,641/prototype - 2 327
jQuery est un code très concis et très concis. Je trouve le prototype beaucoup plus verbeux, bien que souvent équivalent dans de nombreux domaines pour la fonctionnalité. Cependant, si vous avez besoin d'aide pour commencer, vous voulez une communauté plus large. Plus de soutien, plus de réponses aux mêmes questions que vous avez déjà trouvées et facile à rechercher sur Google, et plus de plug-ins, de code que vous cherchez probablement pour faire quelque chose ... déjà écrit.
Pour les mêmes raisons, plus la communauté est large, plus il y a de code, plus le code complex est complexe, ce qui signifie que des éléments simples ont été écrits et que de nombreuses situations compliquées ont également été résolues. Il est donc probable que vous écriviez une application très riche. vous allez rencontrer des questions ou des situations assez compliquées ... il existe plus de ressources pour vous aider à gérer cela.
Encore une fois ... pour la même raison de taille de communauté, davantage de lacunes ont été détectées dans le cadre et les lacunes ont été comblées, car une communauté plus large le scrutait. Cela signifie que lorsque vous rencontrez un problème, il y a de fortes chances que quelqu'un d'autre l'ait fait, et une méthode ou une option a été ajoutée pour que vous puissiez continuer à avancer, sans vous coincer, car vous avez heurté quelque chose que le framework ne pouvait pas faire.
Je suis en train de réécrire de gros blocs d'une application pour passer de Prototype à jQuery. Pourquoi? Plugins, plugins, plugins, en particulier les widgets d'interface utilisateur. Les éléments prototypes de l'interface utilisateur sont plutôt fragmentés et très fragmentés, alors que jQuery possède un ensemble très riche d'éléments "standard" .
JQuery a été conçu pour faciliter l'ajout d'effets de fantaisie aux pages. Il a réussi à 100%.
Puisque les gens ont généralement besoin d’ajouter des animations et des appels ajax occasionnels à une bibliothèque Javascript, JQuery possède une grande communauté. La devise de JQuery est "Je vais ajouter un peu de brillance et me dégager de tout chemin", ce dont nous avons souvent besoin.
Néanmoins, Prototype excelle dans la plupart des autres cas d'utilisation. Il a un cadre stable pour les classes OOP (résolvant uniformément les problèmes tels que l’héritage des constructeurs), et un bon ensemble d’abstractions d’utilisation générale pour traiter les données.
J'ai choisi jQuery sur Prototype car:
- le "fais plus, écris moins ..."
- la communauté jQuery est plus grande (d'où plus de plugins et de ressources)
J'ai utilisé les deux et j'aime les deux. Cela dépend vraiment des exigences de votre projet. Pour moi, il semble que les deux plates-formes viennent de 2 directions différentes en raison de 2 exigences différentes. Ils ont tous deux été créés pour répondre à la nécessité de résoudre les problèmes de programmation afin de créer des sites Web/des applications plus rapides et plus performants.
Pour créer rapidement des sites Web, jQuery et sa bibliothèque sont parfaits avec une boîte à outils standard. Inutile de réinventer la roue. Cependant, je rencontre un problème de version de navigateur inhabituel lorsque mon outil/astuce ne fonctionne pas et qu'il arrive toujours que ce soit le client qui possède cette version spécifique. Cela se produit généralement lorsqu'une version du navigateur est publiée/mise à jour. Donc, je dois ensuite aller chercher la nouvelle version de ce fichier de bibliothèque jquery pour mettre à jour tous mes sites, si la communauté a déjà remarqué et résolu le problème. C’est ma seule bêtise parce que je n’ai pas le temps de le découvrir moi-même. Cela n'arrive pas souvent mais arrive.
Lorsque je travaille sur des projets Web plus complexes, peut-être un réseau de sites pris en charge avec des API back-end, le prototype est excellent. Je profite pleinement du codage côté serveur OO et suis très heureux de pouvoir faire de même avec Prototype. J'ai l'impression d'avoir plus de "contrôle" sur mes applications et de pouvoir réparer les choses rapidement car je suis l'auteur. J'entends bien ce que les gens disent au sujet des frais généraux, des DOM étendus, etc., mais je n'ai pas rencontré de problème majeur (cogner du bois). En outre, le fait de ne pas avoir d'instruction 'pour chaque' n'est pas vraiment un problème, car je peux tout aussi facilement itérer la même variable avec .each (function () {}, ..) et avec un peu plus de contrôle.
Ainsi, chacun a sa place et vous devez choisir votre propre médicament.
Comme,
Ni est le "meilleur". Tout dépend. Essayez les deux et voyez lequel vous aimez le plus. Personnellement, j’utilise JQuery en raison de la facilité d’utilisation par rapport au prototype, qui est plutôt avancé et a une courbe d’apprentissage plus longue.
Jettes un coup d'oeil à:
jQuery utilise des sélecteurs et des filtres de style CSS basés sur la syntaxe CSS. Du point de vue de la conception, cela présente de nombreux avantages. J'aime beaucoup CSS et j’ai beaucoup de connaissances à ce sujet, donc jQuery se sent chez moi personnellement. Si vous recherchez une syntaxe pour rendre votre expérience de codage complète plus agréable et que vous êtes un grand fan de/compétent de CSS, il est prudent de dire que vous préférerez jQuery aux alternatives. J'ai suivi un cours élémentaire en Prototype et je me suis ennuyé jusqu'aux larmes. Je viens juste de terminer "The Essentials of jQuery" sur Lynda's et je l'adore, car il est étroitement lié à CSS. Je programme en langage JavaScript avec Vanilla depuis environ 10 ans et je l’ai toujours trouvé extrêmement sec; et pour moi c'est code overkill (pas beaucoup pour le prix). Bien que cela m'a été très utile au fil des ans. D'après ce que j'ai vu jusqu'à présent, jQuery est ce que JavaScript devrait être depuis le premier jour. Mais là encore, cela prend beaucoup de temps, de tests et d’efforts pour améliorer les choses. Alors jQuery gagne pour moi.
Ceci est un autre article intéressant sur jQuery et MooTools (MooTools et Prototype sont principalement interchangeables, du moins dans le contexte de ce débat): http://jqueryvsmootools.com/
Je ne connais pas encore jQuery ou Prototype. Sur le point de commencer à apprendre l’un d’eux à ajouter à ma boîte à outils en tant que développeur et chef de projet ColdFusion senior. Mon point de vue est au départ celui qui sera choisi par le nouvel arrivant car il reflète l’adoption de l’industrie, élément essentiel de l’IMHO.
Après un coup d’œil rapide et quelques lectures de didacticiel sur ces deux aspects, il semble que chacun offre les mêmes capacités fondamentales. Cependant, en ce qui concerne les offres d'emploi et d'autres projets, jQuery semble être beaucoup plus "demandé" par opposition à une compétence que l'on peut utiliser. Pour moi, jQuery gagne ici avec adoption et demande, le support de la communauté et la documentation est un atout. Rien contre Prototype, il est bon de savoir si un projet le nécessite en raison de sa pré-existence, car un développeur l'a choisi comme premier investisseur.
j'ai utilisé prototype framework et jquery, et quant à moi, j'aime personnellement jquery cuz de son noConflict (); Je préfère utiliser le jq noConflict comme ceci dans mes fichiers js
(function($){
}(jQuery));
de cette manière, vous utiliserez le sélecteur $ as you jquery par fichier js
En souscrivant la réponse correcte marquée et déjà signée, je ne souhaite pas non plus partager une bibliothèque vous permettant d'utiliser la plupart des utilitaires que vous vous attendez à trouver sur un framework tel que prototype, mais avec l'avantage de ne pas étendre les objets natifs. En conséquence, il vous offre plus de contrôle et de flexibilité sur les frameworks complémentaires que vous souhaitez utiliser tout au long de votre projet.
Underscore est une bibliothèque de ceinture d’utilitaires pour JavaScript qui fournit un fichier beaucoup du support de programmation fonctionnelle que vous attendez dans Prototype.js (ou Ruby), mais sans prolonger l’intégré Objets JavaScript. C'est la cravate qui va avec Tux de jQuery, et Les bretelles de Backbone.js.
Pourrais-je également avancer l'argument selon lequel utiliser l'un ou l'autre est un faux dilemme? Ayant beaucoup d’expérience avec jQuery, je sais à quel point cela peut être bénéfique et à quel point le développement d’applications pourrait devenir plus rapide.
Cependant, il est important de noter qu'il peut être plus avantageux pour les utilisateurs finaux de ne pas utiliser de bibliothèque du tout, en particulier dans les cas où cela n'est pas nécessaire. Bien que cela soit certainement utile pour les applications volumineuses, il peut être contre-intuitif d’être utilisé sur le site Web commun en raison de son impact sur les performances.
Une requête HTTP supplémentaire est effectuée pour télécharger la bibliothèque et, bien que généralement petite lorsqu'elle est réduite, il faut davantage de bande passante. Cela risque de ralentir le temps de chargement des pages, ce qui peut être réalisé par les utilisateurs mobiles.
De plus, lors du chargement, une bibliothèque exécute immédiatement le code pour créer des fonctions et des objets accessibles de manière globale, consommant ainsi davantage de mémoire même si vous ne les utilisez jamais. Certaines bibliothèques ajouteront également des fonctions et des objets aux prototypes d'objets intégrés , ce qui augmente également l'utilisation de la mémoire.
Enfin, bien que jQuery et de nombreuses autres bibliothèques fassent souvent l'objet de tests approfondis pour garantir le moins d'impact possible sur les performances, le code que vous écrivez, bien que moins volumineux, sera souvent plus lent que autrement. Gardez à l'esprit que tout ce que vous pouvez faire avec une bibliothèque que vous pouvez faire avec du JavaScript brut, puisque fondamentalement ils sont identiques.