Avec un report massif des usagers sur des mobiles, la plupart sous un navigateur Webkit powered, on peut tabler sur un bien meilleur support de Javascript et ses APIs. Cela signifie qu’on a moins besoin d’utiliser des libs pour combler les trous, mais aussi la possibilité d’utiliser des frameworks comme AngularJS, MeteorJS, etc.
Est-ce pour autant la fin de notre bien aimé jQuery, qui nous a sorti de l’age sombre, et nous a tenu la main pendant cette dernière décennie ?
Non.
Bien entendu, on utilise moins jQuery. On utilise parfois des choses plus légères. Parfois des choses plus lourdes. Parfois du JS pur.
Et il faut avouer que les projets parallèles à jQuery comme jQuery Mobile et jQueryUI n’ont jamais décollé. Merci Bootstrap et le responsive design.
Néanmoins, il reste des tas de choses pour lesquelles jQuery est utile.
Certes, il y a les versions light qui font “presque la même chose mais avec beaucoup moins de ko”. Mais c’est le “presque” qui finit par vous faire ajouter plein d’autres dépendances, pour finalement vous retrouver avec un truc qui fait “presque” la même taille que la lib que vous vouliez éviter, et qui ne sera probablement pas en cache. De plus, la documentation disponible n’est pas du tout comparable.
Et certes, il y a les outils bazooka, qui font tout, même le café. Mais les solutions comme Angular ne permettent pas une dégradation gracieuse du site, pèchent en référencement, et massacrent l’accessibilité. Les apps sont des bons candidats pour une “one page navigation”, mais pas les sites orientés contenus, quant aux hybrides…
Pensez aussi que même si vous codez pour des browsers modernes (donc pas IE8 qui limite ses sélecteurs à css 2.1), les APIs haut niveau comme querySelector et querySelectorAll sont très loin d’être aussi pratiques et puissantes que le bon vieux $(). Je ne parle même pas de la gestion des événements et d’Ajax qui sont toujours à chier en 2014.
Donc jQuery permet de rajouter cette petite touche de dynamisme à votre site statique, ou de faire un outil moderne sans sacrifier les aveugles et le PR. C’est un compromis entre puissance et simplicité. Et quand vous sortirez du cas standard, contrairement aux versions au bifidus actif allégé, la lib vous permettra de sauter le pas avec ses centaines de features, ou ses milliers de plugins.
Sans compter l’immense base de projets existants utilisant le bouzin, et qu’il va bien falloir maintenir. Bonne chance à ceux qui veulent porter un site avec jQuery vers un autre truc. N’oubliez pas non plus l’inertie technique. Et le temps de formation de la population de dev aux nouvelles technos. Surtout qu’en ce moment, avec l’avalanche de nouveaux trucs à tester/apprendre/valider, il va falloir gérer ses priorités. Ajoutez à ça la baisse drastique du niveau des devs sur le marché du travail :)
Bref, bien que j’apprécie et utilise les nombreuses alternatives à jQuery, il ne va pas disparaitre cette année, et probablement pas l’année prochaine.
Je ne comprends pas/plus l’argument “jQuery pèse trop lourd” (en terme de ko). Un très grand nombre de site l’utilise, ce qu’il fait qu’il est probable que nous ayons déjà la bonne version dans le cache navigateur, non?
Et puis à l’heure du haut débit et de la 4G, qu’est ce que c’est que 30ko?
“la baisse du niveau des devs”…
source ?
@Balthazar : pour ça il faut utiliser un CDN. De plus la taille des pages est la cumulation de plein de choses, quelques ko par ci, quelques ko par là… Sur de gros sites, une seconde de chargement en plus c’est 10000 visiteurs en moins. Sans compter que tu parles d’une partie de la population qui est bien lotie (haut débit, 4G), mais ce n’est pas le cas partout. Comme souvent, il est bon de ne pas généraliser, mais de mesurer, tester, et adapter à son cas.
@desfrenes : l’INDMS : institus national du doigt mouillé de Sam. Mais en tant que formateur, dev, blogger, aide sur les forum et consultant en recrutement, je vois toute la chaine d’évolution des devs. Et bien que le nombre absolu de dev de haut niveau soit en hausse (dans mon échantillon pas représentatif mais bien concret), le % de dev de bon niveau par rapport à la masse de nazes est en chute libre. Ceci est à mettre en corélation avec l’augmentation du besoin de dev de bon niveau et de la demande un peu partout. Du coup, il y a pénurie, et on se retrouve avec des mecs moyens, voir incompétent, qui criblent le secteur. Il y a plein de causes et conséquences à cela, mais ça mérite un article à lui tout seul.
@Balthazar : j’ai vécu 4 ans entre 2008 et 2012 en 56k. Je maudissais les sites “modernes”, à l’époque toujours lourds et très rarement bien pensés pour les petites connexions (j’ai l’impression qu’il y a eu des progrès au niveau de l’accessibilité en général ces dernières années). jQuery faisait partie de mes cauchemars, et je me sentais faire partie d’une minorité frustrée non négligeable…
@Sam : l’article à lui tout seul serait fort intéressant ! A quand l’INDMS reconnu d’utilité publique ?
vivement l’article alors.
Personnellement dans notre projet nous avons suivi de près l’évolution de framework alternatif comme AngularJS ou autres.
Cependant, nous composons nos développements également avec les équipes d’intégration qui n’ont pour la plupart été formés que sur jQuery, et la plupart des profils que nous recevons en entretien ne connaissent les autres framework que de loin.
jQuery possède un monopole, c’est indéniable, et je le vois mal disparaître aussi vite. Et puis il faut admettre qu’il est plus facile à mettre entre toutes les mains qu’AngularJS qui est souvent plus efficace pour les “one-page website” mais nécessite des compétences bien plus élevés en développement.
Quand je pense à mon projet actuel (une refonte en Django d’un progiciel de gestion à destination des mutuelles et assureurs), je me dis que j’aurais du privilégier AngularJS, mais on a privilégié jQuery pour que tout le monde sur le projet et que la future maintenance puisse comprendre plus facilement, quitte à devoir faire des lignes de JS en plus pour des choses basiques en AngularJS (typiquement le binding et le DOM parsing).
A noter qu’il existe jQuery Lite où Zepto ! On peut aussi, dans certains cas, utiliser Sizzle uniquement !
Au-delà de ça, il est toujours possible de charger ses dépendances en fin de traitement. De manière à rendre disponible une version “mineure” mais fonctionnelle dés les premiers bytes chargé pour ensuite ajouter le reste des fonctionnalités dynamiquement. Bien entendu, ça demande une vraie structure de contenu… et tous les projets ne le permettent pas. :-/
jQuery et autres grosses libs prennent pas mal de temps à être _parsé_ par le navigateur (je ne parle pas du temps de téléchargement). Sur mobile, et notamment les mobiles plutôt entrée/moyen de gamme, ça induit un vrai lag lors du chargement de la page. À ne pas négliger…
@JulienW
Le temps de parsing des libs js est négligeable sur desktop (~30k/ms pour l’ordre de grandeur), et sur les mobiles, même si c’est plus lent (1k/ms mais pas bien sûr?), le temps de téléchargement est infiniment plus long de toute façon.
Optimize le download d’abord, le bottleneck n’est pas dans le parsing.
Sinon, je sais que google entre autre écrit du javascript en commentaire dans du html, et quand il en a besoin (ou qu’il a du temps), il lit l’html et parse le code. Mais on parle de google là ;)
Je veux un article sur les rapports de l’INDMS ! :)