Si il y a une chose à retenir de cette semaine, c'est ça :
La béta 1 de jQuery 1.5 est disponible
Ah et il y a eu ça aussi :
Joyeux anniversaire jQuery!!!
Une fois cet effet d'annonce passé, plus concrètement, qu'est-ce qu'il s'est passé? Alors jQuery est né le 14 janvier 2006, il fêtait donc ce 14 janvier ces 5 ans. Au passage, les gars en ont profité pour mettre en release la béta 1 de jQuery 1.5. Donc voilà ce qui est au menu de cette version :
- le module Ajax a été entièrement réécrit par Julian Aubourg : http://bugs.jquery.com/ticket/7195, j'en avais déjà parlé en décembre,
- le dédoublement de code dans $.get et $.post, également évoqué en décembre, même article,
- le SubClassing est maintenant supporté : http://bugs.jquery.com/ticket/7901
- quelques fixs de bugs divers et variés concernant soit des régressions apportées par les versions 1.4.x, soit des bugs constatés avec IE,
- un meilleur respect des normes du W3C,
- des mises à jour de la documentation,
- le parser HTML a été revu pour le transformer en parser XML cross-browser, pratique, le ticket est ici : http://bugs.jquery.com/ticket/6693
Si vous voulez jouer avec, ça se passe ici : http://code.jquery.com/jquery-1.5b1.js
Vous pouvez retrouver l'ensemble détaillé des nouveautés sur le blog officiel, ici : http://blog.jquery.com/2011/01/14/jquery-1-5-beta-1-released/
Une discussion a démarré autour du formatage des dates avec le composant DatePicker de jQuery.UI. Actuellement, celui s'adapte selon le pays défini via votre navigateur, evancarroll propose de se conformer au standard défini par le W3C et la [RFC 3339]. Je rejoins scott.gonzalez sur son avis, l'expérience utilisateur est bien meilleure quand le format de date s'adapte au pays du visiteur. Le débat se tient ici : http://forum.jquery.com/topic/html5-and-jquery-ui-datepicker-date-formatting-defaults#14737000001898703
Il y a eu changement de "minifieur", jusqu'à maintenant, l'équipe utilisait Google Closure Compiler, c'est UglifyJS qui prend la relève. Le ticket est ici.
Et pour finir, des soucis de performances ont été remonté, les discussions sont lancées, dans idées suggérées (parfois), des solutions sont trouvées (ou pas), la liste :
- sur les listes de sélection dans jQuery Mobile : http://forum.jquery.com/topic/very-poor-select-input-performance#14737000001903401
- le manque de réactivité des boutons sur jQuery Mobile : http://forum.jquery.com/topic/usability-touch-feedback-too-slow
- dans l'autocomplete de jQuery UI : http://forum.jquery.com/topic/autocomplete-search-optimize#14737000001898785
Une semaine plutôt riche et intéressante. J'ai eu bien du mal à clôturer cet article, quelques petits malins se sont visiblement amusés à beaucoup discuter sur le forum ce mardi soir (j'écris la veille de la publication, je n'écris pas au boulot, les articles sont planifiés, merci WordPress), m'empêchant de terminer tôt cet article. Mais bon, c'est pour le bien de la communauté 
A la semaine prochaine!
Pour le « minifieur », c’est fou comment le gain de qqs octets peuvent faire basculer des choix de technologies..
Petites rivières qui font de grands fleuves à l’époque où nos stockages sont au tera-octets et les débits grandissant.. Et pourtant via les CDN, la recherche du gain de bande passante est omniprésente..
C’est assez intéressant comme débat.
S.
J’avoue être sceptique concernant les minifieurs. Ok c’est intéressant d’alléger le contenu de ces fichiers, y compris quand ils viennent d’un CDN (tant qu’à faire, autant que la première fois soit rapide). Cependant, réduire pour réduire, il y a t’il un réel intérêt derrière pour l’interpréteur? Peux-t’on en plus d’optimiser le poids du fichier optimiser son code pour qu’il soit plus rapide à interpréter? Je serai plus tenté de me pencher sur cette question.