react - ¿Cuándo usar Vanilla JavaScript vs. jQuery?

vanilla js vs react

Question

He notado que, al monitorear / intentar responder preguntas comunes de jQuery, existen ciertas prácticas que usan javascript, en lugar de jQuery, que en realidad le permiten escribir menos y hacer ... bueno, la misma cantidad. Y también puede dar beneficios de rendimiento.

Un ejemplo especifico

$(this) vs this

Dentro de un evento de clic que hace referencia a la identificación de los objetos seleccionados.

jQuery

$(this).attr("id");

Javascript

this.id;

¿Hay otras prácticas comunes como esta? Donde ciertas operaciones de Javascript se podrían lograr más fácilmente, sin traer jQuery a la mezcla. ¿O es un caso raro? (de un "atajo" de jQuery que realmente requiere más código)

EDITAR: Aunque aprecio las respuestas con respecto a jQuery en comparación con el rendimiento de JavaScript simple, en realidad estoy buscando respuestas mucho más cuantitativas. Al usar jQuery , las instancias en las que uno realmente estaría mejor (legibilidad / compacidad) usar un Javascript simple en lugar de usar $() . Además del ejemplo que di en mi pregunta original.

Answer 1

Aquí hay una respuesta no técnica: muchos trabajos pueden no permitir ciertas bibliotecas, como jQuery.

De hecho, Google no permite jQuery en ninguno de sus códigos (ni Reacciona, porque es propiedad de Facebook), lo que tal vez no sabías hasta que el entrevistador dice "Lo siento, pero no puedes usar jQuery, no está en la lista aprobada en XYZ Corporation ". Vanilla JavaScript funciona absolutamente en todas partes, siempre, y nunca te dará este problema. Si confías en una biblioteca, sí obtienes velocidad y facilidad, pero pierdes la universalidad.

Además, hablando de entrevistas, el otro inconveniente es que si dice que necesita usar una biblioteca para resolver un problema de JavaScript durante una prueba de código, aparece como si realmente no entendiera el problema, lo que parece bastante malo. Mientras que si lo resuelves en JavaScript de vainilla sin procesar, eso demuestra que realmente entiendes y puedes resolver cada parte de cualquier problema que se te presente.

Answer 2

Como de costumbre voy tarde a esta fiesta.

No fue la funcionalidad adicional lo que me hizo decidir usar jQuery, por más atractivo que fuera. Después de todo, nada te impide escribir tus propias funciones.

Era el hecho de que había muchos trucos que aprender al modificar el DOM para evitar pérdidas de memoria (estoy hablando de tu IE). Para tener un recurso central que gestionaba todo ese tipo de problemas para mí, escrito por personas que eran mucho mejores codificadores JS de lo que yo nunca lo sería, ese fue revisado, revisado y probado continuamente, fue Dios God.

Supongo que este tipo de caer en el soporte de navegador cruzado / argumento de abstracción.

Y, por supuesto, jQuery no impide el uso de JS directo cuando lo necesita. Siempre sentí que los dos parecían trabajar juntos a la perfección.

Por supuesto, si su navegador no es compatible con jQuery o si está soportando un entorno de gama baja (¿un teléfono más antiguo?), Entonces un archivo .js grande puede ser un problema. ¿Recuerdas cuando jQuery solía ser pequeña?

Pero normalmente la diferencia de rendimiento no es un tema de preocupación. Solo tiene que ser lo suficientemente rápido. Con los ciclos de Gigahertz de la CPU que se desperdician cada segundo, me preocupa más el rendimiento de mis codificadores, los únicos recursos de desarrollo que no duplican la potencia cada 18 meses.

Dicho esto, actualmente estoy buscando problemas de accesibilidad y, aparentemente, .innerHTML es un poco de no, no con eso. jQuery, por supuesto, depende de .innerHTML, por lo que ahora estoy buscando un marco que dependa de los métodos algo tediosos que se permiten. Y puedo imaginar que un marco de este tipo se ejecutará más lento que jQuery, pero siempre que funcione lo suficientemente bien, seré feliz.

Answer 3

Cuando:

1. usted sabe que existe un soporte de navegador cruzado para lo que está haciendo, y
2. no es significativamente más código para escribir, y
3. no es significativamente menos legible, y
4. estás razonablemente seguro de que jQuery no elegirá diferentes implementaciones basadas en el navegador para lograr un mejor rendimiento, entonces:

utilizar JavaScript. De lo contrario usa jQuery (si puedes).

Edición : esta respuesta se aplica tanto al elegir usar jQuery global como a omitirla, así como a la elección de usar vanilla JS dentro de jQuery. La elección entre attr(''id'') y .id inclina a favor de JS, mientras que se elige entre removeClass(''foo'') versus .className = .className.replace( new Regexp("(?:^|//s+)"+foo+"(?://s+|$)",''g''), '''' ) inclina a favor de jQuery.

Answer 4

Este es mi punto de vista personal, pero como jQuery es JavaScript de todos modos, creo que, en teoría, no puede funcionar mejor que el JS de vainilla.

Pero en la práctica puede funcionar mejor que el JS escrito a mano, ya que el código escrito a mano puede no ser tan eficiente como jQuery.

En pocas palabras: para cosas más pequeñas, tiendo a usar vainilla JS, para proyectos intensivos en JS me gusta usar jQuery y no reinventar la rueda, también es más productivo.

Answer 5

Hay un marco llamado ... oh, ¿adivina qué? Vanilla JS . Espero que obtenga la broma ...: D sacrifica la legibilidad del código por el rendimiento ... Comparándolo con jQuery continuación, puede ver que recuperar un elemento DOM por ID es casi 35 veces más rápido. :)

Entonces, si quieres un rendimiento, es mejor que pruebes Vanilla JS y saques tus propias conclusiones. Tal vez no experimente JavaScript colgando la GUI del navegador / bloqueando el subproceso de la interfaz de usuario durante un código intensivo como dentro de un bucle for .

Vanilla JS es un marco rápido, ligero y multiplataforma para crear aplicaciones JavaScript increíbles y potentes.

En su página de inicio hay algunas comparaciones de perf:

Answer 6

He encontrado que ciertamente hay superposición entre JS y JQ. El código que has mostrado es un buen ejemplo de eso. Francamente, la mejor razón para usar JQ sobre JS es simplemente la compatibilidad del navegador. Siempre me inclino por JQ, incluso si puedo lograr algo en JS.

Answer 7

La lista de propiedades en vivo de la primera respuesta de this como un elemento DOM es bastante completa.

Puede que también te interese conocer algunos otros.

Cuando este es el documento:

• this.forms para obtener una HTMLCollection de los formularios de documento actuales,
• this.anchors para obtener una HTMLCollection de todos los HTMLAnchorElements con el name establecido,
• this.links para obtener una HTMLCollection de todos los HTMLAnchorElement s con href establecido,
• this.images para obtener una HTMLCollection de todos los HTMLImageElement s
• y lo mismo con los applets obsoletos como this.applets

Cuando trabaja con document.forms , document.forms[formNameOrId] obtiene el formulario denominado o identificado.

Cuando esta es una forma:

• this[inputNameOrId] para obtener el campo denominado o identificado

Cuando este es el campo de formulario:

• this.type para obtener el tipo de campo

Cuando aprendemos los selectores de jQuery, a menudo omitimos el aprendizaje de las propiedades de los elementos HTML existentes, que son tan rápidos de acceder.

Answer 8

La respuesta correcta es que siempre tendrá una penalización de rendimiento cuando use jQuery en lugar de JavaScript nativo "simple". Eso es porque jQuery es una biblioteca de JavaScript. No es una versión nueva de JavaScript.

La razón por la que jQuery es poderosa es que hace que algunas cosas sean demasiado tediosas en una situación de navegador cruzado (AJAX es uno de los mejores ejemplos) y suaviza las inconsistencias entre la gran cantidad de navegadores disponibles y proporciona una API consistente. También facilita fácilmente conceptos como el encadenamiento, la iteración implícita, etc., para simplificar el trabajo en grupos de elementos juntos.

Aprender jQuery no es un sustituto para aprender JavaScript. Debe tener una base firme en este último para que pueda apreciar plenamente lo que es más fácil para usted saber qué es lo primero.

- Editado para abarcar los comentarios -

Como los comentarios son rápidos para señalar (y estoy de acuerdo con el 100%), las declaraciones anteriores se refieren al código de evaluación comparativa. Una solución JavaScript "nativa" (suponiendo que esté bien escrita) superará a una solución jQuery que logra lo mismo en casi todos los casos (me encantaría ver un ejemplo de lo contrario). jQuery acelera el tiempo de desarrollo, lo cual es un beneficio significativo que no quiero minimizar. Facilita un código fácil de leer y fácil de seguir, que es más de lo que algunos desarrolladores pueden crear por sí mismos.

En mi opinión, entonces, la respuesta depende de lo que está intentando lograr. Si, como presumí basado en su referencia a los beneficios de rendimiento, está buscando la mejor velocidad posible para su aplicación, entonces usar jQuery introduce gastos generales cada vez que llama a $() . Si busca legibilidad, coherencia, compatibilidad entre navegadores, etc., entonces hay razones para favorecer jQuery sobre JavaScript "nativo".

Answer 9

Las respuestas de otros se han centrado en la pregunta general de "jQuery vs. plain JS". A juzgar por su OP, creo que simplemente se preguntaba cuándo es mejor usar Vanilla JS si ya ha elegido usar jQuery. Su ejemplo es un ejemplo perfecto de cuándo debe usar vanilla JS:

$(this).attr(''id'');

Es más lento y, en mi opinión, menos legible que:

this.id

Es más lento porque tiene que girar un nuevo objeto JS solo para recuperar el atributo de la manera jQuery. Ahora, si va a utilizar $(this) para realizar otras operaciones, entonces, por supuesto, almacene ese objeto jQuery en una variable y opere con eso. Sin embargo, me he encontrado con muchas situaciones en las que solo necesito un atributo del elemento (como id o src ).

¿Hay otras prácticas comunes como esta? Donde ciertas operaciones de Javascript se podrían lograr más fácilmente, sin traer jQuery a la mezcla. ¿O es un caso raro? (de un "atajo" de jQuery que realmente requiere más código)

Creo que el caso más común es el que describe en su publicación; personas que envuelven $(this) en un objeto jQuery innecesariamente. Veo esto más a menudo con id y value (en lugar de usar $(this).val() ).

Edición: Here un artículo que explica por qué el uso de jQuery en el caso de attr() es más lento. Confesión: lo robé de la etiqueta wiki, pero creo que vale la pena mencionarlo para la pregunta.

Edite de nuevo: dadas las implicaciones de legibilidad / rendimiento de solo acceder a los atributos directamente, yo diría que una buena regla general es, probablemente, intentar usar this.<attributename> cuando sea posible. Probablemente hay algunos casos en los que esto no funcionará debido a las inconsistencias del navegador, pero probablemente sea mejor intentar esto primero y recurrir a jQuery si no funciona.

Answer 10

Si está preocupado principalmente por el rendimiento, su ejemplo principal se encuentra en la cabeza. En mi opinión, invocar a jQuery de forma innecesaria o redundante es, en mi humilde opinión, la segunda causa principal de rendimiento lento (el primero es un desplazamiento pobre de DOM).

No es realmente un ejemplo de lo que estás buscando, pero veo esto tan a menudo que vale la pena mencionar: una de las mejores maneras de acelerar el rendimiento de tus scripts jQuery es almacenar en caché objetos jQuery y / o usar el encadenamiento:

// poor
$(this).animate({''opacity'':''0''}, function() { $(this).remove(); });
// excellent
var element = $(this);
element.animate({''opacity'':''0''}, function() { element.remove(); });
// poor
$(''.something'').load(''url'');
$(''.something'').show();
// excellent
var something = $(''#container'').children(''p.something'');
something.load(''url'').show();

Answer 11

Ya hay una respuesta aceptada, pero creo que ninguna de las respuestas escritas directamente aquí puede ser exhaustiva en su lista de métodos / atributos nativos de javascript que prácticamente garantiza el soporte entre navegadores. Para eso puedo redirigirte a quirksmode:

http://www.quirksmode.org/compatibility.html

Es quizás la lista más completa de lo que funciona y lo que no funciona en el navegador en cualquier lugar. Preste especial atención a la sección DOM. Es mucho para leer, pero el punto no es leerlo todo, sino usarlo como referencia.

Cuando comencé a escribir aplicaciones web con seriedad, imprimí todas las tablas de DOM y las colgué en la pared para saber de un vistazo qué es seguro de usar y qué requiere piratear. En estos días, solo busco en Google algo así como la quirksmode parentNode compatibility cuando tengo dudas.

Como cualquier otra cosa, el juicio es principalmente una cuestión de experiencia. Realmente no te recomendaría leer todo el sitio y memorizar todos los problemas para descubrir cuándo usar jQuery y cuándo usar JS simple. Solo ten en cuenta la lista. Es bastante fácil buscar. Con el tiempo desarrollará un instinto de cuándo es preferible la simple JS.

PS: PPK (el autor del sitio) también tiene un libro muy bonito que recomiendo leer

Answer 12

$(this) es diferente a this :

Al usar $(this) , se asegura de que el prototipo jQuery se transfiera al objeto.

Answer 13

• this.id (como ustedes saben)
• this.value (en la mayoría de los tipos de entrada, solo los problemas que conozco son IE cuando <select> no tiene propiedades de value establecidas en sus elementos <option> , o entradas de radio en Safari).
• this.className para obtener o establecer una propiedad de "clase" completa
• this.selectedIndex contra un <select> para obtener el índice seleccionado
• this.options contra un <select> para obtener una lista de elementos <option>
• this.text contra una <option> para obtener su contenido de texto
• this.rows contra una <table> para obtener una colección de elementos <tr>
• this.cells contra un <tr> para obtener sus celdas (td & th)
• this.parentNode para obtener un padre directo
• this.checked para obtener el estado marcado de una checkbox de checkbox Gracias @Tim Down
• this.selected para obtener el estado seleccionado de una option Gracias @Tim Down
• this.disabled para obtener el estado deshabilitado de una input Gracias @Tim Down
• this.readOnly para obtener el estado ReadOnly de una input Gracias @Tim Down
• this.href contra un elemento <a> para obtener su href
• this.hostname contra un elemento <a> para obtener el dominio de su href
• this.pathname contra un elemento <a> para obtener la ruta de su href
• this.search contra un elemento <a> para obtener la cadena de consulta de su href
• this.src contra un elemento donde es válido tener un src

... creo que entiendes la idea

Habrá momentos en que el rendimiento es crucial. Como si estuvieras realizando algo en un bucle muchas veces, es posible que desees deshacerte de jQuery.

En general puedes reemplazar:

$(el).attr(''someName'');

con:

Arriba estaba mal redactado. getAttribute no es un reemplazo, pero recupera el valor de un atributo enviado desde el servidor, y su setAttribute correspondiente lo establecerá. Necesario en algunos casos.

Las oraciones de abajo lo cubren. Vea esta respuesta para un mejor tratamiento.

el.getAttribute(''someName'');

... para acceder directamente a un atributo. Tenga en cuenta que los atributos no son lo mismo que las propiedades (aunque a veces se reflejan entre sí). Por supuesto que también hay setAttribute .

Digamos que tuvo una situación en la que recibió una página en la que necesita desenvolver todas las etiquetas de cierto tipo. Es corto y fácil con jQuery:

$(''span'').unwrap(); // unwrap all span elements

Pero si hay muchos, es posible que desee hacer un poco de API nativa de DOM:

var spans = document.getElementsByTagName(''span'');
while( spans[0] ) {
var parent = spans[0].parentNode;
while( spans[0].firstChild ) {
parent.insertBefore( spans[0].firstChild, spans[0]);
}
parent.removeChild( spans[0] );
}

Este código es bastante corto, se desempeña mejor que la versión jQuery y puede convertirse fácilmente en una función reutilizable en su biblioteca personal.

Puede parecer que tengo un bucle infinito con el exterior while debido a while(spans[0]) , pero debido a que estamos tratando con una "lista parent.removeChild(span[0]); ", se actualiza cuando hacemos parent.removeChild(span[0]); . Esta es una característica bastante ingeniosa que no podemos ver cuando trabajamos con un Array (o un objeto similar a un Array).