Discussion :

[Michael Guilloux]

La version 5.0 du framework Bootstrap va supprimer jQuery, sa plus grande dépendance côté client
pour du pur JavaScript

Bootstrap n'est plus à présenter aux développeurs Web, car c'est sans doute le framework HTML, CSS et JavaScript le plus populaire pour développer des projets mobiles first et responsives sur le Web. Il offre des outils utiles à la création du design de sites et d'applications Web. C'est un ensemble qui contient des codes HTML et CSS, des formulaires, boutons, outils de navigation et autres éléments interactifs, ainsi que des extensions JavaScript en option. La dernière version majeure, Bootstrap 4.0 a été publiée en janvier 2018, après plus de trois 3 ans de développement et une réécriture majeure de l'ensemble du projet. Elle a donc introduit des changements incompatibles que les développeurs devraient prendre en compte dans leurs projets.

Plus d'un an après la version 4.0, des versions mineures ont été livrées. La dernière, Bootstrap 4.3, date du 11 février. Bootstrap v4.3 vient avec des améliorations aux utilitaires du framework, des corrections de bogues, mais surtout des tailles de polices responsives. Un nouveau projet Bootstrap permet en effet d’automatiser le calcul d’une taille de police appropriée en fonction des dimensions du périphérique du visiteur ou de la fenêtre du navigateur.

Mais juste après la livraison de la v4.3, l'équipe Bootstrap a décidé d'aborder quelques changements clés à venir dans la version v5. À la Une, elle annonce l'abandon de jQuery pour du pur JavaScript. « Le chat est sorti du sac - nous abandonnons notre plus grande dépendance côté client pour du JavaScript pur. Nous y travaillons depuis longtemps et un pull request est en cours et presque terminé », a affirmé l'équipe Bootstrap.

Il s'agit d'un énorme pull request avec des centaines de commentaires étalés sur un an et demi. Selon les commentaires, jQuery a été remplacé par du pur JavaScript (également désigné par le nom Vanilla JS) qui appelle directement les API du navigateur. S'il est souvent désigné comme étant un framework, Vanilla JS ne l'est pas vraiment, c'est du JavaScript sans bibliothèque.

Le concept Vanilla JS a été popularisé fin 2012, avec pour objectif de contrecarrer l’omniprésence des bibliothèques JS comme jQuery. Si vous avez déjà effectué une recherche sur un moteur de recherche suite à une question ou à un problème en codant en JavaScript, vous vous êtes peut-être rendu compte que jQuery et d’autres étaient omniprésents et toujours présentés comme la solution, même sur des questions génériques. C'est pour lutter contre cela que le concept Vanilla JS a été mis en avant. Il vante les mérites de JavaScript. Plutôt que d’utiliser une bibliothèque en surcouche, on peut en effet trouver une solution équivalente qui utilise les fonctions du core JavaScript.

L'argument général pour justifier la suppression de jQuery dans Bootstrap v5 est que maintenant que plus de 95 % des fonctionnalités de jQuery sont désormais natives dans les navigateurs (les 5 % restants étant sans doute des bizarreries excessivement rétrocompatibles qui méritent d'être ignorées), donc ajouter une dépendance JS serait "stupide" ou un gaspillage de bande passante.

Dans la communauté des développeurs, les avis divergent quant à ce changement. Pour certains, c'est une bonne nouvelle. Cela pourra rendre Bootstrap plus attractif et compétitif en tant que framework. Ils reconnaissent que jQuery était l’un des frameworks (bibliothèques) les plus importants de l’histoire JavaScript et il a permis de créer de véritables applications Web. Cependant, depuis lors, les différences entre les navigateurs se sont considérablement réduites et nous avons appris à créer des applications maintenables et évolutives de manière plus déclarative, grâce à des frameworks comme React, Angular et autres. Du coup, jQuery ne serait plus d'une grande utilité. Ils avancent également que c'est généralement bien de pouvoir éliminer une dépendance pour des fonctionnalités natives.

Les autres, par contre, ne comprennent pas pourquoi l'équipe Bootstrap s'est donné tant de mal pour supprimer jQuery. L'API est incompatible, et si vous parcourez les commentaires du pull request, vous allez constater que de nombreux problèmes spécifiques aux navigateurs sont en cours de résolution. Le support d'Internet Explorer a quant à lui été abandonné. Autrement dit, la suppression de jQuery "a tout cassé". Ils estiment aussi que jQuery fait beaucoup de choses utiles et reste un projet intéressant. Il ne devrait pas être utilisé pour tout, mais passer du temps à le supprimer simplement parce que ce n’est plus le framework à la mode semble être une perte de temps.

Enfin, si Bootstrap va supprimer jQuery en tant que dépendance, ses développeurs prévoient d'offrir aux utilisateurs qui en besoin un moyen de l'utiliser.

Sources : Annonce Bootstrap 4.3, Pull request Github (Bootstrap v5 sans jQuery)

Et vous ?

Utilisez-vous Bootstrap ? Si oui, quelle version ? Sinon, pourquoi ? Quelle alternative utilisez-vous ?
Que pensez-vous de la suppression de jQuery dans Bootstrap ? Cela va-t-il vous affecter ? De quelle manière ?
Que pensez-vous de coder en JavaScript pur (également appelé Vanilla JS) au lieu d'utiliser des bibliothèques comme jQuery ? Quels sont les avantages et inconvénients dans chaque cas ?

Voir aussi :

Bootstrap annonce la disponibilité de la version 3.4.0 du framework qui apporte des correctifs de sécurité et des mises à jour essentielles
La version 4.1.2 de Bootstrap est maintenant disponible, et pourrait mettre fin aux problèmes rencontrés avec la version 4.1.1
Bootstrap 4.1 est disponible : des corrections de bogues, de nouvelles classes utilitaires et une mise à jour de la documentation
Bootstrap 4.0 est officiellement disponible : un aperçu des changements notables dans la collection d'outils pour la création de sites Web

[Invité]

L'argument général pour justifier la suppression de jQuery dans Bootstrap v5 est que maintenant que plus de 95 % des fonctionnalités de jQuery sont désormais natives dans les navigateurs (les 5 % restants étant sans doute des bizarreries excessivement rétrocompatibles qui méritent d'être ignorées), donc ajouter une dépendance JS serait "stupide" ou un gaspillage de bande passante.

Tu passes 1 ans et demi de développement pour supprimer une librairie qui fait 80ko alors que dans la majeur partie du temps tu vas de toute façon l'intégrer pour pouvoir utiliser d'autre plugin, décidément les décideurs me font rêver et leur arguments aussi !

[koyosama]

Mouais j'ai sorti la meme chose quand j'ai vu que ma version d'un plugin n'est pas retro-compatible avec la derniere version de jQuery. Alors que le vanilla JS est retro-compatible avec tous les scripts JS (pour les anciens navigateurs c'est une autre histoire). Et puis on peut encore telecharger la version 4. J'ai plus envie d'avoir 20 scripts qui s'ecrasent les unes les autres pour rien, un de moins c'est deja cela de pris.

Je trouve que c'est une bonne nouvelle , enfin.

[frfancha]

Précision importante, jQuery n'est nécessaire que pour certains composants de Bootstrap.
On peut parfaitement utiliser Bootstrap sans ces composants et du coup sans jQuery.
Notre application AngularJS (gros SPA avec plus de 100 routes) utilise Bootstrap (3) mais pas jQuery.
Par exemple à la place du typeahead de bootstrap (qui nécessite jQuery) on utilise le typeahead d'angular-ui qui est plus facilement intégré avec AngularJS (forcément) mais hérite de tous les styles de bootstrap donc est tout aussi bien intégré visuellement que le typeahead Bootstrap.

[eomer212]

on élimine une dépendance..comme si ca leur coutait du pognon.
un bel exemple de modernisme effrené. une bonne raison de ne pas aller vers cette nouvelle mouture avec son lot de bugs insurmontables autrement qu'en jquery..
comme si on décidait d'enlever le carburateur parceque ca ferait pas partie du moteur..hallucinant de connerie. ils vivent dans un rêve virtuel ou tout le monde a le dernier windows 10 et le dernier smartphone. ho, reveil !!!

[NBoulfroy]

Étant un développeur qui n'aime pas l'omniprésence de jQuery car peu de gens savent vraiment coder en JavaScript et pire avec cette librairie en plus de mâcher de façon parfois perturbante le boulot (chaîner les instructions je veux bien mais il y a des limites).

J'avoue préféré (je pense que vous l'avez compris) JavaScript Vanilla à jQuery de manière globale. Au moins, j'ai la main mise sur mon code de A à Z et je ne peux m'en prendre qu'à moi même si une erreur se produit et j'ai personnellement une certaine aisance dans la maîtrise du langage.

La question de l’interopérabilité entre les navigateurs en revanche est un débat assez difficile : doit-on empêcher les anciens navigateurs de fonctionner sur nos applications web ? Je fais parti de ceux qui estiment que oui, nous ne devons pas laisser des applications en mode "dégradé" tourner sous prétexte que la personne en face refuse de mettre à jour son navigateur (et à ce que je sache, cela n'est pas compliqué). Le client est peut être roi mais on doit garantir que l'application fonctionne sans limiter celle-ci (autant mettre une page indiquant que l'application n'est pas compatible avec le navigateur en question et inviter à télécharger la dernière version de Google Chrome / Firefox / Opera / etc. ...)

[Kikuts]

Merci !!!! Je vais peut être réutiliser ce framework

Je suis allergique à jQuery : la moitié de ceux que je connais qui utilisent jQuery ne savent même pas comment écrire une manipulation de dom basique...
Vanilla est super et suffit souvent pour la majorité des sites.

De plus, en utilisant plusieurs bibliothèques on peut vite se retrouver avec une page qui embarque 5 versions différentes de jQuery... Un non sens total.
Le pire étant que jQuery est souvent utilisé pour simplifier l'écriture d'un simple sélecteur du genre document.getElementById...
Si on trouve l'écriture trop longue, il existe une magnifique chose qui se nomme "fonction". Avec 3, 4 on peut déjà couvrir énormément de cas et simplifier le code.
Je ne comprends vraiment pas pourquoi ajouter une dépendance et alourdir une page pour si peu.

Après, le web n'est pas mon activité principale donc j'imagine sans problème que je n'ai pas connaissance de tous les cas de figure où son utilisation est justifiée voir incontournable.

Perso, à chaque fois que je cherche des exemples sur codepen ou autre, si je vois du jQuery, je ferme l'onglet directement sans aller plus loin.

[NBoulfroy]

Enfin quelqu'un comme moi !

Après, le problème étant que paradoxalement, les gens ne savent plus maintenir du code *JavaScript* Vanilla (j'ai appris ça durant ma licence professionnelle lors de la soutenance de mon projet avec un prof qui était aussi un professionnel encore en activité). Cette modification va probablement avoir beaucoup de répercussion sur le marché dans le développement *web* et peut être influencer l'utilisation de Bootstrap (un peu ou beaucoup, l'avenir nous le dira).

[Charvalos]

Après, le web n'est pas mon activité principale donc j'imagine sans problème que je n'ai pas connaissance de tous les cas de figure où son utilisation est justifiée voir incontournable.

Perso, j'ai toujours trouvé la syntaxe JQuery plus lisible que celle du JS de base (pour autant qu'on ne commence pas chaîner les choses) et c'est surtout pour ça que je l'utilise.

Typiquement, je préfère

Code JS :

Sélectionner tout - Visualiser dans une fenêtre à part

$('#myDiv').remove();

que

Code JS :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
var elem = document.getElementById("myDiv");
elem.parentNode.removeChild(elem);

Ou un autre exemple qui me vient en tête, c'est la création de requête AJAX que je trouve nettement plus lisible et moins verbeux avec JQuery qu'en JS pur et dure.

[Arno500]

Pour l'anecdote, la méthode remove() existe maintenant sur les éléments
Il suffit de faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

document.querySelector("un_selecteur_css").remove()

Pour la deuxième anecdote du jour, depuis 8 ans au moins il y a la méthode "querySelector()" qui marche exactement comme les sélecteurs jQuery.
Voilà, voilà, jQuery n'est nécessaire que pour Internet Explorer < 10 en gros. Dans le cas précis avec IE, cela reste pertinent. Toutefois, cela doit rester un cas spécial, et ne pas alourdir la page de tout le monde, ou surcharger des trucs en global juste par simplicité. Je vous laisse utiliser jQuery avec Vue par exemple (À NE PAS FAIRE).

[earhater]

Ou un autre exemple qui me vient en tête, c'est la création de requête AJAX que je trouve nettement plus lisible et moins verbeux avec JQuery qu'en JS pur et dure.

C'était vrai pour les API XMLHttpRequest mais pour ce qui est de l'API fetch ça reste presque pareil que Jquery pour le coup

[Kikuts]

Enfin quelqu'un comme moi !

Après, le problème étant que paradoxalement, les gens ne savent plus maintenir du code *JavaScript* Vanilla (j'ai appris ça durant ma licence professionnelle lors de la soutenance de mon projet avec un prof qui était aussi un professionnel encore en activité). Cette modification va probablement avoir beaucoup de répercussion sur le marché dans le développement *web* et peut être influencer l'utilisation de Bootstrap (un peu ou beaucoup, l'avenir nous le dira).

Oui je voulais te citer mais j'oublie toujours la syntaxe exacte et trouver la section d'aide sur developpez.com révèle toujours du miracle...

Perso, j'ai toujours trouvé la syntaxe JQuery plus lisible que celle du JS de base (pour autant qu'on ne commence pas chaîner les choses) et c'est surtout pour ça que je l'utilise.

Si c'est uniquement pour ça, des micro bibliothèque existe. Tu fais donc partie des personnes qui utilisent jQuery pour rien
Imagine une fonction comme suit (c'est un exemple pas optimisé ni rien mais pour donner une idée et en aucun cas la bonne implémentation)

Code JavaScript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
$ = function (selector) {
  if (selector[0] == "#")
    return document.getElementById(selector);
  /* add code to handle classname and tagname */
}

et voilà une fonction super bidon. C'est quand même pas bien compliqué

[Lcf.vs]

Tu passes 1 ans et demi de développement pour supprimer une librairie qui fait 80ko alors que dans la majeur partie du temps tu vas de toute façon l'intégrer pour pouvoir utiliser d'autre plugin, décidément les décideurs me font rêver et leur arguments aussi !

En même temps, si tu fais encore du jQuery en 2019, c'est qu'il est peut-être temps de s'orienter vers des solutions moins gourmandes, plus performantes, plus modernes, ...

Pour moi, jQuery n'a jamais été nécessaire, tout au plus un mauvais raccourci pour ceux qui ne veulent apprendre les bases.

[Doksuri]

« Le chat est sorti du sac - nous abandonnons notre plus grande dépendance côté client pour du JavaScript pur. »

essayez d'interpreter les traductions
=> vendre la meche

[Lcf.vs]

Code JavaScript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
/* s for select or anything you want*/
function s(selector) {
  if (selector[0] == "#")
    return document.getElementById(selector);
  /* add code to handle classname and tagname */
}

Attention, un peu trop simpliste tout de même... quid des sélecteurs multiples ou complexes qui commenceraient par # ?

[NBoulfroy]

C'était vrai pour les API XMLHttpRequest mais pour ce qui est de l'API fetch ça reste presque pareil que Jquery pour le coup

Je ne vois pas de quoi tu parles, l'API pour le XMLHttpRequest de base marche très bien. Ah si, il faut pondre une méthode qui retourne le bon objet selon le navigateur m'enfin, il faut pas non plus abuser pour le coup.

Oui je voulais te citer mais j'oublie toujours la syntaxe exacte et trouver la section d'aide sur developpez.com révèle toujours du miracle...

Si c'est uniquement pour ça, des micro bibliothèque existe. Tu fais donc partie des personnes qui utilisent jQuery pour rien
Imagine une fonction comme suit (c'est un exemple pas optimisé ni rien mais pour donner une idée)

Code JavaScript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
/* s for select or anything you want*/
function s(selector) {
  if (selector[0] == "#")
    return document.getElementById(selector);
  /* add code to handle classname and tagname */
}

et voilà une fonction super bidon qui remplacera $('#myDiv') par s('#myDiv'). C'est quand même pas bien compliqué

Merci de m'avoir cité

C'est assez triste comme constat ...

En même temps, si tu fais encore du jQuery en 2019, c'est qu'il est peut-être temps de s'orienter vers des solutions moins gourmandes, plus performantes, plus modernes, ...

Pour moi, jQuery n'a jamais été nécessaire, tout au plus un mauvais raccourci pour ceux qui ne veulent apprendre les bases.

Je suis assez d'accord, personnellement, je dois absolument avoir jQuery pour Bootstrap (ou Materialize) mais en dehors de cela, je fais tout en JavaScript Vanilla (sauf la fermeture de modal, c'est l'un de mes grands regrets).

Une alternative qui peut être intéressante si on veut combler les lacunes en terme d'écriture du JavaScript, c'est de passer sur TypeScript (le code compiler étant forcément du code JavaScript compatible).

[Kikuts]

Attention, un peu trop simpliste tout de même... quid des sélecteurs multiples ou complexes qui commenceraient par # ?

J'ai déjà mis à jour le code tu as répondu trop rapidement mdr
Je n'allais pas t'écrire en vrac en 20 sec un truc sérieux sinon ça remetterait vraiment vraiment en cause l'utilisation de jQuery
De plus je ne fais que très peu de Javascript. A la rigueur, du Dart <3 mais du Js ou Ts ? Non merci je laisse aux autres
Je suis plus C# et Xaml

[Lcf.vs]

Ce n'était pas pour critiquer, juste pour ne pas que certains se disent "hop, y a plus qu'à"...

Perso, ça, c'est la mienne, d'approche : https://github.com/Lcfvs/anticore/bl...y/one/index.js

Elle ne tient pas compte du fait que ce soit un id ou non mais bon.

[Kearz]

Je comprends pas trop pourquoi les gens sont choqués de la suppression de jQuery. En soit c'est bien, si vos briques sont toutes indépendantes, ça permet de faire sa propre stack.

Tu veux Bootstrap, t'as pas besoin de jQuery? Tu peux.
Tu veux Bootstrap, t'as besoin de jQuery? Tu peux aussi.

C'est simple, c'est logique et c'est efficace. C'est pas comme si Bootstrap avait sortie une version sans jQuery mais avec autre chose, ils ont viré jQuery pour mettre du natif.
Après est-ce que le ratio temps passé pour viré jQuery est bon niveau ROI, c'est autre chose.

PS: si vous êtes bloqué sur la stack : jQuery / Bootstrap, c'est quand même un choix de carrière dangereux. Personnellement, je pense que jQuery va mourir dans les 5 prochaines années et Bootstrap va devoir se renouveler s'il veut pas disparaître.

[grunk]

Que des acteurs majeurs comme bootstrap considère que le support de js est devenu assez bon dans les navigateurs moderne pour se passer de lib supplémentaire est très encourageant.

On laisse IE sur le coté ... "Qui s'en fou ? "
De toute manière si on traîne sans cesse certains boulet , on arrivera pas à s'en débarrasser. A un moment il faut savoir dire stop.

Jquery à été une super lib pendant plusieurs années , mais clairement ses jours sont comptés