La version finale de jQuery 3.0 est désormais disponible au téléchargement pour les développeurs. Contrairement à la mouture 2.0, la nouvelle venue introduit peu de régressions. Plusieurs points importants sont tout de même à prendre en compte.
jQuery a fêté son dixième anniversaire il y a quelques mois. À la base un simple projet visant à simplifier le développement en JavaScript sur certaines parties jugées rébarbatives, cette bibliothèque est désormais utilisée par de très nombreux développeurs.
jQuery 3.0 était en travaux depuis environ 18 mois. La lente maturation tenait notamment compte d’une grande cassure provoquée par la version 2.0, incompatible avec la première branche. La nouvelle mouture est davantage un prolongement de la précédente, et si quelques régressions seront à prendre en compte, la transition devrait beaucoup mieux se passer lors de la migration des projets. Un guide pour jQuery Migrate 3.0 est d’ailleurs disponible.
Adieu Compat, bonjour « slim »
L’un des changements les plus importants est sans doute l’abandon de jQuery Compat. Il s’agissait d’une version spécifique de la bibliothèque JavaScript, conçue pour préserver la compatibilité avec certaines fonctionnalités spécifiques des anciennes versions d’Internet Explorer jusqu’à la 8. Or, avec le changement de politique de support du navigateur par Microsoft, la plus ancienne version supportée sur un Windows (Vista) est Internet Explorer 9. Pour l’équipe de jQuery, Compat n’avait plus qu’à mourir.
jQuery 3.0 introduit également une version « slim ». La mouture principale contiendra toujours l’ensemble des modules AJAX et dédiés aux effets, mais la slim en sera en quelque sorte dégraissée. Bien que l’équipe estime que la taille de jQuery soit rarement un problème de performance, ils précisent néanmoins que le paquet slim pèse 23,6 Ko, contre 30 Ko pour l’édition classique.
Un prolongement de la version 2.0
Parmi les autres changements à signaler, on notera que les objets jQuery.Deferred sont maintenant compatibles Promises/A+ et ES2015 Promises, la méthode catch leur a été adjointe, l’affichage de messages d’erreurs pour certaines opérations qui n’en renvoyaient pas, le retrait des alias .load, .unload, et .error, l’utilisation par défaut de requestAnimationFrame, la possibilité d’ajouter des arguments dans la méthode unwrap ; ainsi que des améliorations « massives » de performances sur certains sélecteurs personnalisés.
Les intéressés pourront lire les notes complètes de version depuis cette page, qui donne également les liens de téléchargement.
Commentaires (29)
#1
Dommage, mon projet demande encore la compatibilité IE7 
" />
#2
#3
@gokudomatic
Au hasard… Un grand compte avec une entête serveur pourrie ? directement dans le httpd.conf, genre :
<IfModule headers_module>
Header set X-UA-Compatible: IE=EmulateIE7
</IfModule>
#4
J’ai voulu tester vite fait il m’a éjecté mes autocomplete dans le coin supérieur gauche du navigateur donc je verrai ça plus tard.
" />
#5
J’ai eu ce cas chez un client à cause d’un intranet qui datait d’il y a “quelques” années et pas compatibles avec des navigateurs plus récent (et pas les moyens d’en faire refaire un).
Du coup obligé de faire quelques dev sur la vers 7 de IE aussi… Et c’est la misère. ;)
#6
déguises-toi en chauve-souris, prends une batte et va visiter à une heure tardive le sysadmin qui a pondu ça.
#7
Si tu savais comme j’aimerais… Mais ils ont un gros service d’ordre, dans ces entreprises du CAC40. Je vais avoir besoin d’aide. ;)
#8
En entreprise, il peut y avoir encore quelques postes sous XP malgré la fin du support à cause d’outils spécifiques qui ont pas été migrés pour une raison XYZ. Et sur le web, peut-être que madame Michu est encore sur Windows XP pour une raison ou une autre.
Edit : Ouais, les exemples de config serveur donnés juste au-dessus piquent très fort t_t
#9
Ou un paramétrage qui force le mode compatibilité pour les intranets par défaut… Tout en ayant pour pré-requis dans la réglementation interne concernant le dev’ Web de respecter le W3C…
" />
#10
Bah ils ont encore énormément de Vista, mais ça migre, petit à petit.
Mais en soit, c’est juste un résidu contractuel, normalement ils n’ont plus le besoin en dessous de IE8.
#11
Sur les site ecommerce, ce sont les stats visiteurs qui sont importants. Tant que le CA généré par de anciens navigateurs est satisfaisant, il doit être supporté.
#12
La question à se poser c’est : est-ce que cette nouvelle version de Jquery permet de faire encore moins de bugs ?
http://www.programmation-facile.com/formation-jquery-dojo/
Ça ferait un bon LIDD
#13
#14
#15
Avec Angular 2 on a abandonné Jquery, et je ne m’en porte pas plus mal.
#16
#17
#18
Tout simplement car ce n’est pas parce qu’il n’y a plus de support, que dans la pratique il n’est plus utilisé.
Ex: poir de la vente en ligne avec des chinois, on nous demandait de supporter ie6.
Beaucoup de xp cracké encore la bas avec des ie6.
#19
Par contre, ils ont fait n’importe quoi avec les RC Angular. D’ailleurs j’ai bien peur qu’Angular 2 soit mort au profit du 3. La RC0 est digne d’une alpha.
#20
#21
#22
#23
Ils sont en train de réécrire tout le formControl, ça marche pas très bien de toute façon au niveau de la validation. Les problèmes de webpack sont légions, les provider déconne dans certains cas, les tests unitaires sont presque impossibles à faire (pas de doc, ça change trop souvent), et j’en passe.
#24
#25
La RC2 était prévu pour lundi de semaine dernière… J’y crois plus trop, surtout à la vue du nombre de commits.
#26
#27
Merci pour ces precisions sur Angular 2. Ca donne pas franchement envie…
#28
Via le chat gitter. Je le suis pas mal, je bosse sur un projet angular 2 depuis 2 mois.
Au début, j’avais voulu l’utiliser pour un projet perso, mais voyant comment on galère au boulot, j’ai abandonné l’idée tant qu’il n’y a pas une version stable.