jQuery vs Prototype

[gwyohm]

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

[SpaceFrog]

jquery propose beaucoup de plugin ...
est secondé par les effets easing et les composant ui

[Arnaud F.]

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 :

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 :

$(":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

[gwyohm]

Bonjour, et merci pour ces premiers retours

Envoyé par Arnaud F.

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.

Envoyé par Arnaud F.

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...

Envoyé par Arnaud F.

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...)

Envoyé par Arnaud F.

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

Envoyé par Arnaud F.

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.

Envoyé par Arnaud F.

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

Envoyé par Arnaud F.

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.

Envoyé par Arnaud F.

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.

Envoyé par Arnaud F.

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 :

$(":building-name('BATIMENT1')")

Séduisant, en effet...

Envoyé par Arnaud F.

tout n'est pas beau et rose non plus avec jQuery

As-tu des exemples ?

Envoyé par Arnaud F.

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 !

[Arnaud F.]

Envoyé par gwyohm

+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.

Envoyé par gwyohm

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

Envoyé par gwyohm

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 ...

Envoyé par gwyohm

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

Envoyé par gwyohm

Ca existe, voir les méthodes store et retrieve

C'est nouveau ça

Envoyé par gwyohm

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.

Envoyé par gwyohm

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.

Envoyé par gwyohm

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.