Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

jQuip : naissance d'un jQuery lite
Qui embarquerait 90 % des fonctionnalités du framework pour seulement 13 % de sa taille

Le , par Idelways

20PARTAGES

4  0 
Alors que jQuery tente de perdre du poids et fait péniblement le ménage dans ses API, certains développeurs s'impatientent. Le framework JavaScript ne dispose en effet pas d'un générateur officiel permettant de créer sa version minimaliste personnalisée à l'instar du MooTools Builder.

Ceux qui ne peuvent plus se passer du framework populaire se retrouvent souvent obligés d'inclure près de 100Ko (minifiés et non compressés) supplémentaires dans leur page pour n'en utiliser qu'une poignée de méthodes.

D'où la naissance de jQuip (JQuery-in-parts), une bibliothèque open source à part entière, sorte de fork temporaire dédié à l'amaigrissement du framework.

Ses développeurs promettent 90 % des « bonnes parties » de jQuery pour 13 % de la taille du framework (soit seulement 4.28 Ko minifiés et gzippés). Le reste pourra être complété via plug-ins, affirment-ils.

jQuip Library Builder est une ébauche de générateur en ligne permettant d'ajouter les callbacks du docready, les méthodes CSS et Ajax et certaines « extensions utiles du Core ».

Le but affiché par les développeurs de jQuip est de : « pousser jQuery.com à réorganiser sa base de code de sorte qu'elle soit plus modulaire, du moment que nous croyons avoir prouvé que les parties les plus utiles de jQuery ne sont qu'une fraction de sa base de code », nous apprend le README du compte GitHub.

L'équipe de jQuip estime en prime avoir optimisé certains rouages internes du framework. Parcourir le DOM serait à titre d'exemple 7 à 8 fois plus rapide sur Internet Explorer 6 et 7, aux frais de quelques couacs à réparer.

Si le concept du projet jQuip ne trouve pas grâce aux yeux de la core-team de jQuery, faudra-t-il d'après vous forker officiellement le framework ?

Télécharger jQuip

Source : compte GitHub du projet

Et vous ?

Que pensez-vous de jQuip ?
Comment percevez-vous son utilité ?
Fera-t-il bouger les choses du côté du jQuery ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de savageman86
Membre habitué https://www.developpez.com
Le 22/11/2011 à 10:39
Je viens d'aller voir vite fait parce que ça m'a interpellé et... Effectivement il y a un peu de la pub mensongère dans leur approche...

13% de la taille, c'est pas pour 90% des fonctionnalités. 13%, c'est sans domready, sans $.ajax et $.css.
90% des fonctionnalités de jQuery sans $.ajax et sans $.css, non quoi.

Ce n'est pas la seule initiative de ce style. Par exemple, Zepto.js se vante d'être compatible jQuery également pour une taille très réduite.

Ceci dit, si ça pouvait accélérer la team jQuery à proposer des solutions pour avoir un fichier plus petit c'est bien. Un builder par exemple ?
4  0 
Avatar de grunk
Modérateur https://www.developpez.com
Le 22/11/2011 à 9:06
Très bonne initiative qui espérons poussera jquery dans ce sens. J'avais à l'époque abandonné prototype pour jquery en partie à cause de sa taille réduite. Aujourd'hui on retombe dans les même travers de librairie très lourde pour parfois pas grand chose.

Pour en revenir à jQuip je trouve quand même assez discutable de placer le DOM ready dans un plugin. C'est quand même bien souvent a première ligne de JS que l'on écrit avec jquery.
3  0 
Avatar de YannPeniguel
Membre éprouvé https://www.developpez.com
Le 22/11/2011 à 9:43
L'équipe de jQuip estime en prime avoir optimisé certains rouages internes du framework. Parcourir le DOM serait à titre d'exemple 7 à 8 fois plus rapide sur Internet Explorer 6 et 7, aux frais de quelques couacs à réparer.
La multiplication de la vitesse d'execution ne sert à rien si le framework fait des couacs.

Parce que sinon, dans ce cas, je vous fait un gateau en 10 minutes au lieu de 45 minutes, vous allez vous régaler...
3  0 
Avatar de YannPeniguel
Membre éprouvé https://www.developpez.com
Le 23/11/2011 à 10:40
Citation Envoyé par vivoli12 Voir le message
Sauf que certains modifie le code jQuery sans changer le nom du fichier.
Bon après le navigateur pourrait par exemple comparer le poids du fichier pour savoir s'il le télécharge ou non. Et ça doit être assez rare que des gens bidouille directement le code jQuery.
Si je remplace un caractère par un autre dans un fichier, il aura le même poids mais sera différent.

Cadeau: http://fr.wikipedia.org/wiki/Hash
1  0 
Avatar de pmithrandir
Expert éminent https://www.developpez.com
Le 24/11/2011 à 14:59
En plus, on ne peut pas modifier le code d'une url CDN.

je suis plutôt sur des application web, donc peu concernée par les utilisateurs uniques, mais franchement, cette idée de rigueur sur le poids de la page pour une librairie, ca me parait bizarre...

En plus, si vous savez développer, vous ne changez normalement pas la librairie elle même...(il est relativement rare de trouver des bugs dans ce genre de librairie...)
1  0 
Avatar de dtcSearch
Membre actif https://www.developpez.com
Le 22/11/2011 à 10:24
EXCELLENT!!

En soit c'est pas utilisable (faut pas abuser non plus), mais c'est claire que là, la jQuery Team à quand même matière à satisfaire ceux qui ne veulent pas un bulldozer pour soulever 3 cailloux.

La balle est dans leur camp.
0  0 
Avatar de Jay13mhsc
Membre du Club https://www.developpez.com
Le 22/11/2011 à 15:27
OUI pour donner l'exemple, et à condition que le fork soit temporaire

NON si le fork doit persister, et même si la team jquery refuse

Dans le cas contraire, ça risque de créer un chaos qui va au final n'être bénéfique à aucun des deux... et tout le monde ira voir ailleurs !
1  1 
Avatar de pmithrandir
Expert éminent https://www.developpez.com
Le 22/11/2011 à 16:23
Je me trompe peut être, mais la taille d'une librairie est si importante maintenant ?

Je m'explique, avec les cache que l'on a actuellement, on devrait pouvoir se débrouiller pour ne jamais avoir a télécharger ces 100ko.

Déjà, sur un site, c'est normalement limité a la première exécution, mais si en plus on le prends depuis les adresse CDN, tous les sites doivent utiliser le même cache non ?

Ne serait il pas plus pratique dailleur de faire en sorte que des navigateurs inclue directement quelques librairies populaires pour ne plus avoir besoin de les importer ? (genre chrome, opéra et firefox pourrait avoir la dernière version de jquery, mootools, prototype, etc... déjà inclue par défault dans l'exécutable.(ou chargé une fois pour toute au premier site exigeant cette librairie)
0  0 
Avatar de vivoli12
Membre régulier https://www.developpez.com
Le 22/11/2011 à 18:36
Sauf que certains modifie le code jQuery sans changer le nom du fichier.
Bon après le navigateur pourrait par exemple comparer le poids du fichier pour savoir s'il le télécharge ou non. Et ça doit être assez rare que des gens bidouille directement le code jQuery.
0  0 
Avatar de gwinyam
Membre chevronné https://www.developpez.com
Le 25/11/2011 à 11:12
Je suis plutôt d'accord avec pmithrandir.

Certes la librairie est "un peu lourde", elle peut vite poser souci aux gens qui sont sur leur mobile sans wifi et avec une mauvaise 3G ou avec un modem 56 Ko, mais sinon, 100ko, faut pas pousser mémé dans les orties.

Si déjà tous les développeurs acceptaient d'utiliser les CDN, on aurait moins de problème de poids.

Je comprends l'envie de vouloir pouvoir se débarrasser des choses inutiles quand vous ne pouvez pas utiliser les CDN (appli interne sans accès à l'intérieur), et encore, le cache marche quand même. Mais quand votre site à accès à l'internet, utilisez les CDN et arrêtez de vous poser la question du poids de vos librairies.
1  1