Cuando se trata de jQuery, muchas personas dicen: “Solo use JavaScript normal. No necesitas una biblioteca jQuery ". Que puedo decir No necesito muchas cosas, pero a pesar de esto, es bueno cuando lo son. Así es jQuery. No necesito esta biblioteca, pero definitivamente es bueno tenerla a mano.
Los sitios como
Es posible que no necesite jQuery (YMNJQ) están promoviendo la idea de que jQuery es muy fácil de eliminar. Pero el primer ejemplo en este sitio demuestra una buena razón para usar jQuery. ¡Allí, una simple línea de código jQuery se reemplaza por 10 líneas de JS regular!
La mayoría de las API de JavaScript, especialmente aquellas que se centran en trabajar con el DOM, ofenden mis sentidos estéticos. Esto es, por decirlo suavemente, mi actitud hacia ellos. Hablando directamente, creo que estas API son una pesadilla completa. Por ejemplo, la
el.insertAdjacentElement('afterend', other) ciertamente funciona. Pero mucho mejor se ve
$(el).after(other) . Aunque nunca me gustó realmente el aspecto de la función
$() , es incomparablemente mejor que lo que nos dan las API estándar para trabajar con el DOM. Sé que en lugar de
$() puedes usar algo como
jQuery(sel) o
window.jq = jQuery . Pero no programo en espacio sin aire. Por lo tanto, prefiero usar técnicas estándar. No sé si esto es bueno o malo, pero el estándar para usar jQuery es la construcción
$() .
Intente recordar rápidamente cómo obtener un elemento vecino de otro elemento utilizando el DOM. ¿Qué debo usar para esto:
nextSibling o
nextElementSibling ? Cual es la diferencia ¿Y qué navegadores admiten este o aquel método? Mientras intentas recordar esto y mirar el MDN, revisándote a ti mismo, usando jQuery, solo escribe
next() o
prev() .
Realizar muchas operaciones comunes implementadas en la API de JavaScript es inconveniente. Podría dar aquí una lista completa de tales operaciones, pero para mí se hizo perfectamente en la página YMNJQ.
Para resolver varios problemas simples usando herramientas JS, se necesitan funciones auxiliares. Y en el sitio web de YMNJQ, nuevamente, puede encontrar muchos ejemplos. Usar jQuery es una forma estándar de incluir tales funciones auxiliares en el código de su proyecto. Al mismo tiempo, el programador no necesita cada vez que necesita algo como esto para obtener fragmentos de código de las primeras respuestas a Stack Overflow que aparecieron en su brazo.
Aunque los problemas de compatibilidad del navegador han perdido su gravedad en estos días, siguen siendo relevantes. Especialmente: para aquellos que no pertenecen al grupo de desarrolladores que creen que si algo funciona en el 85% de los navegadores, entonces les conviene. Por cierto,
aquí está el material sobre por qué Hello CSS no utiliza variables CSS.
¿Debo usar siempre jQuery? No, claro que no. Cualquier dependencia adicional es un aumento en la complejidad del proyecto y un aumento en el volumen de su código. Pero jQuery no es una gran biblioteca. El ensamblaje estándar, minificado y comprimido, ocupa 30 Kb. El ensamblaje personalizado sin ajax y características poco utilizadas es de 23 Kb. Y el ensamblaje, que usa
querySelector lugar de
querySelector , ocupa solo 17 Kb. Para resolver muchos problemas, estoy bastante contento con el ensamblaje estándar de 30 Kb y el ensamblaje optimizado de 17 Kb.
Aquí puede ver cuánto esfuerzo se ha puesto en eliminar jQuery de Bootstrap y cambiar a JS normal.
Los desarrolladores han escrito sus propias funciones auxiliares. Tuvieron que abandonar el soporte de IE, ya que dicho soporte era muy difícil de implementar. Hicieron la API incompatible ("rompimos todo") y pasaron un año y medio en todo esto. No puedo decir que lo que pasó es mucho mejor que lo que pasó.
Entiendo las razones para traducir Bootstrap a JS regular. Por ejemplo, los desarrolladores quieren usar Bootstrap con Vue.js, o algo similar. Y Vue.js y jQuery en un proyecto ya son un poco fallidos. Soy un gran defensor de reducir la cantidad de código innecesario en la web (y
aquí hay un par de materiales sobre esto). Pero aquí propongo mirar la situación desde un punto de vista pragmático y realista. ¿Es la inclusión del código jQuery de 17 KB en Bootstrap? ¿Es tan malo? Cuando digo que para ver sitios como Medium o New York Times necesita descargar más de un megabyte de código JavaScript, para proteger esta situación, me preguntan si estoy sentado en una línea de módem de 56 kilobits. Megabyte JS está bien. ¿Es 17Kb jQuery realmente pesado?
Hay buenas razones para no usar jQuery. Por ejemplo, jQuery no es necesario si está escribiendo código que desea compartir con otros, o si está creando alguna función pequeña. Pero, ¿por qué darse la vuelta para no usar jQuery? ¿Por qué todo este esfuerzo si solo puedes escribir
$() ? No creo que jQuery deba usarse en todas partes y siempre, pero no creo que el rechazo fanático de jQuery sea correcto.
Quiero señalar que no estoy casado con jQuery. Estaré encantado de usar algo como "jQuery light", un tipo de biblioteca que cubre las deficiencias de las API estándar, lo que le da al programador algo más agradable. El sitio YMNJQ recomienda, entre otros, las bibliotecas
bonzo y
$ dom , diseñadas para resolver varios problemas. Pero muchos de ellos, como parece, no han sido apoyados por mucho tiempo. Además, muchos ya conocen jQuery. ¿Por qué cambiar jQuery por otra cosa sin una buena razón?
Muchos lectores pueden preguntarse qué puedo decir yo, en el contexto de este material, sobre Vue.js, React y otros marcos modernos. Pero el objetivo de este artículo es mapear JavaScript y jQuery, en lugar de ofrecer a la comunidad una "Grandiosa teoría general de desarrollo frontend".
Dado lo anterior, creo que puedo encontrar muy pocas razones para usar JS regular donde puede usar jQuery. Esto se debe principalmente al hecho de que quiero crear páginas rápidas y usar las construcciones de trabajo más simples. Al mismo tiempo, me esfuerzo por asegurar que la mayor cantidad posible de usuarios de la Web puedan ver mis páginas. La experiencia me dice que la forma más corta de lograr este objetivo son las plantillas generadas en el servidor, que están ligeramente sazonadas con JavaScript al estilo de "mejora progresiva". Si compara tales proyectos con algo que usa algo más complejo, resulta que a menudo son más fáciles de desarrollar. Tales proyectos suelen ser más rápidos, generalmente tienen menos errores y, mientras trabajan en ellos, el ventilador de la computadora portátil no hace ruido que pueda despertar a toda la casa.
¿Esto significa que los marcos web modernos y las bibliotecas potentes son siempre malos? No, no lo hace. Muy poco es digno de ser siempre llamado malo o bueno. Pero usar el marco significa hacer algunos compromisos (esto, por supuesto, es cierto para jQuery).
En general, veo la web como un entorno para ver documentos, y no como un sistema operativo. Y el "enfoque de documentos" es bueno no solo para sitios regulares, sino también para muchas "aplicaciones web" (como se llame).
Estimados lectores! ¿Usas jQuery?
