Comme dit hier dans ma chronique, certaines choses commencent à me fatiguer et il est temps de remettre les pendules à l'heure. Ou à minima que je pousse mon coup de gueule, ça fait toujours du bien.
jquip est une fausse bonne idée !
Bon en fait, ce n'est pas que jquip mais toute tentative de construire une version personnalisée de jQuery ou de n'importe quel autre framework "populaire".
Pourquoi ?
Parce que cela signifie plusieurs choses :
- vous fragmentez un tout qui a été pensé et conçu comme tel ;
- vous rendez la maintenance de votre application/site quasi impossible du fait du temps passé à porter vos modifications sur chaque nouvelle version ;
- vous devez reprendre tous les tests unitaires et y porter les modifs nécessaires pour éliminer les tests qui concernent vos suppressions
(ah ah rien qu'à cette idée j'en pleure de rire, à ce point, ce n'est plus du courage); - vous allez certainement provoquer un bug ou une instabilité dans un plugin qui n'est pas de votre oeuvre, en plus de ceux pouvant déjà être potentiellement présents. Votre seul test est visuel, avec un peu de chance, vous avez les unitaires mais c'est rare, très rare ;
- vous avez effectivement réduit la taille de votre bibliothèque, bravo, vous avez gagné 10Ko (en admettant que vous ayez su retirer 30% de la librairie en version de production). Bravo, 10Ko, même un téléphone 3G (et pas 3G+) ne fera pas la différence. Sur un modem 56Ko, vous avez économisé quelques précieuses secondes à vos visiteurs ;
- vous avez perdu une semaine (si vous avez travaillé rapidement et salement) pour faire gagner quelques instants à
1%40% de vos visiteurs (correction suite à un commentaire).
La solution
Oui, il est vrai, jQuery fait son poids mine de rien : 31Ko pour la 1.7.1 en version minifiée et gzippée. Pour certains terminaux et certaines connexions, ça représente une belle charge et c'est bien d'en avoir conscience. Ceci dit, vous allez devoir réfléchir plus loin que votre personne application.
Utilisez les CDN !
C'est fou, on ne le répétera jamais assez. Le principe est simple : tous les navigateurs disposent d'un cache. Un passage sur un site au cours de la session du navigateur, voire plus pour ceux qui ne nettoient rien, et pof, la librairie est en cache et n'en bouge plus. Ce qui veut dire :
- vous ne cherchez pas à découper un monolithe ;
- la mise à jour vers une nouvelle version se fait par un simple changement d'appel de fichier (20 secondes) ;
- vous n'avez pas besoin de dérouler les tests unitaires, l'équipe l'a déjà fait pour vous ;
- vous n'avez à traiter que les potentiels problèmes déjà existants des plugins que vous utilisez, pas ceux que vous avez ajoutés ;
- vous avez toujours une librairie de 36Ko, mais qui pèsera 0 (même pas les en-têtes) si la personne a visité un autre site utilisant jQuery avant le vôtre, ce qui est de plus en plus probable ;
- vous avez pu vous occuper de votre application/site, vous avez économisés une semaine de votre temps et avez pu prendre votre temps en pause déjeuner tout en bouclant le projet en temps et en heure.
J'ai employé un ton quelque peu ironique ici mais j'espère par là vous avoir fait comprendre le ridicule de ce débat : "version composée personnelle VS. version originale complète".
Attention, à ne pas confondre avec la question actuellement traitée par l'équipe de développement qui concerne l'allègement par l'élimination des choses qui n'ont rien à faire dans le coeur. Sauf que eux connaissent vraiment la librairie sur le bout des doigts et c'est vraiment leur projet professionnel.
Et parce qu'il serait dommage d'arrêter là, je vous recommande le CDN de jQuery :
http://code.jquery.com/jquery-1.7.1.min.js
Vous pouvez bien évidement utiliser les CDN de Google et Microsoft mais ceux-ci sont mis à jour dans un délai plus long que l'officiel et s'éparpiller serait ridicule en ôtant tout intérêt aux CDN. Dernière précision, si vous voulez éviter des mauvaises surprises à l'usage d'un CDN, précisez toujours le numéro de la version utilisée, sinon, vous risquez un résultat hasardeux.