IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

jQuery Discussion :

jQuery vs Prototype


Sujet :

jQuery

  1. #1
    Membre expérimenté
    Avatar de gwyohm
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Octobre 2007
    Messages
    925
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Octobre 2007
    Messages : 925
    Points : 1 333
    Points
    1 333
    Par défaut jQuery vs Prototype
    Bonjour à tous.

    Je suis un grand fan de la librairie prototype, mais connais finalement peu jQuery.

    Pour un projet, nous nous posons la question du framework à employer, et nous hésitons entre prototype et jQuery (que d'autres de l'équipe connaissent, mais sans connaitre prototype).

    Je cherche donc des témoignages objectifs de personnes ayant utiliser les 2 technologies pour avoir leurs impressions quant aux points forts/faiblesses de chacun.

    Mes sentiments (sans doute faux, ne connaissant que prototype) sont que :
    • jQuery est beaucoup plus simple à utiliser pour la manipulation du dom, l'écouté d'événements
    • prototype intègre plus de surcharges au niveau du langage que jQuery (les Ranges, Templates), ainsi que sur les objets natifs (tels que Function, Array...)
    • jQuery propose via sa notion de plugins d'une plus grande communauté, donc de beaucoup de plugins, mais dont la qualité et la pérennité s'en trouvent de fait plus "hasardeuse"
    • l'investissement d'entrée dans jQuery est moins important que prototype (prototype requiert de bien connaitre tout ce qui est disponible pour écrire du code performant)
    • jQuery semble moins standardisé sur certaines méthodes (des étourderies qui ont été maintenues pour compatibilité ascendante) voir ce billet
    • prototype propose en standard un système de POO plus abouti que jQuery sans un plugin particulier


    Bien sur ces arguments en faveur de l'un ou l'autre sont critiquables, et c'est l'objet de ce message.

    Merci de vos retours.

    Edit: Je reste convaincu que les 2 librairies sont très bonnes, mais que l'emploi de l'une ou l'autre relève plus de ce dont on a besoin
    on ne dit pas "ça ne marche pas" on dit "je suis incapable de faire fonctionner correctement les outils mis à ma disposition"
    Pas de question technique par MP

  2. #2
    Rédacteur/Modérateur

    Avatar de SpaceFrog
    Homme Profil pro
    Développeur Web Php Mysql Html Javascript CSS Apache - Intégrateur - Bidouilleur SharePoint
    Inscrit en
    Mars 2002
    Messages
    39 637
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 74
    Localisation : Royaume-Uni

    Informations professionnelles :
    Activité : Développeur Web Php Mysql Html Javascript CSS Apache - Intégrateur - Bidouilleur SharePoint
    Secteur : Industrie

    Informations forums :
    Inscription : Mars 2002
    Messages : 39 637
    Points : 66 662
    Points
    66 662
    Billets dans le blog
    1
    Par défaut
    jquery propose beaucoup de plugin ...
    est secondé par les effets easing et les composant ui
    Ma page Developpez - Mon Blog Developpez
    Président du CCMPTP (Comité Contre le Mot "Problème" dans les Titres de Posts)
    Deux règles du succès: 1) Ne communiquez jamais à quelqu'un tout votre savoir...
    Votre post est résolu ? Alors n'oubliez pas le Tag

    Venez sur le Chat de Développez !

  3. #3
    Rédacteur
    Avatar de Arnaud F.
    Homme Profil pro
    Développeur COBOL
    Inscrit en
    Août 2005
    Messages
    5 183
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France

    Informations professionnelles :
    Activité : Développeur COBOL
    Secteur : Finance

    Informations forums :
    Inscription : Août 2005
    Messages : 5 183
    Points : 8 873
    Points
    8 873
    Par défaut
    Bonjour,

    pour avoir développé un projet en Prototype à une époque ou jQuery n'était pas aussi abouti, et devant apporter des évolutions assez conséquentes aujourd'hui, je me suis penché sur le cas jQuery justement.

    jQuery vs prototype, quel débat !

    Mais de mon point de vue, tout deux ont leurs points fort / faible, en fait le framework à utiliser dépend vraiment de ce qui va tourner derrière.

    Pour le projet que j'ai réalisé en Prototype, on va dire que c'est un "simcity-like", à savoir pouvoir créer des "bâtiments", les glisser/déposer pour pouvoir reproduire le quartier, la ville. Sauvegarder le tout en base. Ensuite pouvoir, pour chaque bâtiment en question, déposer des éléments à l'intérieur (définir les pièces mais en très grosse maille) et là aussi en glisser/déposer.

    A l'époque, c'était Prototype & Scriptaculous, jQuery était en bêta et la partie UI inexistante, le choix était vite fait, sachant que Prototype dispose quand même de pas mal de fonctionnalités.

    Je me suis récemment replongé dans le code et je dois bien avouer que je ne sais pas comment on a pu développer des choses pareilles à l'époque, l'écriture Prototype me paraît un peu fouillis, non lisible et non "naturelle".

    J'ai mis pas mal de temps à retomber sur mes pieds.

    Le seul vrai avantage que je vois à Prototype aujourd'hui, c'est la notion de classe et pouvoir faire du pseudo objet, ce qui n'est pas présent en tant que tel dans jQuery.

    Je trouve que depuis le temps, l'API n'a pas beaucoup évoluée, la communauté s'est un peu essouflée.

    Passons sur jQuery.

    Je ne connaissais pas se framework mais j'en avais beaucoup entendu parlé, je me suis donc mis à tester sur une page type. J'ai bizarrement mis beaucoup (mais alors beaucoup) moins de temps à comprendre et appréhender les subtilités de jQuery qu'avec Prototype à l'époque. jQuery propose une API de base juste phénoménale.

    J'ai refais une page à l'équivalent jQuery, le code est :
    • Beaucoup plus lisible
    • Beaucoup plus évolutif / maintenable
    • Beaucoup plus concis ! (Prototype : ~800 lignes de code / jQuery : ~300 lignes de code) Sans pour autant être moins compréhensible, au contraire même !


    Au niveau des performances, l'appli en question est très gourmande en ressource, au point que lors du chargement, elle met ~1m sur IE6 (contre 2 secondes sur FF/Chrome ), le passage de Prototype a jQuery n'a quasi rien changé de ce côté là, mais j'ai vu que dans la dernière release jQuery, des évolutions énormes ont été apportées côté perfs, donc à voir.

    Choses que j'apprécie également énormément dans jQuery c'est le système de cache global / à l'élément qui est disponible (via $.data()), c'est juste surpuissant et ça manque à Prototype.

    A noter que le manque de classe côté jQuery peut être compensé par la création de widgets, qui utilisé à bon escient est juste une pure merveille, une pure tuerie, je vais en faire un article d'ailleurs.

    Bref, tout le côté plugin de jQuery est bien, même si j'en utilise aucun (jQuery se suffit à lui-même, soyons honnête) et au besoin, il est très facile de développer les siens (genre l'API de prototype? ), ainsi que de développer ses propres sélecteurs !

    Un exemple tout bête, l'appli que je développe, les divs sur lesquelles je fais un .building() (pour dire que c'est des bâtiments), je peux directement les retrouver avec le sélecteur $(":building"), pas besoin de rajouter de classes particulières, il gère automatiquement les sélecteurs, et tout un tas d'opérations de base. Je veux rechercher un bâtiment par son nom (une métadonnée), là non plus, je peux écrire mon propre sélecteur, du genre :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    jQuery.expr[':']["building-name"] = function(ui, index, name) {
        try
        {
            return $.data(ui, "building").options.name == name[3]
        } catch(e)
        {
            return false;
        }
    };
    Pour ensuite, n'avoir plus qu'a faire :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    $(":building-name('BATIMENT1')")
    pour sélectionner un élément du DOM par son nom.

    Eh oui, ça fait beaucoup de jQuery tout ça, tout n'est pas beau et rose non plus avec jQuery mais je dois bien avouer que si c'était à refaire je ne prendrai plus Prototype...

    Cependant, je reste tout à fait d'accord avec les pour et contre que tu as cité (excepté pour la surcharge des opérateurs )


    Je suis prêt à toute discussion ou apport de compléments d'infos pour étayer (/ détruire ) ce que j'ai dis
    C'est par l'adresse que vaut le bûcheron, bien plus que par la force. Homère

    Installation de Code::Blocks sous Debian à partir de Nightly Builds

  4. #4
    Membre expérimenté
    Avatar de gwyohm
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Octobre 2007
    Messages
    925
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Octobre 2007
    Messages : 925
    Points : 1 333
    Points
    1 333
    Par défaut
    Bonjour, et merci pour ces premiers retours
    Citation Envoyé par Arnaud F. Voir le message
    Mais de mon point de vue, tout deux ont leurs points fort / faible, en fait le framework à utiliser dépend vraiment de ce qui va tourner derrière.
    +1
    J'aimerai arriver à définir les points qui vont faire pencher la balance pour l'un ou l'autre.
    Citation Envoyé par Arnaud F. Voir le message
    Je me suis récemment replongé dans le code et je dois bien avouer que je ne sais pas comment on a pu développer des choses pareilles à l'époque, l'écriture Prototype me paraît un peu fouillis, non lisible et non "naturelle".
    As-tu des exemples à donner ? Par connaissance de Prototype, j'ai tendance à penser le contraire...
    Citation Envoyé par Arnaud F. Voir le message
    Je trouve que depuis le temps, l'API n'a pas beaucoup évoluée, la communauté s'est un peu essouflée.
    La dernière release apporte pourtant beaucoup de nouveautés (Sizzle, gestion des événements simplifiée, reporting plus précise sur les dimensions des éléments du dom...)
    Citation Envoyé par Arnaud F. Voir le message
    Passons sur jQuery.
    ...
    J'ai bizarrement mis beaucoup (mais alors beaucoup) moins de temps à comprendre et appréhender les subtilités de jQuery
    Ca rejoint un point que j'avais soulevé : le coût du ticket d'entrée est plus faible sous jQuery
    Citation Envoyé par Arnaud F. Voir le message
    le code est :
    • Beaucoup plus lisible
    • Beaucoup plus évolutif / maintenable
    • Beaucoup plus concis ! (Prototype : ~800 lignes de code / jQuery : ~300
    C'est peut-être lié au point précédent ; encore une fois le défaut majeur de prototype est en même temps sa force : il faut connaitre l'API dans son ensemble pour l'utiliser correctement.
    Citation Envoyé par Arnaud F. Voir le message
    Choses que j'apprécie également énormément dans jQuery c'est le système de cache global / à l'élément qui est disponible (via $.data()), c'est juste surpuissant et ça manque à Prototype.
    Ca existe, voir les méthodes store et retrieve
    Citation Envoyé par Arnaud F. Voir le message
    A noter que le manque de classe côté jQuery peut être compensé par la création de widgets, qui utilisé à bon escient est juste une pure merveille, une pure tuerie, je vais en faire un article d'ailleurs.
    J'ai lu en diagonale, mais le concept de class dans Prototype ne se base pas uniquement sur des Elements du DOM, ca permet de réaliser des choses beaucoup plus métier.
    Citation Envoyé par Arnaud F. Voir le message
    Bref, tout le côté plugin de jQuery est bien, même si j'en utilise aucun
    Si on n'en a pas besoin tant mieux, mais je sais par experience que l'emploi d'un plugin non réalisé par l'équipe core peut amener des problèmes (collisions) ; de plus, les "garage-band" plugins sont moins bien maintenus.
    Citation Envoyé par Arnaud F. Voir le message
    Un exemple tout bête ... je peux directement les retrouver avec le sélecteur $(":building") ... je peux écrire mon propre sélecteur...
    Pour ensuite, n'avoir plus qu'a faire :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    $(":building-name('BATIMENT1')")
    Séduisant, en effet...
    Citation Envoyé par Arnaud F. Voir le message
    tout n'est pas beau et rose non plus avec jQuery
    As-tu des exemples ?
    Citation Envoyé par Arnaud F. Voir le message
    Cependant, je reste tout à fait d'accord avec les pour et contre que tu as cité (excepté pour la surcharge des opérateurs )
    Qu'entends-tu par là ?

    Merci encore pour ces retours !
    on ne dit pas "ça ne marche pas" on dit "je suis incapable de faire fonctionner correctement les outils mis à ma disposition"
    Pas de question technique par MP

  5. #5
    Rédacteur
    Avatar de Arnaud F.
    Homme Profil pro
    Développeur COBOL
    Inscrit en
    Août 2005
    Messages
    5 183
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France

    Informations professionnelles :
    Activité : Développeur COBOL
    Secteur : Finance

    Informations forums :
    Inscription : Août 2005
    Messages : 5 183
    Points : 8 873
    Points
    8 873
    Par défaut
    Citation Envoyé par gwyohm Voir le message
    +1
    J'aimerai arriver à définir les points qui vont faire pencher la balance pour l'un ou l'autre.
    Dans ce cas, peut-être vaudrait-il mieux prendre le problème dans l'autre sens à savoir que tu nous décrive brièvement ce que tu souhaite faire

    Si c'est plus orienté graphique & modifications des éléments du DOM ou plutôt de l'intelligence métier avec des objets / des classes, etc.

    Citation Envoyé par gwyohm Voir le message
    As-tu des exemples à donner ? Par connaissance de Prototype, j'ai tendance à penser le contraire...
    Faudrait que je recherche , mais sur la partie Ajax en tout cas, on peut facilement éviter de faire un traitement redondant en utilisant $.ajaxSetup

    Citation Envoyé par gwyohm Voir le message
    La dernière release apporte pourtant beaucoup de nouveautés (Sizzle, gestion des événements simplifiée, reporting plus précise sur les dimensions des éléments du dom...)
    Faudrait que j'y rejette un oeil ...

    Citation Envoyé par gwyohm Voir le message
    C'est peut-être lié au point précédent ; encore une fois le défaut majeur de prototype est en même temps sa force : il faut connaitre l'API dans son ensemble pour l'utiliser correctement.
    Oui, mais à l'époque elle était pas si étoffée non plus et je trouve assez "bof" d'avoir une casquette "expert" pour pouvoir utiliser le framework à fond

    Citation Envoyé par gwyohm Voir le message
    Ca existe, voir les méthodes store et retrieve
    C'est nouveau ça

    Citation Envoyé par gwyohm Voir le message
    J'ai lu en diagonale, mais le concept de class dans Prototype ne se base pas uniquement sur des Elements du DOM, ca permet de réaliser des choses beaucoup plus métier.
    C'est bien ça, c'est bien un widget, à savoir que ça touche forcément à un élément du DOM. C'est là, la limitation de jQuery (même s'il existe un plugin pour gérer créer des classes à la Prototype). La philosophie n'est pas la même.

    Et oui, tu as mis le doigt sur la bonne chose, à savoir que jQuery est très orienté UI et laisse la notion de classe objet un peu de côté, tandis que Prototype est plutôt du côté métier, faire de l'objet avec tous les avantages que ça apporte.

    Citation Envoyé par gwyohm Voir le message
    Si on n'en a pas besoin tant mieux, mais je sais par experience que l'emploi d'un plugin non réalisé par l'équipe core peut amener des problèmes (collisions) ; de plus, les "garage-band" plugins sont moins bien maintenus.
    C'est le problème de tout plugin mais pour ma part, je n'ai aucun mal à les éviter, il y a quand même déjà énormément de choses disponibles dans la version de base.

    Citation Envoyé par gwyohm Voir le message
    As-tu des exemples ?
    Je m'étais mal exprimé, c'était par rapport à cette phrase que je voulais réagir :

    prototype intègre plus de surcharges au niveau du langage que jQuery (les Ranges, Templates)
    jQuery a fait beaucoup d'effort, et notamment sur la notion de templates, je t'encourage à y jeter un oeil car c'est en natif depuis la version 1.4+ et c'est très très séduisant. Mais là encore, tout dépend ton besoin.
    C'est par l'adresse que vaut le bûcheron, bien plus que par la force. Homère

    Installation de Code::Blocks sous Debian à partir de Nightly Builds

Discussions similaires

  1. jQuery et prototype
    Par benjibul dans le forum jQuery
    Réponses: 1
    Dernier message: 14/10/2011, 22h18
  2. Cohabitation Jquery et Prototype
    Par almoha dans le forum jQuery
    Réponses: 3
    Dernier message: 20/07/2011, 23h35
  3. Conflit entre jQuery et Prototype
    Par Rahim-US dans le forum Général JavaScript
    Réponses: 2
    Dernier message: 29/09/2010, 17h01
  4. Réponses: 5
    Dernier message: 22/01/2008, 13h11
  5. Réponses: 3
    Dernier message: 07/01/2008, 10h09

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo