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

Le , par Idelways, Expert éminent sénior
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 ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de programaniac programaniac - Membre régulier http://www.developpez.com
le 22/11/2011 à 10:05
ça doit surement être a cause d'un de ces vieux développer qui ne veut pas évoluer et qui maintient jQuery dans la bouse de vache lol
Avatar de dtcSearch dtcSearch - Membre actif http://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.
Avatar de savageman86 savageman86 - Membre actif http://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 ?
Avatar de frfancha frfancha - Membre averti http://www.developpez.com
le 22/11/2011 à 12:16
Citation Envoyé par YannPeniguel  Voir le message
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...

+1000
Avatar de Jay13mhsc Jay13mhsc - Membre du Club http://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 !
Avatar de pmithrandir pmithrandir - Membre expert http://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)
Avatar de vivoli12 vivoli12 - Membre régulier http://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.
Avatar de YannPeniguel YannPeniguel - Membre éprouvé http://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
Avatar de pmithrandir pmithrandir - Membre expert http://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...)
Avatar de gwinyam gwinyam - Membre chevronné http://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.
Avatar de gwinyam gwinyam - Membre chevronné http://www.developpez.com
le 29/11/2011 à 14:21
Voilà mon coup de gueule : jquip & cie, une fausse bonne idée
Offres d'emploi IT
Expert sécurité en audit d'applications (H/F)
Société Générale - Ile de France - Val-de-Marne
Technical leader / moe perle (H/F)
Société Générale - Ile de France - Val de Marne
Analyste SI-métier (poste également ouvert aux stagiaires, alternants et VIE du groupe)-(H/F)
Société Générale - Ile de France - Val-de-Marne

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil