¿Por qué los navegadores no tienen instalado jQuery?

19

Estoy usando jQuery en varios de mis sitios web y aunque uso un CDN para servirlo, simplemente no tiene sentido que el visitante descargue jQuery cada vez. jQuery debe ser el marco de JavaScript más utilizado en el mundo, ¿no tendría más sentido si los navegadores solo lo tienen instalado de forma predeterminada?

De esa forma, millones de veces al día se podría evitar una descarga de jQuery. Ya sea desde los propios sitios web de las personas o desde los CDN.

Todo lo que realmente se necesitaría es algún tipo de afirmación como:

 <!--[if jQuery gt 11]>

¿Existe algo que me ayudará a evitar que los usuarios hagan el viaje a la CDN si ya tienen jQuery en su caché desde otro sitio?

cache browsers jquery

— usuario1914292
fuente

3

la pregunta es: ¿por qué un usuario necesita hacer nuevas descargas de sitios o CDN para algo que ya tiene? jQuery se sirve desde muchas ubicaciones y en muchas versiones. Estoy preocupado por la velocidad de la página y los usuarios están preocupados por el ancho de banda (especialmente móvil). Si hay un estándar de oro para una biblioteca, ¿por qué no usarlo? Hay otros ejemplos seguros y también los agradecería, siempre y cuando haya un estándar acordado para ellos (como un número de versión).

— user1914292

27

¿Por qué jQuery pero no Angular, MooTools, Underscore, ...? ¿Y qué versiones de cada uno? ¿Deben los navegadores contener copias de cada biblioteca de JavaScript que se haya creado?

— user253751

15

"Lo siento, no puedes usar mi sitio web hasta que actualices a una versión 0.1 de tu navegador"

— VLAZ

44

Relevante

— Charlie

44

el almacenamiento en caché está hecho para eso. de lo contrario, el manejo de la versión sería básicamente imposible

— njzk2

55

Si sirve jQuery desde un CDN popular como las Bibliotecas Hospedadas de Google o cdnjs , no se volverá a descargar si su visitante ha estado en un sitio que hace referencia a él desde la misma fuente (siempre que la versión en caché no haya caducado).

jQuery es una biblioteca popular, tal como usted dice, pero no es probable que lo incluya en el navegador por varias razones:

jQuery es relativamente pequeño (en comparación con las bibliotecas que a veces se incluyen en los navegadores, como Flash). Es poco probable que los mayores cuellos de botella de rendimiento en el sitio promedio se deban a la descarga de jQuery.
Las mejoras en JavaScript / ECMAScript significan que cada vez más los desarrolladores no están obligados a depender de jQuery. (Ver youmightnotneedjquery.com .)
Hay muchas otras bibliotecas JavaScript populares. Los navegadores no están diseñados como repositorios para el código JavaScript. El seguimiento de la popularidad de los scripts, la eliminación de bibliotecas menos populares y el mantenimiento de todo actualizado pueden dejarse en manos de los desarrolladores web de sitios individuales.

— Mella
fuente

Entiendo esto, pero ahora estoy usando code.jquery.com como CDN. Sin embargo, cuando otro sitio web utiliza googleapis o cdjns, el navegador DE NUEVO descargará jQuery de ese otro CDN. Eso simplemente no tiene sentido y cuesta mucho tiempo / ancho de banda en todo el lugar. Si agrega a esto que en la mayoría de los casos a la gente le gustaría algo como jQuery1.7 +, entonces se pone aún peor. Entiendo su punto de vista acerca de que los navegadores no son repositorios, pero ¿no podríamos encontrar algún tipo de regla de 'caché de múltiples fuentes'?

— user1914292

24

@ user1914292 Esto solo sería útil si todos los navegadores tuvieran todas las versiones de jQuery, y si interceptara cualquier solicitud a cualquier fuente conocida de jQuery, reemplazándola por la versión en caché. Si incluso hay una pequeña diferencia, puede causar errores que son imposibles de depurar. Esto se ve agravado por el hecho de que el almacenamiento en caché web funciona , y ha funcionado durante décadas. Su navegador no es lo único que almacena en caché esas solicitudes de jQuery: muchos de los enrutadores en el camino hacia su navegador hacen lo mismo. El problema ha sido resuelto hace mucho tiempo, cuando el ancho de banda hizo importa :)

— Luaan

4) ¿Qué sucede si el código jquery en un sitio en particular depende de una función que ha sido alterada fundamentalmente en una actualización reciente y ya no hace lo que el código espera que haga?

— Shadur

1

@Ejay no, no funciona como mecanismo de seguimiento porque el 99% del tiempo la solicitud se atiende desde la memoria caché de su navegador.

— suriv

1

@BenSteward Sí, use las herramientas de desarrollo de su navegador y verifique el panel Red . Chrome, por ejemplo, mostrará recursos en caché con "caché de disco" o "caché de memoria" en la columna "tamaño" y un valor fantasma en la columna "estado" (siempre que no tenga "Desactivar caché (mientras DevTools está abierto) "activo en la configuración de las herramientas de desarrollo). Puede depender de los encabezados de control de caché y otros factores en cuanto a qué se almacena en caché y por cuánto tiempo. developer.mozilla.org/en-US/docs/Web/HTTP/Caching

— Nick

21

JQuery no solo no es la única biblioteca JS popular, sino que un navegador tendría que incluir múltiples versiones. El CDN de Google actualmente enumera: 42 versiones de jQuery; 44 versiones de jQuery UI; 6 versiones de jQuery Mobile.

Es mejor permitir que los desarrolladores web definan qué versión de una biblioteca descargar en función de los requisitos de su sitio web. Si usa una versión actual de producción de jQuery en su sitio web y la carga desde un CDN más popular, entonces hay una buena posibilidad de que sus visitantes ya la tengan en caché de todos modos.

— Andrew Lott
fuente

14

El navegador es el motor, no es el deber del diseñador del motor averiguar qué tipo de combustible y piezas adicionales va a poner en su automóvil e incluirlo por usted. Si hicieran esto, los navegadores serían un gran bloatware porque la siguiente pregunta sería "¿por qué solo jQuery?", Y terminaríamos manteniendo depósitos de dependencia.

Además, ¿incluiremos todas las versiones? ¿Qué pasa si alguien quisiera usar una versión personalizada? ¿Qué pasa si a alguien no le gustaría usar esa biblioteca? ¿Con qué frecuencia fusionarán y lanzarán los últimos lanzamientos? ¿Terminaremos con diferentes navegadores con diferentes versiones de jQuerys? Ni siquiera pueden implementar funcionalidades estandarizadas de HTML, CSS y JavaScript. ¿Qué sucede si uno de los mantenedores del navegador no va a incluir una biblioteca o su versión específica?

Los navegadores proporcionan bloques de construcción y un entorno para que usted cree una solución que no esté terminada.

Poner jQuery en el navegador no hará que su sitio se cargue a toda velocidad porque hoy en día este no es el mayor cuello de botella, sin embargo, podemos estar de acuerdo en que jQuery es una biblioteca innecesariamente grande, pero su propósito nunca fue ser una biblioteca rápida (considerando banda ancha). Hay muchas otras bibliotecas que fueron diseñadas específicamente para la carga rápida y para ser livianas como Zepto .

Si realmente le preocupa el tamaño de jQuery y el uso de ancho de banda, entonces no lo use. ¿Alguna vez has oído hablar de Vanilla JS ? ¡Es una biblioteca aún más popular que es utilizada literalmente por casi todo el mundo, incluido jQuery! ¡Y ya cumplió su sueño porque está incluido en todos los navegadores!

— totymedli
fuente

2

Una razón para usar una biblioteca como jQuery es la compatibilidad.

Los navegadores se han vuelto más compatibles con los estándares, pero al usar la biblioteca jquery, usted se suministra a sí mismo, no tiene que preocuparse por las diferencias entre las familias y las versiones del navegador

Al suministrar el jquery usted mismo, está seguro de tener una API constante.

Si tenemos el jquery integrado en el navegador, debe verificar qué versión tiene el usuario, y volveremos al examen del navegador y "Este sitio se ve mejor en ..."

Por lo tanto, tener la compilación jquery en el navegador no tiene sentido.

Además, el almacenamiento en caché funciona, por lo que incluso si el usuario aún no tiene su versión jquery, solo necesita descargarse una vez.

— Lenne
fuente

-3

De hecho, creo que los que responden aquí no entienden que la respuesta a la pregunta es que los navegadores probablemente deberían incluir las bibliotecas más utilizadas, los polyfills, etc. en el lado del cliente.

Como dice la persona que hace la pregunta, los comentarios condicionales podrían usarse para garantizar que aquellos que usan navegadores que no incluyen jquery reciban una versión adecuada.

Jquery también incluye su propio soporte de compatibilidad con versiones anteriores a través de la migración, lo que permite comentarios condicionales para dar soporte retro a alguien con una versión empaquetada de una biblioteca jquery anterior sin descargar una biblioteca completamente nueva.

El argumento a favor de incluirlos en los navegadores no se trataría solo de la experiencia y el costo del usuario, sino también del planeta en el que vivimos. El uso de datos es una gran contribución a la contaminación global, y garantizar que se minimice la transferencia innecesaria de datos podría tener un efecto dramático en nuestra huella de carbono.

En esencia, en aras de agregar unos pocos megabytes adicionales de relleno de código en un navegador empaquetado: los mismos datos se transfieren innecesariamente miles de millones de veces al día.

Eso empeora la experiencia del usuario para todos en Internet. Y cuesta a las grandes empresas grandes cantidades de dinero.

Como desarrollador, solo crearía los retrocesos necesarios como lo hacemos actualmente para IE, etc., entonces, ¿cuál es el problema? ¿Probablemente debería incluirse seguramente?

— Andy Bbop
fuente

1

Esto es tangencial a la pregunta. La pregunta es "por qué no navegadores, y qué puedo hacer al respecto", no "por qué deberían los navegadores".

— Stephen Ostermiller

El OP, mientras reflexiona sobre su punto, está interesado en reducir el tráfico a la CDN si el marco ya existe dentro de la memoria caché del navegador, posiblemente incluso desde otro sitio. Personalmente, no puedo ver cómo a menos que haya una forma común de hacer referencia al marco.

— closetnoc

La mayoría de las personas no han podido decir también la respuesta más relevante a la pregunta y es que jQuery no es un estándar web y los navegadores solo ejecutan estándares web que cambian lentamente y se basan en fundamentos. jQuery se creó originalmente para hacer que los fundamentos funcionen de manera coherente entre los navegadores, por lo que incluir jQuery es como incluir un parche para reparar los navegadores, pero los navegadores ya se arreglan ellos mismos eventualmente. Ya vemos el uso disminuido de jQuery como lo demuestran en parte los numerosos artículos de "No necesitas jQuery" en la actualidad.

— Rob

Stephen La pregunta no es "por qué no navegadores, y qué puedo hacer al respecto". Esa es tu repetición. La pregunta es por qué no lo hacen, y la persona que pregunta claramente afirma que simplemente hacer esto y crear un nuevo marco para tratar los problemas que surjan en realidad tendría un enorme beneficio potencial para todos los usuarios de la web.

— Andy Bbop el

Todos deben dejar de defender sus ideas preconcebidas pasadas de moda y aceptar que todavía pueden aprender. Ah, y también aprender a leer algo realmente. # Armas. "El OP, mientras reflexiona sobre su punto, está interesado en reducir el tráfico a la CDN". No, dice que podría ahorrar enormes cantidades de ancho de banda, ya sea en el lado del cliente o CDN. Lee el post de efing.

— Andy Bbop el