Discussion :

[domi65]

« jQuery est une dépendance d'environ 30 Ko »
Non, elle fait 86 Ko (version 3.4.1)

[shenron666]

32 Ko d'économisés, bravo
Quand je vois que le front-end dans ma boite pèse plusieurs Mo, je me dis depuis toujours que ce n'est pas jQuery le problème

[grunk]

« jQuery est une dépendance d'environ 30 Ko »
Non, elle fait 86 Ko (version 3.4.1)

86Ko c'est la version normal , mais a peut près n'importe quel serveur web configuré correctement sert une version gzipé qui doit être autour des 30Ko

[domi65]

On peut même dire que c'est zéro octets puisque il y a de bonne chance que la bibliothèque soit dans le cache. Mais cela fait bien 86 Ko de code JS à analyser par l'interpréteur.
Cela dit, je reconnais que je n'ai aucune idée du travail que cela demande au processeur.

P.S.
J'ai vu dernièrement une page où JQuery ne servait qu'à faire $('#identifiant').clic(fonction(){...}). Parfaitement con, à mon avis, surtout que la fonction en question était truffée de document.getElementById('identifiant').

[ABCIWEB]

de plus, avec jquery, on a tendance (moi a l'epoque) d'abuser de .animate ou de .slideUp/Down (et autres effets)...
=> c'est infiniment mieux de gerer les animations dans le css et d'appliquer une classe a l'element

Pas d'accord là dessus. Je préfère largement centraliser le code en un seul endroit quand c'est possible plutôt que de l'éparpiller entre css et js. Tu oublies aussi de dire que ces fonctions bénéficient de callback bien pratiques qu'il serait plus laborieux d'implémenter en vanilla.

Quant aux gains de vitesse (effets js vs effets css) ils sont la plupart du temps plus théoriques que pratiques. Je teste par ailleurs le code sur un vieux smartphone qui a 9 ans d'age et que j'avais acheté 70€ à l'époque pour justement tester dans les conditions les plus défavorables. Sur cet (très) ancien appareil entrée de gamme limité à la 3G, jQuery ne pose pas de problèmes. A savoir au passage que la 2G disparaîtra en 2025 et la 3G en 2028.

Et au final quand tu auras fait l'équivalent en js de toutes les fonctionnalités spécifiques de jQuery, tu vas gagner quoi, quelques kilos pour avoir un code plus verbeux, moins lisible et plus dispersé. Là où je suis d'accord avec toi c'est que cette librairie est devenu inutile pour des petits bouts de code, étant donné que le seul argument de compatibilité est marginal de nos jours. Mais jQuery permet de gagner du temps sur les gros développements, c'est le principe même de toute librairie.

Sans doute aujourd'hui on pourra gagner plus de temps en utilisant de "nouvelles" librairies plus spécifiques mais il faudra souvent en utiliser plusieurs, ce qui requière aussi plus de compétences, de suivi technologique et au final de dépendances. Certes jQuery n'est plus utile avec ces nouvelles librairies mais il peut l'être dans un contexte plus généraliste.

Je ne dis pas que la priorité des nouveaux développeurs doit être d'apprendre jQuery, mais cette chasse aux sorcières me paraît bien puérile. Concernant la pérennité du code, je ne me fais aucun souci, surtout quand je vois que les dernières versions de la branche 1 fonctionnement encore. Et pour la dernière branche, la version 3.6.1 vient de sortir il y a tout juste 4 jours.

[Rolllmops]

JavaScript vanilla manque en effet cruellement d'api natives pour animer des propriétés.

[oooopppp]

Mmm !
Je me passerais de JQuery quand l'API fetch ne produira plus des bugs inattendus et hasardeux,
c'est bien de dire "Mec t'est rouillé de faire des requêtes http en AJAX, sert-toi de fetch", Oui mais fetch plante lamentablement des fois,
comme ça, sans prévenir, et même après avoir passé deux jours à configurer tous les headers correctement (je suis au top en headers maintenant !).

Encore, petit goodie, fetch ne reconnait pas l'en-tête "application/json". (whaaat ??)

Une dernière chose sur du pur JS, j'ai demandé la modification de la documentation JS sur Mozilla
car undefined DOIT s'utiliser entouré de guillemets avec l'opérateur typeof, pour le reste y'en pas besoin, va le savoir ça ...

Bref, en plein dev. d'une API, j'ai décidé d'en faire une partie en "vanillia", pour tester,
j'ai fait tout mon gestionnaire de stats. en pur JS
et franchement j'estime avoir mis entre 40% et 50% de temps en plus, alors oui c'est vieux JQuery mais
quand tu dois produire du code de qualité en rase campagne et que tu dois gagner ta croûte, et bien c'est rapide et efficace ...

Mais les technos à la hype citées plus en amont, ça se vend plus cher, c'est bien pour les grosses boites et ça permet
de d'aérer les cerveaux des devs.

[Doksuri]

@ABCIWEB
ce n'est pas parce que tu sais conduire une voiture automatique, que tu sais conduire une manuelle... par contre, si tu sais conduire une manuelle, conduire une automatique est un jeu d'enfant.
=> ce n'est pas parce que tu sais faire du jquery que tu sais faire un JS.

quand j'ai abandonne jquery, je me suis vraiment penche sur la doc de chaque nouvelle chose que j'aprennais en vanilla... et je me suis senti tellement "inculte du JS", je me suis meme demande si j'avais le droit de mettre "JS" sur mon CV tellement j'avais de lacunes....

si c'est la verbosite / lisibilite qui te pose probleme, tu peux toujours te faire des "alias". par exemple

Code javascript :

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

1
2
3
4
function qs(s) { return document.querySelector(s); }
function qsa(s) { return document.querySelectorAll(s); }
 
const list = qsa('.maListe');

sinon, le switch de jquery a js est comme apprendre un nouveau language... le plus long est d'apprendre les syntaxes

@oooopppp
perso... je n'ai jamais eu de probleme avec fetch... quelque soit la conf...
le seul truc que je n'avais pas compris (et qui peu en surprendre plus d'un...) est qu'une erreur 404 n'est pas une erreur de fetch...
=> le fetch a correctement recu une reponse du serveur, qui s'avere avoir un statut 404
=> une 404 (ou autre codes d'erreur) ne va pas trigger le .catch du fetch...

pour ce qui est du typeof... je suis desole, mais c'est la 1ere ligne de la doc : developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Operators/typeof

L'opérateur typeof renvoie une chaîne qui indique le type de son opérande.

donc oui... quand tu teste le typeof undefined... faut tester une string...

en pur JS et franchement j'estime avoir mis entre 40% et 50% de temps en plus

c'est normal... tu ne connais pas le vanilla sur le bout des doigts ...

JavaScript vanilla manque en effet cruellement d'api natives pour animer des propriétés.

c'est "normal" j'ai envis de dire... ce n'est pas le but 1er du JS

[oooopppp]

@oooopppp
perso... je n'ai jamais eu de problème avec fetch... quelque soit la conf...
le seul truc que je n'avais pas compris (et qui peu en surprendre plus d'un...) est qu'une erreur 404 n'est pas une erreur de fetch...
=> le fetch a correctement reçu une réponse du serveur, qui s'avere avoir un statut 404
=> une 404 (ou autre codes d'erreur) ne va pas trigger le .catch du fetch...

Salut !

Ben oui, je sais bien lire un code de réponse http
mais essaye, fait toi un petit bout de code qui envoie 50-100 requêtes vers un serveur avec Fetch
- j'ai oublié de préciser que c'était sur gogol Chrome,
tu verras il y a un moment où la requête va échouer alors que les 99 autres sont passées avec les mêmes paramètres envoyés, tout, tout pareil,
(punaise dans qques jours le code sera diffusé en Open-Source, tu pourras tester et/ou m'aider à débeuguer si tu le souhaite),
dans mon souvenir, ça disait que ça appelait la requête dans un contexte public mais que le serveur répondait publiquement mais que ... bref, etc ...

Je précise que je fais ces requêtes sur un serveur où il y a des en-têtes CORS, au top de la sécurité, comme indiqué dans les docs,
mais des fois ça plante (note: en même temps je surveille les coupures de réseau), donc ... recherches, recherches et d'autres ont le même
problème, mais PERSONNE n'a la solution, donc ça bug ...
et ça m'énerve car je dev. des API sans bugs ( oui je met 3 plombes mais le service client reste muet et ça m'épargne su stress )

Pour ce qui est du typeof... je suis désole, mais c'est la 1ere ligne de la doc : developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Operators/typeof

-> Ok mais pas sur la doc de undefined , dont j'ai demandé la modif, donc si tu prend la doc de undefined, t'en a pour des jours à comprendre ce qu'il se passe ...

c'est normal... tu ne connais pas le vanilla sur le bout des doigts ...

-> heu.. quand même ... j'ai dev. des trucs entiers en NODE, je pourrais probablement jamais tout cerner du langage,
mais j'en ai bouffé des tonnes et des variées ( les API * ) et j'en bouffe encore chaque jours ...,

-> Je ne crache pas sur le "vanillia", je dis que pour l'instant JQuery est plus clair et plus rapide à développer.

* LES API,
tiens je l'avais oublié celle là aussi :
"Regardez comme c'est trop cool les API JS, vous allez pouvoir faire de la vidéo-conférence !",

alors oui, l'exemple fonctionne bien en localhost, mais tu ne peux pas encore développer une application de vidéo-conférence car derrière il te
faut un solide serveur STUN/TURN pour gérer tout le flux entre les participants et ça j'en ai un peut marre aussi,
quand tu passes une semaine à te régaler à faire un prog. de vidéo-conférence et qu'à la fin tu te rend compte que tu ne vas
pouvoir l'utiliser que dans ton salon, ça gâche !

-> Certes le langage a de belles promesses et il sert même de contrôleur au télescope James Webb (Merci la newsletter de developpez.net !)
Mais j'attend que tout ça soit bien
1/ compatible avec Apple (les derniers à faire chier sur le web)
2/ Que les belles promesses réalisables par les API soient vraiment exploitables en production

cordialement, ^_^

p.s: je reviens sur l'en-tête "application/json" qui n'est pas reconnue par Fetch, alors que c'est fait un peut pour ça ... Quand même !

[ABCIWEB]

@ABCIWEB
ce n'est pas parce que tu sais conduire une voiture automatique, que tu sais conduire une manuelle... par contre, si tu sais conduire une manuelle, conduire une automatique est un jeu d'enfant.
=> ce n'est pas parce que tu sais faire du jquery que tu sais faire un JS.

quand j'ai abandonne jquery, je me suis vraiment penche sur la doc de chaque nouvelle chose que j'aprennais en vanilla... et je me suis senti tellement "inculte du JS", je me suis meme demande si j'avais le droit de mettre "JS" sur mon CV tellement j'avais de lacunes....

si c'est la verbosite / lisibilite qui te pose probleme, tu peux toujours te faire des "alias". par exemple

Code javascript :

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

1
2
3
4
function qs(s) { return document.querySelector(s); }
function qsa(s) { return document.querySelectorAll(s); }
 
const list = qsa('.maListe');

sinon, le switch de jquery a js est comme apprendre un nouveau language... le plus long est d'apprendre les syntaxes

Tes arguments ne tiennent pas car ils s'appliquent de la même manière pour TOUTE librairie ou framework javascript. Ce que tu dis n'est donc pas spécifique à jQuery, on devrait avoir de bonnes bases en javascript avant d'utiliser n'importe quelle librairie et il n'est pas certain que ce soit le cas de tous ceux qui utilisent les nouvelles librairies plus à la mode.

De toutes façons, sur un développement assez conséquent, on devra à un moment ou à un autre connaître javascript quand on fait du front end. Personnellement j'ai eu le parcours inverse au tien puisque je codais en vanillla avant d'utiliser jQuery. Et je continue de l'utiliser car il me fait gagner du temps. Quant à tes "alias", sur le principe tu es juste entrain de réécrire une lib comme jQuery... donc autant se servir de l'original.

Un exemple ici de création de filigrane wysiwyg dans le contexte d'un upload de photos. Entièrement paramétrable, compatible avec un upload multiple (avec possibilité de filigrane différent pour chaque photo), gestion de preset pour gagner en productivité, cela fait du boulot. Quelle autre librairie que jQuery aurait pu me faire gagner du temps dans le contexte de ce développement et en ayant aussi peu de dépendances ?

Au passage, pour ceux qui utilisent Php et qui seraient intéressés, le module d'upload (qui ne se limite pas à la création de filigrane et permet entre autre de télécharger des très gros fichiers en surpassant les limites serveur) est livré prêt à l'emploi avec le traitement côté serveur. Il suffit donc de le télécharger et de le poser sur son serveur pour faire les premiers tests de fonctionnement complets.

Après je veux bien que mon code ne soit pas un modèle (les cadors en javascript s'y seraient probablement pris autrement) mais il propose de très nombreuses fonctionnalités et il rempli son rôle. Pour dire qu'on peut utiliser jQuery tout en ayant des bases en javascript, car il y a beaucoup de vanilla si tu regardes le code source.

A un moment je me suis posé la question du tout vanilla, mais il y a de nombreuses fonctionnalités jQuery qui demandent une ou plusieurs lignes de code en vanilla qui par ailleurs est plus verbeux. Ajouté à cela les animations et leur callback, plus le fait de vérifier si la fonction de remplacement n'est pas trop récente et implantée sur tous les navigateurs... jQuery fait tout ça pour moi, alors je suis pas maso, surtout que toutes ces lignes supplémentaires diminueraient l'intérêt de se passer de jQuery et de ses 30Ko de code gzip.

Et puis ceux qui veulent personnaliser leur code ont par la même occasion jQuery à leur disposition et cela ne les empêche pas d'utiliser javascript. Bref j'ai très vite abandonné cette idée, sinon dans l'absolu ont pourrait aussi se passer de toutes les lib front end et ne coder qu'en pur javascript. Personnellement tout en faisant des sites responsive, je n'utilise pas Bootstrap, mais je ne rentre pas en croisade contre ceux qui l'utilise, et je ne les accuse pas non plus à priori d'être incompétents en javascript/css, même si l'on peut aussi s'en passer.

[SpaceFrog]

Entre 80Ko et la tonne d'autres saletés chargées en background pour le tracking et autres outils marketing ... (voir la bande passante esquivée par le navigateur Brave ...)
On peut très bien se passer de JQuery mais vu que la plupart du temps comme déja signalé il est déja en cache, je ne comprends pas cet engouement à vouloir absolument taper sur JQuery qui peut s'averer un gain de temps à la programmation dans certains cas ...
Que l'on s'attaque d'abord aux scripts invisibles de tracking et autres espions marketing avant de vouloir erradiquer un outil qui peut être utile ...