Pourquoi les navigateurs n'ont-ils pas installé jQuery?

19

J'utilise jQuery sur plusieurs de mes sites Web et bien que j'utilise un CDN pour le servir, cela n'a tout simplement pas de sens pour le visiteur de télécharger jQuery à chaque fois. jQuery doit être le framework JavaScript le plus utilisé au monde - cela n'aurait-il pas plus de sens si les navigateurs l'ont simplement installé par défaut?

De cette façon, des millions de fois par jour, un téléchargement de jQuery pourrait être empêché. Soit à partir des sites Web des gens, soit à partir des CDN.

Tout ce qui serait vraiment nécessaire est une sorte de déclaration if comme:

 <!--[if jQuery gt 11]>

Existe-t-il quelque chose qui m'aidera à empêcher les utilisateurs de se rendre sur le CDN s'ils ont déjà jQuery dans leur cache à partir d'un autre site?

cache browsers jquery

— user1914292
source

3

la question est - pourquoi un utilisateur doit-il effectuer de nouveaux téléchargements à partir de sites ou de CDN pour quelque chose qu'il a déjà? jQuery est servi à partir de nombreux emplacements et dans de nombreuses versions. Je suis préoccupé par la vitesse des pages et les utilisateurs sont préoccupés par la bande passante (en particulier mobile). S'il existe une norme d'or pour une bibliothèque - alors pourquoi ne pas l'utiliser? Il y a bien d'autres exemples et je les accueillerais aussi bien - tant qu'il existe une norme convenue pour eux (comme un numéro de version).

— user1914292

27

Pourquoi jQuery mais pas Angular, MooTools, Underscore, ...? Et quelles versions de chacun? Les navigateurs doivent-ils contenir des copies de chaque bibliothèque JavaScript jamais créée?

— user253751

15

"Désolé, vous ne pouvez pas utiliser mon site Web avant d'avoir mis à niveau vers une version 0.1 supérieure de votre navigateur"

— VLAZ

4

Pertinent

— Charlie

4

la mise en cache est faite pour ça. sinon, la gestion des versions serait fondamentalement impossible

— njzk2

55

Si vous diffusez jQuery à partir d'un CDN populaire tel que les bibliothèques hébergées de Google ou cdnjs , il ne sera pas téléchargé à nouveau si votre visiteur a été sur un site qui l'a référencé à partir de la même source (tant que la version en cache n'a pas expiré).

jQuery est une bibliothèque populaire, comme vous le dites, mais il est peu probable qu'elle soit regroupée avec le navigateur pour plusieurs raisons:

jQuery est relativement petit (par rapport aux bibliothèques qui sont parfois regroupées dans des navigateurs, comme Flash). Les goulots d'étranglement les plus importants sur le site moyen ne sont probablement pas dus au téléchargement de jQuery.
Les améliorations apportées à JavaScript / ECMAScript signifient que les développeurs ne sont de plus en plus tenus de dépendre de jQuery. (Voir youmightnotneedjquery.com .)
Il existe de nombreuses autres bibliothèques JavaScript populaires. Les navigateurs ne sont pas conçus comme des référentiels pour le code JavaScript. Il peut être préférable de laisser aux développeurs Web de sites individuels le suivi de la popularité des scripts, de la suppression de bibliothèques moins populaires et de la mise à jour de tout.

— pseudo
source

Je comprends cela, mais j'utilise maintenant code.jquery.com comme CDN. Cependant, lorsqu'un autre site Web utilise googleapis ou cdjns, le navigateur téléchargera à nouveau jQuery à partir de cet autre CDN. Cela n'a tout simplement pas de sens et coûte beaucoup de temps / de bande passante partout. Si vous ajoutez à cela que dans la plupart des cas, les gens aimeraient quelque chose comme jQuery1.7 +, cela devient encore pire. Je comprends votre point de vue selon lequel les navigateurs ne sont pas des référentiels, mais ne pourrions-nous pas proposer une sorte de règle de «cache provenant de plusieurs sources»?

— user1914292

24

@ user1914292 Cela ne serait utile que si tous les navigateurs avaient toutes les versions de jQuery existantes, et s'il interceptait toutes les demandes vers une source connue de jQuery, en le remplaçant par la version mise en cache. S'il y a même une toute petite différence, cela pourrait provoquer des bogues impossibles à déboguer. Ceci est encore aggravé par le fait que la mise en cache Web fonctionne et fonctionne depuis des décennies. Votre navigateur n'est pas la seule chose qui met en cache ces requêtes jQuery - de nombreux routeurs sur le chemin de votre navigateur font de même. Le problème a été résolu il y a longtemps, lorsque la bande passante a affaire :)

— Luaan

4) Que se passe-t-il si le code jquery sur un site particulier dépend d'une fonction qui a été fondamentalement modifiée dans une mise à jour récente et ne fait plus ce que le code attend de lui?

— Shadur

1

@Ejay non, cela ne fonctionne pas comme un mécanisme de suivi, car 99% du temps, la demande est traitée à partir du cache de votre navigateur.

— suriv

1

@BenSteward Oui, utilisez les outils de développement de votre navigateur et vérifiez le panneau Réseau . Chrome, par exemple, affichera les ressources mises en cache avec «cache disque» ou «cache mémoire» dans la colonne «taille» et une valeur fantôme dans la colonne «état» (tant que vous n'avez pas «Désactiver le cache (tandis que DevTools est ouvert) "actif dans les paramètres des outils de développement). Cela peut dépendre des en-têtes de contrôle du cache et d'autres facteurs quant à ce qui est mis en cache et pendant combien de temps. developer.mozilla.org/en-US/docs/Web/HTTP/Caching

— Nick

21

Non seulement jQuery n'est pas la seule bibliothèque JS populaire, mais un navigateur devrait potentiellement inclure plusieurs versions. Le CDN de Google répertorie actuellement: 42 versions de jQuery; 44 versions de jQuery UI; 6 versions de jQuery Mobile.

Il est préférable de permettre aux développeurs Web de définir la version d'une bibliothèque à télécharger en fonction des exigences de leur site Web. Si vous utilisez une version de production actuelle de jQuery sur votre site Web et que vous la chargez à partir d'un CDN plus populaire, il y a de fortes chances que vos visiteurs l'aient déjà mis en cache de toute façon.

— Andrew Lott
source

14

Le navigateur est le moteur, il n'est pas du devoir du concepteur de moteur de savoir quel type de carburant et de pièces supplémentaires allez-vous mettre dans votre voiture et de l'inclure pour vous. S'ils le faisaient, les navigateurs seraient un énorme bloatware car la question suivante serait "pourquoi juste jQuery?", Et nous finirions par maintenir des référentiels de dépendances.

De plus, inclurons-nous toutes les versions? Que faire si quelqu'un souhaite utiliser une version personnalisée? Et si quelqu'un n'aimait pas utiliser cette bibliothèque? À quelle fréquence fusionneront-ils et déploieront-ils les dernières versions? Allons-nous nous retrouver avec différents navigateurs avec différentes jQuerys versionnées? Ils ne peuvent même pas implémenter également des fonctionnalités HTML, CSS et JavaScript standardisées. Que se passe-t-il si l'un des mainteneurs du navigateur n'inclut pas une bibliothèque ou sa version spécifique?

Les navigateurs fournissent des blocs de construction et un environnement pour vous permettre de créer une solution qui n'est pas déjà terminée.

Mettre jQuery dans le navigateur ne va pas rendre votre site incroyablement rapide car de nos jours ce n'est pas le plus gros goulot d'étranglement, mais nous pouvons convenir que jQuery est une bibliothèque inutilement grande mais son but n'était jamais d'être une bibliothèque rapide (compte tenu bande passante). Il existe de nombreuses autres bibliothèques spécialement conçues pour un chargement rapide et pour être légères comme Zepto .

Si vous êtes vraiment préoccupé par la taille et l'utilisation de la bande passante de jQuery, ne l'utilisez pas. Avez-vous déjà entendu parler de Vanilla JS ? C'est une bibliothèque encore plus populaire qui est utilisée littéralement par presque tout le monde, y compris jQuery lui-même! Et il a déjà réalisé votre rêve car il est inclus dans tous les navigateurs!

— totymedli
source

2

Une raison d'utiliser une bibliothèque comme jQuery est la compatibilité.

Les navigateurs sont devenus plus conformes aux normes, mais en utilisant la bibliothèque jquery, vous vous fournissez vous-même, vous n'avez pas à vous soucier des différences entre les familles de navigateurs et les versions

En fournissant vous-même le jquery, vous êtes sûr d'avoir une API cohérente.

Si nous avons le jquery intégré dans le navigateur, vous devez vérifier la version de l'utilisateur, et nous sommes de retour dans le navigateur et "Ce site est mieux visualisé en ..."

Donc, avoir la construction de jquery dans le navigateur n'a pas de sens.

De plus, la mise en cache fonctionne, donc même si l'utilisateur n'a pas déjà votre version jquery, elle ne doit être téléchargée qu'une seule fois.

— Lenne
source

-3

En fait, je pense que les répondants ici ne comprennent pas que la réponse à la question est que les navigateurs devraient probablement chercher à inclure les bibliothèques les plus utilisées, les polyfills, etc. du côté client.

Comme l'indique la personne qui pose la question, des commentaires conditionnels pourraient être utilisés pour garantir que ceux qui utilisent des navigateurs qui n'incluent pas jquery reçoivent une version appropriée.

Jquery inclut également sa propre prise en charge de la compatibilité descendante via migrate, permettant aux commentaires conditionnels de fournir une prise en charge rétroactive à une personne possédant une version packagée d'une ancienne bibliothèque jquery sans télécharger une toute nouvelle bibliothèque.

L'argument en faveur de leur inclusion dans les navigateurs ne concernerait pas seulement l'expérience utilisateur et les coûts, mais également la planète sur laquelle nous vivons. L'utilisation des données est une énorme contribution à la pollution mondiale, et garantir que le transfert inutile de données soit minimisé pourrait avoir un effet dramatique sur notre empreinte carbone.

Essentiellement pour l'ajout de quelques mégaoctets supplémentaires de code gonflé dans un navigateur intégré - les mêmes données sont transportées inutilement environ des milliards de fois par jour.

Cela aggrave l'expérience utilisateur pour tout le monde sur Internet. Et cela coûte énormément d'argent aux grandes entreprises.

En tant que développeur, vous devez simplement créer les solutions de secours nécessaires comme nous le faisons actuellement pour IE, etc., alors quel est le problème - il devrait probablement être inclus?

— Andy Bbop
source

1

C'est tangentiel à la question. La question est «pourquoi les navigateurs ne le font pas, et que puis-je faire à ce sujet», et non «pourquoi les navigateurs devraient-ils».

— Stephen Ostermiller

L'OP, tout en réfléchissant à votre point de vue, souhaite réduire le trafic vers le CDN si le cadre existe déjà dans le cache des navigateurs, peut-être même à partir d'un autre site. Personnellement, je ne vois pas comment, sauf s'il existe un moyen commun de référencer le cadre.

— closetnoc

La plupart des gens ont omis de dire également la réponse la plus pertinente à la question, à savoir que jQuery n'est pas une norme Web et que les navigateurs n'exécutent que des normes Web qui changent lentement et sont basées sur les fondamentaux. jQuery a été créé à l'origine pour que les principes fondamentaux fonctionnent de manière cohérente entre les navigateurs, donc l'inclusion de jQuery revient à inclure un correctif pour réparer les navigateurs, mais les navigateurs se corrigent déjà eux-mêmes. Nous constatons déjà que l'utilisation réduite de jQuery est en partie attestée par les nombreux articles "Vous n'avez pas besoin de jQuery" de nos jours.

— Rob

Stephen. La question n'est pas "pourquoi les navigateurs ne le font pas, et que puis-je faire à ce sujet". Voilà votre remaniement. La question est de savoir pourquoi ils ne le font pas, et la personne qui pose la question déclare clairement que le simple fait de le faire et de créer un nouveau cadre pour traiter les problèmes qui se posent aurait en fait un énorme avantage potentiel pour tous les utilisateurs du Web.

— Andy Bbop

Vous devez tous cesser de défendre vos idées préconçues dépassées et accepter que vous pouvez toujours tous apprendre. Oh, et apprenez aussi à lire quelque chose. #Armes. "L'OP, tout en réfléchissant à votre propos, souhaite réduire le trafic vers le CDN". Non, il dit que cela pourrait économiser énormément de bande passante, que ce soit côté client ou CDN. Lisez le billet effing.

— Andy Bbop