VanillaJS vs jQuery

Una de las cosas más difíciles para cualquier desarrollador(a) es tener que estar al día con las nuevas tendencias, nuevos frameworks, librerías, … y en particular en el mundo de JavaScript.

Con tal avalancha de herramientas e ideas es fácil confundirse y sentirse perdidx.

Ayer en la tarde una colega me preguntó:

Quería hacerte una consulta sobre jQuery. Es recomendable mezclar VanillaJS con jQuery al momento de implementarlo? Es decir, si estoy implementado funcionalidad con jQuery, sería recomendable codear también con VanillaJS?

Como primera aclaración, jQuery es una librería escrita en JavaScript para el navegador, mientras que VanillaJS no es más que un chiste entre JavaScripters 🐵; una manera de referirse a JavaScript que no hace uso de librerías o frameworks.

Si tu código no hace uso de dependencias externas, dirías que es VanillaJS, mientras que si estás usando una librería o framework (por ejemplo jQuery) tu código ya no es VanillaJS.

Como referencia, el código fuente completo de VanillaJS es:

// VanillaJS v1.0
// Released into the Public Domain
// Your code goes here:

😜

Como puedes ver, no se trata de un framework o librería. Es simplemente una broma para gente a la que le encantan los frameworks y creen que tienes que usar uno. Si alguien te pregunta “qué framework o librería estás usando”, puedes responder que usas VanillaJS (o sea que no usas ningún framework o librería).

VanillaJS vs jQuery (ahora sí)

Volviendo a la pregunta original, podríamos refrasearla como: “debería mezclar código que usa jQuery con código que accede y manipula el DOM directamente usando las APIs del navegador?” En ese caso mi respuesta corta sería no. Pero…

Si ya estás usando jQuery en un proyecto mediano/grande, ya estás pagando el precio de cargar 93k, y probablemente los estés usando porque quieres abstraer las APIs del DOM para que tu código funcione en navegadores antiguos; si es así, entonces usa jQuery para todo lo que sea DOM (y XHR). Tu código será más corto y consistente (con el peligro de convertirse en spaghetti code). De hecho, si usamos la librería y además implementamos en estilo vanilla estamos pagando doble, el costo de tanto la librería como el tener que implementar, testear y mantener nuestra propia implementación de funcionalidad que ya ofrece jQuery.

Por otro lado, si se trata de un proyecto chico, probablemente no valga la pena obligar al usuario a descargar 93k para ahorrar 20 líneas de código.

Finalmente, si estamos empezando un proyecto nuevo a finales de 2017, teniendo en cuenta HTML5, ES6, React, Vue, … quizás deberíamos preguntarnos si realmente necesitamos jQuery, y la respuesta probablemente sea no.

Un ejemplo

Y ya que estamos en este tema, aprovechemos para ver un ejemplo y comparar un snippet usando VanillaJS (DOM API del navegador) y después lo mismo con jQuery. El snippet simplemente añade la clase clicked a los elementos con clase some-class al hacer click sobre ellos.

// Selecciona todas las etiquetas con la clase `some-class`
var nodes = document.getElementsByClassName(‘some-class’);
// Declaramos una función que después registraremos para que se
// ejecute en el evento `click` (onclick) de cada nodo seleccionado.
var handleClick = function (e) {
  var classes = e.target.className.split(/\s/);
  if (classes.indexOf(‘clicked’) === -1) {
    classes.push(‘clicked’);
    e.target.className = classes.join(‘ ‘);
  }
};
// Iteramos sobre los nodos seleccionados y registramos
// `handleClick` en el evento click de cada uno.
for (var i = 0; i < nodes.length; ++i) {
  nodes[i].addEventListener(‘click’, handleClick);
}

Ahora la misma funcionalidad usando jQuery:

$(‘.some-class’).click(function () {
  $(this).addClass(‘clicked’)
});

Viendo el ejemplo uno se puede sentir tentado por lo simple que parece jQuery (en el ejemplo es mucho más fácil de entender y es mucho menos código), pero cabe mencionar que este beneficio normalmente sólo se da en scripts pequeños. Según crece una página web o aplicación, jQuery de hecho fomenta una serie de patrones que pueden resultar en código muy desorganizado y dificilísimo de entender/mantener (aka spaghetti code).

Conclusiones

• Si necesitas dar soporte a navegadores viejitos y jQuery ya está cargado en tu página (ya estás pagando el costo de tener jQuery), entonces no hay motivo para volver a implementar todos los detalles que ya incluye la librería y no aprovechar sus beneficios.
• Si se trata de un proyecto chico, probablemente no valga la pena obligar al usuario a descargar 93k de librería para ahorrar 20 líneas de código.
• Siendo finales de 2017, si estás empezando un proyecto nuevo — teniendo en cuenta HTML5, ES6, React, Vue, … — es probable que jQuery no sea la herramienta adecuada.
• En ejemplos sencillos vemos que jQuery puede simplificar las cosas notablemente (además de abstraer diferencias entre navegadores), pero más adelante puede fomentar código poco estructurado.

Addendum

No he podido evitar añadir un comentario sobre el ejemplo anterior… algo completamente fuera de contexto en este post… pero aprovecho a incluirlo ya que ilustra un problema super común.

En el ejemplo hay un bucle dentro del cual registramos la función handleClick en el evento click de cada nodo seleccionado. Para ello primero declaramos la función handleClick en vez de usar una función anónima directamente como argumento a addEventListener.

for (var i = 0; i < nodes.length; ++i {
  // ESTO ESTÁ MAL!! Una función nueva en cada iteración
  nodes[i].addEventListener(‘click’, function (e) {
    // ...
  });
}

El motivo por el que evitamos hacer esto y en vez usamos la función handleClick es para no estar declarando una función nueva en cada iteración del bucle, lo cual es muy ineficiente e innecesario. La misma función puede/debe ser reusada.