jQuip : naissance d'un jQuery lite
Qui embarquerait 90 % des fonctionnalités du framework pour seulement 13 % de sa taille
Le 2011-11-22 07:45:18, 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 ?
Source : compte GitHub du projet
Et vous ?
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 ?
Source : compte GitHub du projet
Et vous ?
-
savageman86Membre habitué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 ?le 22/11/2011 à 10:39 -
grunkModérateurTrè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.le 22/11/2011 à 9:06 -
YannPeniguelMembre éprouvéLa multiplication de la vitesse d'execution ne sert à rien si le framework fait des couacs.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.
Parce que sinon, dans ce cas, je vous fait un gateau en 10 minutes au lieu de 45 minutes, vous allez vous régaler...le 22/11/2011 à 9:43 -
YannPeniguelMembre éprouvé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/Hashle 23/11/2011 à 10:40 -
pmithrandirExpert éminentEn 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...)le 24/11/2011 à 14:59 -
dtcSearchMembre actifEXCELLENT!!
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.le 22/11/2011 à 10:24 -
Jay13mhscMembre du ClubOUI 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 !le 22/11/2011 à 15:27 -
pmithrandirExpert éminentJe 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)le 22/11/2011 à 16:23 -
vivoli12Membre régulierSauf 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.le 22/11/2011 à 18:36 -
gwinyamMembre chevronné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.le 25/11/2011 à 11:12