jQuery, le bulletin hebdomadaire

Chroniques jQuery, épisode 43

Flattr this!

Je n'ai pas pu faire de billet hebdomadaire la semaine dernière à cause de mon état physique (il y a un mec en blouse blanche qui m'a piqué mes amygdales). Même si je ne peux pas encore reprendre le travail, j'ai quand même pu écrire celui-ci. Du coup, je résume les deux dernières semaines. Et je peux vous dire que j'en ai eu de la lecture.

Côté core de jQuery, on a eu la mise à disposition de la version mineure de jQuery 1.6.4. Cette version corrige deux bugs apparus avec la version 1.6.3.

Dans les différentes suggestions faites par les utilisateurs, il y a eu une discussion intéressante à propos de la mise à disposition d'une version allégée du core. L'équipe de développement s'y oppose pour la simple et bonne raison que celui-ci est déjà allégé au maximum et que le "superflu" est déjà déporté vers des plugins. Cependant, la discussion a continué, suggérant que la méthode click(), par exemple, est inutile quand on dispose de la méthode bind(). Effectivement, ces assistants de gestion d'évènements pourraient être facultatifs pour un utilisateur expérimenté, cependant leur retrait n’entraînerait qu'un allègement de 256 octets sur un fichier de 32 Ko. Idem pour certains raccourcis dans Ajax, qui feraient perdre environ 207 octets. En somme : inefficace.

La seule façon d'alléger substantiellement jQuery serait donc de retirer, par exemple, tout le module Ajax, soit environ 15 Ko. Mais cela interdirait entre autres et évidemment toute interaction asynchrone avec le serveur. Ainsi que l'objet Deferred, arrivé avec jQuery 1.5. Et nombre de plugins ne fonctionnerait plus. Peu envisageable.

La discussion s'est donc close naturellement sur le fait que si on veut limiter la charge "jQuery", il faut utiliser les CDN. Il est toujours bon de le rappeler.

Côté jQuery UI, la milestone 6 de la version 1.9 est disponible avec notamment une concentration sur une nouvelle version du module Spinner.

Concernant cette nouvelle version, on a :

  • essentiellement des corrections de bugs ;
  • une redéfinition de l'API pour le module Spinner, désolé pour le coup je n'ai pas de détails ;
  • une amélioration du widget Menu pour la gestion des sous-menus ;
  • une amélioration du module Position.

Petite info aux utilisateurs de Spip, le plugin permettant l'utilisation de jQuery UI est à jour. Il permet d'utiliser la toute dernière version, soit la 1.8.16.

Le ThemeRoller de jQuery UI, c'est pratique mais c'est pas très dynamique. Une fois qu'on a chargé un thème, il faut aller éditer ce thème à la main. Un utilisateur a donc proposé un système pour générer des thèmes pour jQuery UI à partir de templates. Il faudrait avoir le temps de l'utiliser pour comprendre son fonctionnement je pense, mais l'idée n'est pas bête. Je n'ai pas d'exemple en tête mais je suis sûr que nombreux sont les designers qui aimeraient pouvoir générer un thème à la volée. D'ailleurs suivez bien ce blog, je devrais vous reparler ThemeRoller dans les temps à venir, mais ça concernera jQuery Mobile 😉

En parlant de nos chers smartphones/tablettes, Meego 1.2 a obtenu le niveau A de support. C'est à dire un support maximal du framework mobile. Ils ont d'ailleurs pu tester cette compatibilité sur un Nokia N950 généreusement offert par Nokia.

Au passage, avec l'arrivée prochaine de la version 1.0, l'équipe a fait le ménage. Les éléments jusqu'alors considérés comme deprecated ont été dégagés. Quand vous récupérerez la version stable, pensez donc bien à tout tester avant de mettre en production, mais c'est un conseil que je ne devrais pas avoir à vous donner 😉

Je vous propose cette semaine une galerie d'images quelque peu originale. Image Zoom Tour vous propose de vous baser sur une première photo, d'y apposer des cadres sur des points d'intérêt et de vous en servir pour ensuite accéder à d'autres photos correspondantes à ces points. La navigation ne se fait donc plus avec des flèches classiques mais via des points d'intérêt de l'image courante. L'idée est bonne et les exemples utilisés sont très parlants.

Pour finir, je vous suggère aussi un développement intéressant réalisé par un utilisateur qui propose ni plus ni moins qu'un petit plugin pour reproduire l'interface "Metro" de Windows Phone 7 avec jQuery.

A la semaine prochaine et en pleine forme (j'espère) pour la prochaine chronique 😉

Flattr this!

A propos de Mathieu

Ingénieur développeur web dans la vente par correspondance B2B, adepte de nouvelles technologies et d'innovation. Vous pouvez aussi me retrouver sur Twitter @mathrobin
Cette entrée a été publiée dans jQuery, avec comme mot(s)-clef(s) , , , , , , , , , , , , , , , , , . Vous pouvez la mettre en favoris avec ce permalien.
  • http://www.pure-tentation.fr/ Syndrael

    Ouh là..que d’info..
    Pour la peine, pas le temps de tout lire mais juste qqs réactions.
    Pour l’Ajax dans JQuery, pourquoi ne pas faire comme JQueryUI et choisir ses propres modules ? Un noyau et plein de modules autour. Ca permettrait même d’intégrer des plugins que nous sommes obligés de définir manuellement actuellement.
    Concernant le theme Roller, quel lourdeur.. Perso je croise un thème avec Less Css et hop.. j’ai du dynamique. Mais au prix d’arrachage de cheveux pour la réflexion..
    A pluus pour d’autres réactions..
    S.

    • http://www.mathieurobin.com/ Mathieu

      Le souci est que jQuery Core et jQuery UI ne répondent pas du tout au même besoin. D’un côté tu as un moteur applicatif dont le coeur de métier est double de façon historique :
      – d’un côté la compatibilité multi-navigateurs
      – de l’autre la gestion simplifiée d’Ajax
      A mon avis, l’équipe n’acceptera jamais de dissocier ces deux éléments et je ne suis même pas sûr que ce soit techniquement possible. A mon avis chacun repose trop l’un sur l’autre. Ajax a besoin de la compatibilité, la compatibilité a besoin d’Ajax parce que c’est lui qui fournit Deferred. Et je les comprends.

      jQuery quand à lui est un moteur graphique, fournissant des éléments d’interface dont on n’a pas forcément besoin et donc dont on peut facilement se séparer sans que cela ait un impact, mais il reste toujours un noyau dur systématique, commun et je suppose « éternel ».

      Peut-être que certains éléments de jQuery Core seront un jour dissociés vers des plugins. Mais ne pas oublier une chose : chaque plugin est un nouveau fichier à charger. Et finalement, 2 ou 3 fichiers de x Ko chacun vaut il mieux qu’un seul fichier de 35 Ko ? Avec les en-têtes et tout le toutim, je ne suis pas convaincu de l’approche.
      Et combien d’entreprises, combien de sites font de la fusion de leurs fichiers de scripts en prod ? A mon avis, pas beaucoup, sinon, nous n’aurions pas des scripts de DSL comme Head.js ou Require.JS

      J’attends tes autres réactions avec impatience 😉

  • XF

    prompt rétablissement

    • http://www.mathieurobin.com/ Mathieu

      Merci :)

Articles liés