Discussion :

[SpaceFrog]

Je tends a utiliser JQuery un peu moins depuis que JS a intégré les sélecteurs querySelector() et querySelectorAll().
Mais je trouve la logique JQuery plus claire et facile a maintenir que du JS pur

[Bigb]

Même si on peut faire la même chose avec les navigateurs récents, il ne faut pas oublier la compatibilité !
On va garder encore jQuery pendant quelques années le temps de voir disparaitre dans les stats de consultation tous les navigateurs qui poseraient problème.
C'est comme à l'époque IE6/7, certains ont laché le support très rapidement, d'autres ont attendu plusieurs années pour être certains de n'écarter personne.

[domi65]

jquery ne sera pas mort de sitôt vu principalement l'inertie naturelle dans toute technique... Et puis 1% des utilisateurs nous em... encore avec des IE obsolètes.
maintenant, il est bien moins pertinent qu'il l'a été vu l'évolution des navigateurs qui respectent bien mieux les standards et ces standards eu-mêmes, principalement les nouveautés HTML5 (support du SVG, nouveau types d'input, etc.), CSS (transitions, animations, etc.) Et ECMAScript.
Et si vous avez besoin de JS, vous faites souvent maintenant en deux lignes ce qui demandait toute une série d'instructions.
Un exemple qui facilite la vie et me vient à l'esprit est l'association des fonctions querySelectorAll et forEach. J'adore !

[Lcf.vs]

Et si vous avez besoin de JS, vous faites souvent maintenant en deux lignes ce qui demandait toute une série d'instructions.
Un exemple qui facilite la vie et me vient à l'esprit est l'association des fonctions querySelectorAll et forEach. J'adore !

Ben, essaie mon anticore, c'est encore plus simple...

Code :

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

1
2
3
4
5
6
 
import { on } from 'anticore'
 
on('body > section', section => {
   // do something
})

Appliquant le code de ton choix, sur toute body > section présente dans le document et celles pouvant arriver, plus tard, en AJAX/SSE via anticore.

Et cela évite aussi une dépendance forte à la bibliothèque : si, un jour, tu venais à vouloir virer anticore, il n'y a que très peu de code "jetable" (l'import et le on), le reste étant toujours utile (le sélecteur et le code à appliquer sur l'élément).

Les requêtes n'ont même pas besoin d'être écrites, puisque la lib écoute les ancres et formulaires, d'un simple defaults() à n'appeler qu'une seule fois.

Et, pour ceux qui ne jurent plus que par le rendu côté client, sachez que cela n'a rien d'incompatible ! Vous pouvez très bien générer votre rendu, via undom, dans un ServiceWorker.

[Stéphane le calme]

jQuery 3.6.2 est disponible et apporte de nouveaux sélecteurs dans Chrome,
mais a-t-on encore besoin de cette bibliothèque JavaScript en 2022 ?

jQuery est une bibliothèque JavaScript libre et multiplateforme créée pour faciliter l'écriture de scripts côté client dans le code HTML des pages web. L'équipe responsable de son développement a annoncé la disponibilité de jQuery 3.6.2. Selon elle, l'impulsion principale de cette version a été l'introduction de nouveaux sélecteurs dans Chrome.

Vous l'avez certainement deviné, la version jQuery 4.0 annoncée depuis quelques années déjà va devoir encore attendre. Cette version sera une refonte de la bibliothèque JavaScript. En effet, l'API de base de jQuery consiste à sélectionner un élément, puis à faire quelque chose avec ce qui a été sélectionné. Sizzle, le moteur de sélection dans jQuery, gère la première partie. C’est un petit moteur rapide et efficace qui a ouvert la voie à des API de sélecteur natif telles que querySelectorAll ainsi qu’à des sélecteurs JavaScript et CSS natifs supplémentaires. Mais maintenant, beaucoup de ces sélecteurs sont intégrés dans les navigateurs modernes. L'équipe jQuery estime donc qu'il est presque temps de dire au revoir à Sizzle, ce qu'elle prévoit de faire dans la version 4.0. L'équipe jQuery assure y travailler, mais d'ici là, elle continuera à prendre en charge la branche 3.x et à résoudre des problèmes importants.

Quelles sont les nouveautés / améliorations apportées par jQuery 3.6.2

variables CSS indéfinies et avec des espaces uniquement

jQuery 3.6.1 a introduit une régression mineure où la tentative de récupération d'une valeur pour une propriété CSS personnalisée qui n'existait pas (c'est-à-dire $elem.css("--custom")) renvoyait une erreur au lieu de renvoyer undefined. Cela a été corrigé en 3.6.2. Dans la même lancée, l'équipe s'est également assuré que les valeurs d'espace uniquement renvoient la même chose sur tous les navigateurs. La spécification exige que les valeurs des variables CSS soient coupées, mais les navigateurs sont incohérents dans leur coupe. jQuery renvoie maintenant undefined pour les valeurs d'espaces uniquement afin de le rendre cohérent avec l'ancien jQuery et sur les différents navigateurs.

Code JavaScript :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
@@ -28,17 +28,37 @@ function curCSS( elem, name, computed ) {
	//   .css('filter') (IE 9 only, trac-12537)
	//   .css('--customProperty) (gh-3144)
	if ( computed ) {
 
		// Support: IE <=9 - 11+
		// IE only supports `"float"` in `getPropertyValue`; in computed styles
		// it's only available as `"cssFloat"`. We no longer modify properties
		// sent to `.css()` apart from camelCasing, so we need to check both.
		// Normally, this would create difference in behavior: if
		// `getPropertyValue` returns an empty string, the value returned
		// by `.css()` would be `undefined`. This is usually the case for
		// disconnected elements. However, in IE even disconnected elements
		// with no styles return `"none"` for `getPropertyValue( "float" )`
		ret = computed.getPropertyValue( name ) || computed[ name ];
 
		// trim whitespace for custom property (issue gh-4926)
		if ( isCustomProp && ret !== undefined ) {
		if ( isCustomProp && ret ) {
 
			// rtrim treats U+000D CARRIAGE RETURN and U+000C FORM FEED
			// Support: Firefox 105+, Chrome <=105+
			// Spec requires trimming whitespace for custom properties (gh-4926).
			// Firefox only trims leading whitespace. Chrome just collapses
			// both leading & trailing whitespace to a single space.
			//
			// Fall back to `undefined` if empty string returned.
			// This collapses a missing definition with property defined
			// and set to an empty string but there's no standard API
			// allowing us to differentiate them without a performance penalty
			// and returning `undefined` aligns with older jQuery.
			//
			// rtrimCSS treats U+000D CARRIAGE RETURN and U+000C FORM FEED
			// as whitespace while CSS does not, but this is not a problem
			// because CSS preprocessing replaces them with U+000A LINE FEED
			// (which *is* CSS whitespace)
			// https://www.w3.org/TR/css-syntax-3/#input-preprocessing
			ret = ret.replace( rtrimCSS, "$1" );
			ret = ret.replace( rtrimCSS, "$1" ) || undefined;
		}
 
		if ( ret === "" && !isAttached( elem ) ) {

.contains() avec <template>

Un problème a été récemment signalé qui montrait qu'un document <template> avait sa propriété documentElement définie sur null, conformément à la spécification. S'il était sémantiquement logique qu'un modèle ne soit pas encore lié à un document, cela constituait un cas inhabituel, en particulier dans jQuery.contains() et toutes les méthodes qui en dépendent. Cela comprenait des méthodes de manipulation et de sélection. Heureusement, la correction était simple.

Ce n'est pas Ralph qui a brisé Internet (clin d’œil au film d'animation Ralph 2.0)

Internet a connu une petite grogne lorsque Chrome a récemment introduit de nouveaux sélecteurs, dont le plus pertinent est :has(). C'était un ajout bienvenu, et célébré par l'équipe jQuery, mais une modification de la spécification signifiait que :has() utilisait ce qu'on appelle « l'analyse indulgente ». Essentiellement, même si les arguments de :has() n'étaient pas valides, le navigateur ne renvoyait aucun résultat au lieu de générer une erreur. Cela posait problème dans les cas où :has() contenait une autre extension de sélecteur jQuery (par exemple :has(:contains("Item"))) ou se contenait elle-même (:has(div:has(a))). La bibliothèque de sélection CSS Sizzle [ndlr. écrite en JavaScript, elle permet de parcourir le DOM d’un document (HTML, XHTML, XML etc.) à l’aide d’expressions CSS] s'est appuyé sur des erreurs comme celle-ci pour savoir quand faire confiance à querySelectorAll natif et quand exécuter le sélecteur via Sizzle. Les sélecteurs qui fonctionnaient plantaient dans toutes les versions de jQuery remontant aux premières versions de jQuery.

Et pourtant, ce petit drame n'a pas duré longtemps. L'équipe Chrome a rapidement mis en place une solution de contournement pour corriger les versions précédentes de jQuery dans la grande majorité des cas. Safari a géré leur implémentation de :has() un peu différemment et n'a pas eu le même problème. Le CSSWG a depuis résolu le problème.

jQuery a pris des mesures pour s'assurer que toute analyse indulgente ne casse pas les futures versions de jQuery, même si les versions précédentes de jQuery seraient toujours affectées.

A-t-on vraiment besoin de jQuery aujourd'hui ?

Créé pour simplifier l'écriture de JavaScript et HTML, jQuery est arrivé au bon moment en 2006, avec la complexification croissante des interfaces Web. Cela lui a permis de séduire en masse les développeurs Web et d'avoir le statut d'élément fondamental dans les formations aux technologies du Web.

jQuery était il y a peu la bibliothèque JS la plus utilisée au monde et bon nombre de frameworks l'utilisaient pour fonctionner. jQuery est une dépendance d'environ 30 Ko utilisée par près de 84 % des pages mobiles en 2021, et pour cause. jQuery était un outil instrumental à une époque où nous avions vraiment besoin d'un moyen de scripter l'interactivité de manière à lisser les différentes implémentations de choses comme la gestion des événements, la sélection d'éléments, l'animation d'éléments, etc.

Voici un exemple d'Ajax avec jQuery :

Code javascript :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
$(document).ready(function() {                    // Lorsque le document est chargé 
    $(".load_page_on_click").click(function() {   // Lorsque l’on clique sur un élément d'attribut class "load_page_on_click" 
        var email = $("input[name=email]").val(); // Variable contenant la valeur d'un élément input d'attribut name "email" 
        $.ajax({                         // Exécution d’une requête Ajax avec la configuration donnée par l'objet suivant : 
            async: "true",               // - requête asynchrone 
            type: "GET",                 // - type HTTP GET 
            url: "mapage.php",           // - URL de la page à charger 
            data: "email=" + encodeURIComponent(email) + "&action=get_email", // - données à envoyer 
            error: function(errorData) { // - fonction de rappel en cas d’erreur 
                $("#error").html(errorData); 
            }, 
            success: function(data) {    // - fonction de rappel pour le traitement des données reçues en cas de succès 
                $("#container").html(data); $("#error").append("Contenu chargé"); 
            } 
        }); // Fermeture de l'appel à la fonction $.ajax 
    });     // Fermeture de la fonction de rappel du $(".load_page_on_click").click 
});         // Fermeture de la fonction de rappel du $(document).ready

Mais avec l'émergence de nouvelles technologies (bibliothèques et frameworks) et la modernisation des navigateurs, le caractère incontournable, voire la pertinence, de jQuery ne fait plus l'unanimité. Les problèmes qui autrefois nécessitaient jQuery sont maintenant en train d'être résolus par les navigateurs et le standard EcmaScript en évolution. Certains développeurs ont donc commencé à prendre de la distance vis-à-vis de la bibliothèque JavaScript.

C'est le cas par exemple de l'équipe Bootstrap qui a annoncé l'abandon de jQuery dès la première version alpha de Bootstrap 5 pour retourner à du pur JavaScript. Selon Mark Otto, créateur du framework et auteur du billet de blog qui a annoncé cette version alpha 1, « jQuery a apporté un accès sans précédent à des comportements JavaScript complexes pour des millions (milliards ?) de personnes au cours des quinze dernières années », et « peut-être qu'il a changé à jamais le JavaScript lui-même », mais le temps était venu pour l’équipe d’abandonner jQuery en tant que dépendance. Selon le billet, ce changement est rendu possible grâce aux progrès réalisés dans les outils de développement front-end et la prise en charge des navigateurs.

Le principal argument avancé 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), ajouter une dépendance serait soit « stupide », soit un gaspillage de bande passante.

C'est aussi le cas de Gov.UK, le site Web d'information du secteur public du Royaume-Uni, a cessé d'utiliser jQuery.

En mars 2022, Matt Hobbs, Responsable du développement front-end de Government Digital Service (qui offre des plateformes, des produits et des services qui aident le gouvernement à devenir intégré, fiable et réactif aux besoins des utilisateurs notamment GOV.UK), a annoncé que GOV.UK avait supprimé sa dépendance jQuery. C'est un gros problème en ce qui concerne l'expérience utilisateur, car GOV.UK fournit des services et des informations en ligne pour le Royaume-Uni à grande échelle. Tout le monde n'utilise pas son MacBook Pro 2022 sur une connexion haut débit à couper le souffle. GOV.UK doit être accessible à tous, et cela signifie qu'il doit rester léger.

Dans la communauté des développeurs, les avis divergent quant à ce changement. Ceux qui l'ont bien accueilli reconnaissent que jQuery est l’une des bibliothèques les plus importantes de l’histoire JavaScript et a permis de créer de véritables applications Web. Ils estiment cependant que 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é.

La suppression du moteur de sélection de jQuery parce qu'il existe maintenant des sélecteurs natifs dans les navigateurs modernes tend à donner raison à ceux qui pensent que jQuery est de moins en moins pertinent. D'autres estiment malgré tout que la bibliothèque JS est loin d'être obsolète, car les techniques jQuery ne sont pas aussi ergonomiques à mettre en œuvre sans utiliser jQuery. Pour ces derniers, ça reste donc un outil très productif qui offre des solutions simples à de nombreux problèmes.

Source : jQuery

Et vous ?

Que pensez-vous de jQuery 3.6.2 ?
A-t-on encore besoin de jQuery actuellement selon vous ?
Utilisez-vous jQuery ou un framework / bibliothèque JavaScript en 2022 ?

[ABCIWEB]

La suppression du moteur de sélection de jQuery parce qu'il existe maintenant des sélecteurs natifs dans les navigateurs modernes tend à donner raison à ceux qui pensent que jQuery est de moins en moins pertinent. D'autres estiment malgré tout que la bibliothèque JS est loin d'être obsolète, car les techniques jQuery ne sont pas aussi ergonomiques à mettre en œuvre sans utiliser jQuery. Pour ces derniers, ça reste donc un outil très productif qui offre des solutions simples à de nombreux problèmes.

Bah oui, parler de jQuery pour ses sélecteurs, c'est excessivement réductif, s'il n'y avait que cela ça fait longtemps que je m'en serais passé. Je me retrouve donc dans la dernière catégorie, jQuery est très productif dans de nombreux cas de figure. Vous n'êtes pas obligés de l'utiliser, mais c'est vrai pour toutes les lib ou frameworks javascript.

[smarties]

Que pensez-vous de jQuery 3.6.2 ?
Elle suit les évolutions technologique des navigateur donc rien d'anormal de ce côté là.

A-t-on encore besoin de jQuery actuellement selon vous ?
Je pense que non, on cherche à maintenir quelque chose sur un problème qui n'existe quasiment plus car les navigateurs se sont standardisés.

Utilisez-vous jQuery ou un framework / bibliothèque JavaScript en 2022 ?
Non, je fais peu de front et quand j'en fais c'est du vanilla JS avec les API standards des navigateurs et je n'ai pas eu d'incompatibilité jusqu'à présent.

[marc.collin]

tu en as besoin en autre pour https://datatables.net/

sinon si tu veux exécuter le js d'un fichier html, c'est plus simple avec jquery... fetch ne le fait pas

[eomer212]

que les gros avec leurs framework crees pour les gros fassent ce qu'ils veulent.
le probleme de bootstrap, c'est ses limitations.
jquery n'est pas que des selecteurs. c'est des composants aussi, une partie UI reellement pratique.
mais bon, il y a toujours des gens pour dire, moi je fais pas comme ca, et je l'impose aux autres. et bien sur, les propagandistes en question se referent toujours d'une liberté dont les concepts leurs sont inconnus.
à l'époque du RTC (que j'ai bien connu, rappellez vous, les modems qui chantaient..), j'aurais pu comprendre l'argument du poids. (rendez vous compte. 40 Kilo Octets, 2,7% d'une disquette,le bout du monde!!!. ) comparez avec la moindre ressources actuelle, texte,css, image, svg, etc. sans parler de vidéos.. et ils vont faire pleurer dans les chaumiéres pour 40KO., qui en plus sont utiles..??
non, c'est juste, encore une fois, un épiphenoméne de jeunisme exacerbé comme on en connais réguliérement dans l'informatique depuis le debut, de 'je suis dans le vent' , 'je me rebelle', je reinvente le monde en plus chiant et plus limité, etc.. bref, des adolescents.

plus prosaiquement, utilisez jquery si ca vous apporte quelque chose, plus simple pour vous, plus rapide, connu, efficace, j'en passe et des meilleurs.
ne vous laissez pas emmerder par les declarations tonitruantes de quelques truands et terroristes sectaires qui veulent avoir une influence qu'ils ne méritent pas.
rendez service à vos clients, faites de bonnes applis, jeux, programmes, etc. faites vous plaisir en realisant des choses de qualité.
personne ne regardera sous le capot si ca fonctionne bien et rends le service attendu.
et ca, c'est pas le fait de telle ou telle libraire, c'est vous et votre approche de la résolution de chaque probleme spécifique..

[shenron666]

mode troll : et dire que developpez.net est resté sur jquery 1.7.2
sinon pour répondre simplement à la question, oui est est toujours beaucoup utilisée
et on n'utilise pas uniquement une bibliothèque parce qu'on en a besoin mais aussi pour ne pas réinventer la roue

[patrick72]

jquery :

1 - Permet une compatibilité entre navigateur (perso je suis toujours à la 1.9 qui était la dernière à prendre en charge IE8... et oui, j'ai encore des clients sous IE !)
2 - Simplicité du code par rapport à javascript pour certaine fonction, comme par exemple, création d'un gestionnaire d'événement ou un appel Ajax.
4 - jQueryUI ! solution simple pour avoir un visuel sympas et qui m'a permis d'évolué mon applicatif - qui a plus de 15 ans - et qui fonctionnait historiquement avec des popups !
5 - Une bibliothèque libre de composants en tout genre, facilement exploitables.

jQuery ce n'est pas un framework intrusif (comme jQueryMobile par exemple) imposant un modèle très fermé. Là, il ne s'agit que de quelques fonctions simple (basées sur un sélecteurs d'élément du DOM), laissant le développeur libre...

[pduboin]

(perso je suis toujours à la 1.9 qui était la dernière à prendre en charge IE8... et oui, j'ai encore des clients sous IE !)

COOL !!!!! …*Les "Scripts kiddies" du monde entier doivent quotidiennement te remercier…

[oooopppp]

Salut à tous !

Je sais que le débat fait rage JQuery/plus jQuery ...

Je vais vous livrer ma réflexion à travers un exemple pratique.

Il y a 1 an je me suis lancé dans l'écriture de Placido-Shop, un programme de vente en ligne,
base sur JS et PHP.

Avant de démarrer, il a fallut se poser la question des langages à employer.

Le but était de produire un un code open-source,
facilement compréhensible même pour des novices,
que je devais développer rapidement et qui soit efficace et sans bugs.

J'ai alors choisit d'utiliser jQuery, car je l'utilise au quotidien pour mes clients.

Même en 2023, jQuery permet d’accélérer le développement, on livre plus vite,
le code est clair et compréhensible.

Toutefois, durant cette année de dev. sur mes fonds propres, j'ai été influencé par la "hype" anti-jQuery
et je me suis amusé à coder une partie en vanillia, pour changer un peut aussi et éviter l'ennui ...

Conclusion : J'en chié comme jamais pour reproduire ce que je fait habituellement facilement en jQuery.

Plus, je n'ai pris aucun plaisir et j'ai eu une sensation de pénibilité à coder des choses que je savais faire plus
facilement en jQuery.
Et comme je l'ai déjà mentionné sur ce forum l'API fetch de JS plante toutes les X requêtes sans savoir pourquoi (je cherche encore ...).

- ça a été désagréable et ça m'a vacciné du Vanilia, du moins pour mon framework et mes prestations en général, car pour d'autres cas de figure,
pour Node ou pour React, il faut bien en passer par le Vanillia et par le nouveau JS qui n'est pas supporté par les navigateurs (trop cool!).

A ce propos, je trouve très désagréable cette hype du terminal ( les dev. ont'ils l'impression de devenir de vrais informaticiens en se servant du terminal ? )
et devoir compiler un site alors qu'on dev. pour le web me semble une abjection.

Donc, je conclurais en disant : Longue vie à jQuery !
Et je crois avoir lu dans l'article que près de 80% des sites en ligne l'utilisent,
... pas vraiment mort le framework, un peut comme PHP que tout le monde enterre alors qu'il domine encore le web ET TANT MIEUX !

p.s. Les arguments du temps de chargement sont insensés, il suffit déjà d'héberger le code sois-même, d'avoir une bonne politique de cache.
p.s.1 bis: quand on compare cela aux 36 bibliothèques que charge un projet Node, où est le gain ?
p.s.2 : De plus en plus je prend conscience du pouvoir de pression que savent exercer certaines personnes pour vous forcer à utiliser des outils
qui sont certes dans la "hype", mais qui au final vont vous faire perdre du temps sur la livraison de votre code et sur sa fiabilité,
je ne comprend pas quel est l’intérêt de ces gens de pousser à fond les devs. dans la hype, quel est leur intérêt ? Éclairez-moi je suis naïf ...