Ventajas de usar JavaScript puro sobre JQuery

¿Cuáles son las ventajas de usar solo Javascript versus usar solo JQuery?

Tengo experiencia limitada con la codificación JavaScript y JQuery. He agregado bits y fragmentos de cada uno a las páginas HTML, pero en su mayoría he codificado cosas del lado del servidor en otros idiomas. Me di cuenta de que, si bien teóricamente puedes hacer las mismas cosas usando cualquiera de los dos enfoques (y, por supuesto, incluso puedes mezclarlos en el mismo proyecto), parece haber una tendencia a comenzar a usar JQuery desde el principio no importa cuáles sean las demandas del proyecto.

Entonces, simplemente me pregunto, ¿hay algún beneficio puntual para no usar solo JQuery sino simplemente usar JavaScript antiguo?

Sé que esto parece no ser una pregunta porque se puede decir al respecto que "no hay una respuesta definitiva" o "se puede debatir para siempre", pero en realidad espero respuestas puntuales como "Puedes hacer esto en un enfoque y no puedes hacerlo con el otro ".

Según el comentario de scrwtp, no me refiero solo a la parte de manejo de DOM. Mi pregunta es más bien: JQuery es una biblioteca. Para Javascript Lo que me parece extraño de esta biblioteca en comparación con otras bibliotecas para otros idiomas es que, en el caso de JQyery, parece estar diseñada para poder usarla exclusivamente y no tener que tocar Javascript directamente. Esto es opuesto a, digamos, Hibernate y SQL, donde aunque la biblioteca (o más bien el marco en este caso, pero creo que la analogía aún se aplica) toma el control de MUCHOS aspectos, aún puedes usar SQL cuando lo usas , al menos para algunos casos marginales. Sin embargo, en el caso de JQuery y Javascript, puede hacer cualquier cosa que haga con Javascript usando solo JQuery (o al menos así me parece).

Según el comentario de Stargazer712: sí, estoy de acuerdo con usted, la pregunta aquí es, como usted lo expresa "solo es cuestión de cómo utilizará JavaScript". Eso es lo que realmente estaba ansioso por preguntar, pero hice algunas formulaciones malas. Aquí hay otra analogía: Spring Expression Language. Es una biblioteca de Java. No puede usarlo sin Java, está basado en Java y, a pesar de todo, aún puede usar Java. Pero en la práctica, lo que puede hacer es agregar esta biblioteca a un proyecto de Java, y luego escribir todo su código utilizando el lenguaje de expresión de Spring EL que efectivamente hace que su código no se parezca a Java en absoluto, e incluso es un cambio de paradigma (por ejemplo, ya no tiene aplicación de tipo fuerte cuando se usa esto). Si bien entiendo que JQuery es solo una biblioteca JS, para mí parece que en la práctica tiene el mismo efecto que Spring EL tiene con Java, es decir, solo puede usar sus API a través de un proyecto y evitar las API de JavaScript. Y me preguntaba si eso es algo bueno que hacer, cuáles podrían ser las trampas, etc.

(y sí, después de leer las respuestas de todos, entiendo que:

a. mi pregunta es algo no sensible hasta cierto punto

si. incluso si la pregunta fuera completamente precisa, la respuesta sería "no, no puedes usar JQuery solo todo el tiempo)

En primer lugar, es imposible usar jQuery solo, todo lo que jQuery hace es agregar un objeto $ a su alcance global, con un montón de métodos. Incluso las bibliotecas más manipuladoras como prototipos no son una alternativa a JavaScript, son un cinturón de herramientas para resolver problemas comunes.

Las principales ventajas de agregar jQuery a su cinturón de herramientas serían:

• compatibilidad del navegador: hacer algo como .attr () es mucho más fácil que las alternativas nativas y no se romperá en todos los navegadores.
• simplificación de operaciones usualmente complicadas: si desea ver una versión compatible con varios navegadores bien escrita de un método XHR, eche un vistazo a la fuente de $ .ajax; para este método solo vale la pena la sobrecarga de jQ.
• Selección de DOM: cosas simples como enlazar eventos y seleccionar elementos de DOM pueden ser complicadas y diferentes según el navegador. Sin mucho conocimiento, también se pueden escribir fácilmente mal y ralentizar su página.
• Acceso a funciones futuras: cosas como .indexOf y .bind son JavaScript nativo, pero aún no son compatibles con muchos navegadores. Sin embargo, el uso de las versiones jQuery de estos métodos le permitirá admitirlos en varios navegadores.

Javascript ya no es solo un lenguaje del lado del cliente, y debido a que jQuery es tan dependiente del DOM, es un candidato terrible para pasar al servidor. Recomiendo encarecidamente dedicar un tiempo a comprender por qué está utilizando jQuery (¡hacer esta pregunta es un gran primer paso!) Y evaluar cuándo es necesario. jQuery puede ser peligroso, algunos de los principales peligros son:

• calidad del código: jQuery tiene una gran comunidad y una curva de aprendizaje baja. Esta es una tormenta perfecta para muchos complementos de código abierto mal escritos.
• ineficiencia: jQuery es fácil de escribir de manera ineficiente. Por ejemplo, usar jQuery's each en lugar de for loops es innecesario y podría tener un impacto en el rendimiento en algunos casos. Mucha información sobre estas cosas en JSPerf
• bloat - jQuery es una gran biblioteca. La mayor parte del tiempo, usará un pequeño subconjunto de sus características y tomará toda la biblioteca. Existen algunas excelentes alternativas que le proporcionarán subconjuntos de funciones, como zepto.js y underscore.js; según su situación, puede guardar algunos bytes eligiendo la biblioteca adecuada para sus necesidades.

En última instancia, jQuery es una biblioteca increíblemente útil y útil, cuando se usa correctamente. Sin embargo, es no una alternativa a JavaScript. Es una biblioteca, al igual que zepto.js , YUI , Dojo , MooTools y Prototype , una de las cuales puede ser una opción mucho mejor para su proyecto actual.

Javascript es un lenguaje incomprendido, y la mayoría de la gente lo ha considerado recientemente como algo más que un lenguaje de script. Realmente recomiendo leer más sobre esto, aquí hay algunos buenos lugares para comenzar:

Edición 07/2014 - Noté que esta publicación todavía está recibiendo atención, así que agregué un montón de enlaces. Estos no están en un orden particular, pero deberían ser útiles.

• Blog de Ben Alman : muchas buenas prácticas recomendadas aquí. No estoy de acuerdo con todos ellos, pero aprendo cosas nuevas de su blog todo el tiempo.
• Code Academy : capacitación básica en JavaScript y jQuery. A veces, volver a lo básico ayuda.
• Javascript Garden : una publicación sobre las características más difíciles o malentendidas de javascript. Por favor, lea este de vez en cuando, hasta que todo tiene sentido.
• Bocoup : estas son clases de entrenamiento. Si estás cerca de uno, ve a él. Muchos de los mejores oradores y maestros de JS enseñan esto.
• Blog de Paul Irish : no estrictamente JS, pero aquí se escriben muchas buenas prácticas. Los feeds de Twitter de él y Ben son excelentes para seguir.
• Javascript: The Good Parts - a menudo referido como 'La Biblia Javascript', este libro de Douglas Crockford es un lugar increíble para comenzar a entender javascript.
• Blog de Isaac Schlueter : Isaac es el creador de npm y trabaja en el núcleo del nodo. Él escribe mucho sobre la comunidad de JavaScript en lugar de sobre las convenciones de código, pero si realmente está entrando en js, es una gran lectura.
• Javascript de Douglas Crockford : si Brendan Eich es el padre de JavaScript, Douglas es el tío abierto de JavaScript. Es el autor de la especificación JSON, la biblia javascript y muchas publicaciones increíbles sobre las peculiaridades y el ascenso meteórico de javascript.
• Blog de Brendan Eich - Brendan es el creador de javascript - escribe sobre todo tipo de cosas tontas en su blog, y aunque tiene sus fallas como persona, sus publicaciones en javascript son valiosas.
• Blog de James Halliday (@substack) : se puede decir que Substack es el desarrollador de node.js más importante de la comunidad, con alrededor de 400 (y creciendo cada día) módulos npm y una filosofía guía de módulos pequeños, similares a Unix, todo lo que escribe vale la pena leyendo.
• Blog de Max Ogden Max Ogden es otro autor prolífico de node.js, y es excelente para escribir publicaciones de blog que le enseñan algo. También es el autor (con otros, creo) de javascript para gatos.
• Javascript para gatos : este es un breve tutorial que lo lleva a través de los conceptos básicos de JavaScript desde la perspectiva de un gato. Si eres un principiante, lee esto. Es divertido y enseña en una hora lo que muchos libros tardan semanas en comunicarse.
• Blog de Nicholas Zakas Nicholas es autor de algunos fantásticos libros de JavaScript: programación orientada a objetos en Javascript , Javascript mantenible , Javascript profesional para desarrolladores web y Javascript de alto rendimiento . Se centra principalmente en el cliente, pero tiene un montón de mejores prácticas y consejos de rendimiento.
• Blog de Guillermo Rauch : Guillermo es otro desarrollador prolífico de node.js, sobre todo famoso por Socket.io y Mongoose. Su blog (y su nuevo libro, Smashing Node.js son recursos excelentes.

Estoy seguro de que hay muchos más recursos excelentes en los que no estoy pensando o que no conozco, otros respondedores deberían sentirse libres de agregar a esa lista.

Hay ventajas, pero es discutible si realmente superan los inconvenientes.

La principal es que ahorras ancho de banda y obtienes respuestas más rápidas. jQuery agrega otros ~ 30kb a su respuesta. En algunas redes (y en algunos países), eso podría significar unos pocos milisegundos más. Por otro lado, sin embargo, puede configurar el almacenamiento en caché con bastante facilidad utilizando su servidor web (o, como dijo Xion, utilícelo desde el sitio de Google para que no afecte al suyo y aún se almacene en caché).

Lo segundo es que es posible que solo necesite una funcionalidad muy simple, y solo descargar y configurar jQuery podría llevar más tiempo que simplemente implementar lo que necesita.

Y, por último, es posible que desee implementar su propio marco, que es una mala idea, pero algunas personas tienen sus razones.

Sin embargo, si descarta jQuery simplemente porque se siente intimidado por la curva de aprendizaje, debe reconsiderarlo. Sobre todo porque es bastante gentil.

Hasta donde sé, en realidad solo hay dos ventajas de usar JavaScript vainilla frente a una biblioteca como JQuery , MooTools , etc.

• Las bibliotecas tienen una carga útil que consume ancho de banda. Pero como la gente ya ha señalado en las otras respuestas, puede limitar esto con gzipping y almacenamiento en caché. Si solo desea un subconjunto de jQuery, puede hacerlo con SizzleJS y con MooTools tiene la opción de seleccionar los conjuntos de características que desea de la misma manera que lo hace Modernizr .
• Las bibliotecas son grandes y toma algo de tiempo aprender. Por otra parte, esta es una inversión única para los desarrolladores ... y se ve bien en su currículum para conocer las bibliotecas de JavaScript.
• (BONIFICACIÓN) Las bibliotecas no son una bala de plata, por lo que si desea reinventar la rueda, definitivamente esta es la mejor opción.

Vale la pena señalar por qué desea utilizar una biblioteca javascript, para lo cual hay muchos:

• No necesita escribir su propio marco para apoyar su desarrollo. Si tiene curiosidad por cómo funcionan las cosas, puede consultar el código ya que es de código abierto.
• Las bibliotecas resuelven la compatibilidad del navegador. Tanto DOM como JavaScript tienen algunas diferencias entre los navegadores. Confía en mí, este es un gran sumidero de tiempo si tienes que hackear soluciones tú mismo.
• Es un estándar de facto de Internet usar bibliotecas javascript, la mayoría de ellas están bien documentadas por ahora y la mayoría de los desarrolladores web (que conocen javascript) saben cómo usarlas.
• Realmente no abandonas JavaScript cuando usas una biblioteca. Aún necesita saber Javascript con sus tipos, objetos, cómo funcionan los cierres , etc.
• La mayoría de las bibliotecas están modularizadas y no lleva mucho tiempo escribir complementos o usar require y el patrón AMD .
• CSS seleccionar elementos del DOM es una gran ayuda.
• (BONIFICACIÓN) También puede usarlos con CoffeeScript .

Solía ​​trabajar en una tienda web que insistía en usar JavaScript vainilla porque jQuery era grande y aterrador. Esta decisión, influenciada principalmente por un "desarrollador de JavaScript" solitario, fue la fuente de muchos errores del navegador y un desarrollo lento, y tratar de ingresar a su base de código fue una experiencia desgarradora. Escribir su propio marco puede parecer una buena idea, pero si desea contratar nuevos desarrolladores, entonces no pueden entrar rápidamente y ayudar. Luego también está la cuestión del factor del autobús a considerar.

Como dije, solía trabajar allí ... había pastos más verdes en otros lugares. : ^)

Por casualidad mezclo bastante el uso de ambos. La razón más importante de esto es que para algunas aplicaciones (piense en las extensiones de Chrome) no necesita compatibilidad con varios navegadores. Lo que significa que puedo aprovechar los nuevos avances como css3 que con cosas como las transiciones pueden simplificar mucho su código sobre el uso de jquery.

Además, a menudo estoy haciendo algo personalizado. Por supuesto, como dijeron los demás, no debes reinventar la rueda. Pero cuando me piden que haga una funcionalidad loca, a menudo me resulta mucho más fácil escribirlo yo mismo que intentar hackear un complemento jquery que está cerca pero no es una combinación perfecta.

También he trabajado con desarrolladores que trabajan con nada más que jquery. Y tengo que decir que comprometieron la funcionalidad con mucha más frecuencia que si no pudieran encontrar un complemento jquery que hiciera lo que querían.

En algún momento del desarrollo web, se le pedirá que haga algo que no esté preempaquetado en una biblioteca. Entonces, en ese punto, es mejor que se asegure de comprender cómo funciona realmente el lenguaje base.

Entonces, TLDC : usa ambos, estás en desventaja usando solo vainilla y estás en desventaja si no conoces vainilla por dentro y por fuera e insistes en usar siempre jquery.

Lo único que se me ocurre que no puedes hacer sin JQuery sería usar los complementos de JQuery; incluso entonces, podría escribir su propia biblioteca JS que proporcionaría justo lo que necesita el complemento.

Piénselo así: JQuery es una biblioteca Javascript de código abierto escrita en Javascript; puede mirar la fuente y, por lo tanto, aprender a hacer todo lo que hace.

No puede usar JQuery sin usar Javascript antiguo simple. Probablemente no usará document.getElementById, pero seguirá definiendo funciones y variables en las formas estándar de Javascript; incluso podrías escribir un forbucle estándar .

El principal beneficio de usar JQuery es prácticamente el mismo que cualquier otra biblioteca de terceros en cualquier idioma: no tendrá que escribir tanto código para implementar la lógica específica de su aplicación.

No dejes que el tamaño te asuste. La versión de CDN es una descarga de ~ 33k que será almacenada en caché por el navegador del usuario después de la primera página.

Si le preocupa el rendimiento, debe intentar usar vanilla js siempre que sea posible. Los frameworks no solo agregan sobrecarga de ancho de banda sino también sobrecarga de procesamiento. Y jQuery también viene con compatibilidad de navegador para navegadores bastante antiguos.

Si está trabajando en aplicaciones móviles o juegos (o ambos combinados), primero necesita rendimiento y eficiencia de recursos.

jQuery y los complementos pueden acelerar su desarrollo, pero especialmente si confía en complementos de jquery de terceros, debe saber qué están haciendo en su interior. Muchos de ellos son malos ejemplos de la calidad y eficiencia del código.

jQuery puede ser de 2 a 10 veces más lento que el JavaScript nativo. Y puede alentar fácilmente a los desarrolladores a no diseñar adecuadamente su interfaz y confiar demasiado en los selectores jQuery, que son mucho más lentos que los nativos.