Discussion :

[alexvb6]

jQuery, c'est pas Sexy ni trendy. Sauf que c'est partout.

Doit-on en rajouter sur les nouveaux projets ? Oui, si l'on considère que je fais mon beurre en vendant mon temps à des clients, et qu'il est limité.

Aucun client n'a l'argent nécessaire pour que je refactorise tout son code en ECMAScript 2015, ni pour que je lui dise "eh, je vais me former sur Vue.JS pendant 3 mois, et ECMASCript 2015 pendant 1 mois, et puis aussi sur Docker pendant 2 mois : vous me payez ? Oh et puis comme la compétence vient de l'expérience (et donc des merdes), je vais me faire la main sur votre appli en PROD, ça vous dérange pas, non ??".
Évidemment, durant cette période je serai indisponible pour maintenir ses outils critiques. Il va surkiffer, c'est sûr. Il va adorer que je lui fasse supporter le poids de mes propres décisions en lui imposant de graves contraintes pénalisantes sur son activité !

J'évolue progressivement sur certaines fonctions JS, bien sûr, je cherche à optimiser, je lis des articles avec des alternatives, des méthodes plus performantes, mais toujours en mixant les critères de faciliter la maintenabilité tout en évitant de passer 1000 ans à tout réapprendre à chaque seconde. Les récentes refontes du standard ECMAScript en font pratiquement un nouveau langage.
Les => et autres ... dans les définitions de fonctions font que j'ai l'impression de me taper du Powershell !
VBScript est ultra compréhensible à la place, et même si ça prend 5 lignes de plus qu'en Powershell, c'est lisible, et je peux taper dans les WMI sans problème. Pourquoi passer à Powershell ? Ben non. Pareil pour jQuery, sauf dans des projets ou la perf est ultra-critique, mais ces clients là ont un budget illimité et n'ont pas de problème à payer des dépassements de budgets x3 à des SSII de dimension mondiale sans scrupules, et pas toujours très compétentes... sauf peut-être en optimisation de dumping vers des dev basés en Asie ou à Macao.

Le temps de formation, c'est du temps. Du temps de vie, de ma vie. Il est limité ce temps. Je pourrais y passer les week-ends ? Ahaha, allez, je ne serai jamais assez bon pour apprendre tout ce qui évolue et toutes ces plateformes sexy et trendy qui naissent, meurent, plus vite que la lumière en seulement 1,5 jours par semaine.

Angular.JS ? c'est super.. ah non pardon.. c'est déjà nul, vaut mieux Vue.JS. Et d'ailleurs pkoi apprendre le Javascript sauce ECMAScript 2015.. Y'a Typescript, non ?
Python ? Ouais, c'est du solide... !! Ah non pardon, Ruby c'est mieux. Je vais plutôt m'améliorer en C#.. non en F#.. et puis en R.. euh.. non en Y, en Z, en Z', voire en ZETA3 ou en PETA(ouchnok) .... Allez, on défonce tout ce qui est on-premise et on fonce sur le Cloud... Ah non, pardon, les serveurs cloud s'éteignent et perdent des données de milliers de boites chaque jour. Bon ben on va sur Docker.. ah ben merde c'est pas sécurisé et galère à sécuriser. J'aurais du réfléchir un peu plus avant de perdre mon temps et mettre mes client en danger.

Bon je devrais prendre le virage du Node.JS.. ah ben attends, les 56 frameworks et libs que j'utilise sont mis à jour tout le temps, ou pas maintenus, ou alors je les ai tweakés à donf, ou alors pire, il ont été remplacés par des packages NPM de ransomware qui ont les mêmes noms ... Bon, alors je vais arrêter l'ASP Classic et passer à .NET.. attends.. on en est à combien d'itérations du Framework .NET déjà ?... le MVC, c'est mort. Les WebForms ? Pareil... comment s'appelle leur nouvelle mouture déjà ? . NET 5. Ah. Ok. Je dois tout réapprendre je pense, non ? Allez, encore une certif Microsoft sur mon tmeps libre. Ah ben j'en ai plus : j'essaye de vivre un peu et passer 2h par jour avec mon gamin avant de mourir.

À ce rythme là, j'ai compris depuis des années que suivre les modes ou les MAJ incessantes de chaque techno ou OS c'est une erreur.

Il faut du temps d'assimilation et de maturation. Regarder sans se presser, puis prendre si ça semble solide. Je me documente, je suis abonné à des NL de dev, de comm, de UI/UX, mais je n'en sélectionne que ce qui me semble pertinent pour maintenant et demain, qui ne prend pas 1567 ans à apprendre (à 90 ans max je serai mort, sot seulement 50 maintenant). Prendre et me former sur ce qui permet à mes clients de compter sur moi comme un expert des technos que je maitrise.

Ça va en faire braire une paire ici, mais je suis un expert en maintenance et en optimisation des performances ASP Classic depuis plus de 15 ans, et j'en ai pas encore 40. Et mes (nombreux) clients (et pas des petits) préfèrent dépenser chez moi 5% du budget que leur couterait une refonte risquée en n'importe quoi d'autre, sans compter le temps que ça leur prendrait. Oh, et puis je ne suis en concurrence avec personne sur cette techno. Ça m'évite de baisser mon froc à facturer du Wordpress customisé en Vue.JS + PHP + Python + Docker pour 5€ de l'heure. Je ne suis pas prêt de m'inscrire sur Fiverr ou 5euros.com pour être en concurrence avec 75% des dev de la planète qui se tirent la bourre sur les mêmes technos !

Et ouais je sais faire du rapide, du sécurisé, et du responsive. Je sais même utiliser du JSON et de l'AJAX (ouahhhhh !). Même que j'intègre du WCAG dans mes sites développés en ASP Classic, et que PageSpeed me fout du vert malgré la présence de jQuery. Calmons-nous, hein : on parle de jQuery, pas de Macromedia Flash v2 !

Lorsque jQuery sera mort, je serai là pour sauver la vie de mes clients dont le front-end repose encore dessus. J'aime être un bon spécialiste, pas un mauvais généraliste

[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.

[gerard093]

Je vais donner mon opinion : JQUERY je ne l'ai jamais utilisé, Ajax j'ai. JQuery ne me manque pas surtout avec les nouvelles fonctions d'HTML 5.
Je n'ai donc pas de problème de mise à jour forcée, ce qui arrive forcément un jour avec les framework. Bonjour à ceux qui veulent gérer simultanément les évolutions de Jquery et de struts.

JQUERY mal maitrisé est une bonne faille pour les attaques à partir de Kali. C'est à mon avis un vrai problème pour le framework.

Et généralement tous les frameworks sont des opportunités pour les hackers, dont le niveau de compétence dépasse celui des néophytes.

ET J'AI PLUS DE CINQUANTE ANS ALORS QUAND J'APPRENDS QUE JE SUIS DE LA JEUNE GENERATION CAR JE NE L'AI JAMAIS UTILISE JE MOUSSE !!! VIVE LE COBOL SECRET DE JOUVENCE ET DE VIE ETERNELLE !!!

[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.

[ABCIWEB]

Je vais donner mon opinion : JQUERY je ne l'ai jamais utilisé
...
Je n'ai donc pas de problème de mise à jour forcée, ce qui arrive forcément un jour avec les framework.

Faut relativiser, rien n'est forcé. JQuery n'utilise que du code javascript avec des fonctionnalités qui respectent le standard. Et étant donné que les différentes versions de javascript sont rétrocompatibles avec les anciennes versions, le code que tu as écrit continuera de fonctionner. Quant aux mises à jour de sécurité, un code bien fait est sécurisé côté serveur en prenant pour principe que ce qui vient du client n'est pas fiable, donc là encore normalement elles ne sont pas essentielles.

[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

[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

[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 ...