Fotografía de Ilya Ilyukhin

Que levante la mano el que use librerías tipo jQuery o Underscore.js ?. Venga, no seas tímido y reconoce que tú también las usas (recuerda que estás en un espacio seguro ?). Es completamente normal que utilices este tipo de librerías. Por dos motivos: por un lado, simplifican muchísimo el trabajo con su montón de utilidades. Por otro lado, forman parte del Core de WordPress, así que ¿por qué no ibas a usarlas? En el escritorio de WordPress ya casi vienen cargadas de serie, y en el front-end basta con un par de líneas de código. Ahora bien, ¿que haya librerías que sean útiles y formen parte del core es motivo suficiente para cargarlas «sin pensar»? Yo creo que no.

En la entrada de hoy, me gustaría empezar explicándote por qué surgieron este tipo de librerías y los problemas que intentan solucionar. A continuación, hablaremos de cómo puedes hacer lo mismo con un JavaScript pelado, sin estas librerías.

Librerías JavaScript

El objetivo de las librerías JavaScript es el de abstraer una serie de operaciones más o menos complejas en una API de funciones sencillas, cómodas y fáciles de invocar. Por ejemplo, la librería jQuery permite realizar operaciones tan complejas y variadas como manipular el DOM, gestionar eventos, crear animaciones, etc. Y consigue hacerlo a través de una API clara, concisa y que, además, es compatible con multitud de navegadores.

Logo de jQuery
El logo de jQuery lo deja bien claro: «escribe menos, haz más». Ahora ya sabes para qué sirve una librería ?

Las librerías son herramientas de trabajo para los desarrolladores. Nos ayudan a ser más eficientes. De hecho, creo que el resumen de lo que es una librería lo tienes en el propio logo de jQuery: «escribe menos, haz más». Y es que esa es la esencia de lo que se intenta conseguir: hacer fácil lo que por definición es difícil.

jQuery

jQuery nació en el año 2006 como una librería multiplataforma diseñada para, ¡oh, sorpresa!, simplificar el scripting de páginas web. Entre sus objetivos estaban ofrecer una sintaxis con la que poder manipular los elementos de la web y gestionar los eventos fácilmente. Además, la librería también incluye un mecanismo de plugins, con lo cual es posible extenderla y añadirle nuevas funcionalidades. Uno de los plugins (o colección de plugins, si lo prefieres) más conocidos de jQuery es jQuery UI, que permite definir y gestionar cuestiones relacionadas con las interfaces de usuario (eventos, efectos, widgets, etc).

Diálogo para añadir nuevos mensajes sociales
Captura de pantalla del diálogo para añadir nuevos mensajes sociales con Nelio Content, creado usando el módulo de diálogos de la librería jQuery UI.

Si no conoces todavía esta librería, la entrada de la Wikipedia (en inglés) es bastante completa y te dará una visión general. También te recomiendo que eches un vistazo a la documentación oficial o a alguno de los miles de tutoriales que existen en los que te explican cómo usarlo.

Underscore.js

Otra librería que quizás hayas usado (aunque no es, ni de lejos, tan conocida como jQuery) es Underscore.js. Se trata de una librería que incluye un montón de utilidades para realizar funciones comunes. Algunos ejemplos de sus funciones son map (para convertir un array en otro), filter (para quedarte con los elementos de un array que cumplen una cierta condición), pluck (para convertir un array de objetos en un array con los valores de uno de los atributos de esos objetos), etc.

Underscore.js es especialmente conocida porque va cogida de la mano de un framework MVC para JavaScript llamado Backbone. Con él puedes crear aplicaciones web con arquitectura MVC; es decir, ofrece las herramientas necesarias para crear modelos de datos y vistas para visualizarlos, así como toda la arquitectura de eventos y métodos para conectar unas piezas con otras. Otros frameworks muy conocidos de tipo MVC son React, Angular o Vue, pero no voy a comentarlos porque, a diferencia de Backbone o Underscore.js, estos últimos no forman parte del Core de WordPress (todavía ?).

Finalmente, comentarte que Underscore.js ha ido perdiendo fuelle respecto a otras librerías como, por ejemplo, Lodash. Lodash coge muchas de las ideas de Underscore.js (de hecho, tiene una compilación equivalente), pero tiene una comunidad más activa detrás (por lo que he leído, los contribuidores originales de Underscore.js se pasaron a Lodash).

La parte negativa

El problema con librerías tipo jQuery, Underscore.js o Backbone es, básicamente, su peso. Por ejemplo, jQuery pesa unos 250kb (90kb si está minificado). En principio no parece un problema, pero fíjate que si tienes 50.000 visitas únicas al mes, jQuery consumirá 4 gigas de tráfico. No está mal, ¿eh?

Bob Esponja levantando peso
Aunque no lo parezca, jQuery y otras librerías JavaScript pesan bastante.

Cuando te das cuenta del impacto que puede tener el uso de una librería en tu sistema es el momento de plantearse si realmente la necesitas o no. ¿Estás metiendo sobrecarga para «cuatro tonterías»? Yo sí puedo responderte que, en muchas ocasiones, sí, lo hacía: siempre metía jQuery en todos mis proyectos, aunque sólo fuera para seleccionar un elemento del DOM y cambiarle el texto ($('.elemento').text('texto')). Pero, amigo, para estos escenarios tan sencillos (y algunos más complejos también) esto ya no es necesario.

La solución a todos tus problemas: Vanilla JavaScript

O, como decimos en España, JavaScript a pelo ?. Y, bueno, quizás no sea la solución a todos tus problemas, pero sí te permite solucionar los que acabamos de comentar. Y es que JavaScript ha evolucionado un montón desde los inicios y ahora es más fácil que nunca hacer todo lo que hacemos con estas librerías… sin estas librerías. Así que, sin más dilación, veamos 6 ejemplos de lo que puedes hacer hoy con JavaScript pelado, dejando atrás las típicas librerías JS.

1. Seleccionar elementos del DOM

Este es, quizás, el principal motivo por el cual instalamos librerías como jQuery: poder seleccionar objetos del DOM con un sencillo $( '#elemento' ). Pero hacer esto en JavaScript puro y duro es extremadamente sencillo:

Sí, la sintaxis es un poco más larga, pero recuerda que te ahorras el peso de jQuery. Además, toda operación ejecutada con funciones nativas y no a través de librerías suele ser un poco (o mucho) más rápida.

Sé lo que estás pensando: en jQuery podías hacer la selección usando una expresión CSS y con el código JavaScript que te acabo de mostrar necesitas usar una función diferente para obtener objetos por ID, clase o tipo. Bueno, pues que sepas que también tienes la posibilidad de realizar una selección usando la sintaxis CSS con JavaScript puro:

2. Moverte por el DOM

Otra operación habitual cuando manipulamos elementos del DOM es saltar de uno a otro: del padre al hijo, de un elemento a su hermano, etc. Todas estas operaciones también existen en JavaScript puro y duro, así que sigues sin necesitar jQuery:

3. Set y Get de atributos

Otra característica típica suele ser la manipulación de atributos. Por ejemplo, cuando quieres añadir una clase a un elemento o conocer la dirección a la que apunta un cierto enlace. Todo esto se puede hacer con las operaciones getAttribute y setAttribute:

4. Operaciones con múltiples nodos

Una de las grandes ventajas de jQuery es que puedes encadenar operaciones de la siguiente forma:

Esto lo que hace es seleccionar múltiples nodos y aplicar las sucesivas operaciones a todos ellos. Esto es algo que, por desgracia, no puedes hacer en vanilla JavaScript; para conseguirlo, deberás iterar por todos los nodos con un bucle:

Esto es lo que internamente hace jQuery, claro, pero reconozco que en este caso el resultado es algo más tedioso. Pero con la llegada de ECMAScript 6 y sus funciones lambda, tampoco es un drama. En el siguiente punto te muestro un ejemplo ?

5. Operaciones con arrays

Al principio de la entrada te he hablado de algunas de las utilidades para arrays típicas que vienen en Underscore.js. Pues bien, diría que todas ellas sin excepción están disponibles en JavaScript puro. Aquí tienes algunos ejemplos:

Como ves, tanto la sintaxis como los nombres de las funciones son extremadamente parecidos. La ventaja de usar vanilla JavaScript es que cualquier desarrollador JavaScript debería estar familiarizado con el lenguaje, con el orden de los parámetros, etc. Si, en cambio, te acostumbras a una librería en concreta, te arriesgas a no saber qué operaciones hay disponibles en otra librería o cómo funciona la otra librería.

¡Ah! Te había dicho que te enseñaría cómo iterar de forma más elegante sobre nuestra lista de nodos usando funciones ECMAScript 6. Pues bien, aquí tienes el ejemplo:

Básicamente, aprovechamos que el resultado de la selección es un array para aplicar la función forEach y pasarle como argumento una función lambda con un único parámetro llamado a que modifica su clase. No está nada mal, ¿eh?

6. Operaciones con objetos

Existen muchas operaciones diferentes que podemos hacer sobre los objetos, como conocer el número de atributos que tienen, listarlos todos, etc. Aunque el resultado puede no ser tan extremadamente compacto como el que obtenemos usando Underscore.js, la ventaja de usar JavaScript sin librerías merece la pena:

Por cierto, una de mis funciones favoritas es la de pluck que, recordemos, sirve para, a partir de un array de objetos, construir otro array con el valor de un atributo. ¿Cómo haríamos esta función en ECMAScript 6? Así:

Conclusión

La lista de cosas que podemos hacer hoy en día con JavaScript pelado es muy grande. Algunas de ellas sólo están disponibles en la versión más nueva de JavaScript (ECMAScript 6) que, por desgracia, todavía no está soportada por el 100% de los navegadores. Pero, insisto, hay muchas cosas que ya puedes hacer hoy en todos los navegadores usando Vanilla JavaScript, así que estudia tu proyecto en concreto y valora hasta qué punto necesitas cargar librerías como jQuery o Underscore.js.

Imagen destacada de Ilya Ilyukhin vía Unsplash.

12 respuestas a «Descubre por qué vanilla JavaScript es el futuro»

  1. Avatar de Juan David Nicholls Cardona

    En la vida real toca soportar distintas versiones de navegadores, sin usar un transpilador tienes que preocuparte de que el código que escribas funcione en todas partes y que esté bien escrito, eso es lo que realmente hacen librerías como jQuery y Lodash. Por lo tanto jQuery no solo permite jugar con elementos del DOM, tiene un gran número de utilidades al igual que Lodash que hacerlo a mano no tendría mucho sentido, ya que es reinventar la rueda, como por ejemplo trabajar con Promesas (Deferred), requests http, animaciones, plugins, etc… Es por eso que VanillaJS no va a ser el futuro hasta que soporte todo esto de manera nativa y siempre se va a necesitar algo más, como por ejemplo un transpilador como Babylon o TypeScript que te permita escribir código con lo nuevo de ECMAScript y te garantice que tú código funcione en todas partes.

    1. Avatar de David Aguilera

      ¡Hola!

      Muchas gracias por tu aportación, Juan David. Efectivamente, el gran problema que tenemos a día de hoy es, precisamente, el nivel de compatibilidad que ofrecen los navegadores. En cualquier caso, si escribes código usando lo nuevo de ECMAScript (aquello que todavía no está soportado por la mayoría de navegadores) y luego lo transpilas a una versión anterior, en realidad estás escribiendo con JavaScript puro, ¿no?

      Un saludo,
      David

      1. Avatar de Juan Martín Díaz
        Juan Martín Díaz

        No.
        Una cosa es lo que escribes y otra es en lo que deriva finalmente el código.
        Un transpilador puede terminar transformando tu código en python si quieres.
        Incluso podría haber un transpilador que te permitiera escribir tu código en jQuery y te lo transformara en vanilla js.
        Con respecto al artículo, respeto tu punto de vista pero discrepo ampliamente.
        Creo que los frameworks han venido para quedarse, sea el que sea y en cualquier lenguaje de programación.
        Mientras un lenguaje provee los materiales de construcción, los frameworks lo potencian con herramientas y maquinaria.
        Uno mismo puede construir una modesta parrilla (barbacoa en Argentina) solo con unos ladrillos, arena y cemento, pero si quieres construir un rascacielos vas a necesitar un poco más de potencia productiva.
        Lo mismo ocurre con los lenguajes de programación.
        Por otra parte, en este mismo artículo hablas de WordPress, si bien no es un framework sino un gestor de contenido de propósito general, podrías hacer lo mismo que haces con WP utilizando PHP y lograrías un website que funcione mucho más rápido, reducir el código que entregas al navegador (lo cual significa también ahorro de ancho de banda) y además, suponiendo que programas a conciencia, evitas dejar agujeros de seguridad bien conocidos como es el caso de WP.
        Yo comencé con vanilla js hace muchos años y recuerdo que me costó mucho aceptar la incorporación de una librería pesada.
        El incremento en productividad es sustancial, ni hablar de los problemas de compatibilidad que sigue (y seguirá) solucionando (que en aquel momento con la hegemonía de IE eran grandes y variados).
        Con la llegada de los CDN se mitiga enormemente el problema del uso de ancho de banda.
        Para terminar, jQuery hoy por hoy ya no despierta el interés de prácticamente nadie ya que ha llegado a los límites de sus posibilidades.
        Afortunadamente ha abierto la puerta a otros frameworks que aportan soluciones a problemáticas puntuales como es el caso de las RIA.
        Si no es jQuery será otro pero vanilla js nunca será una alternativa para grandes construcciones.

        1. Avatar de David Aguilera

          Muchísimas gracias por tus apuntes, Juan. Cuando escribí la entrada pensaba más en librerías tipo jQuery o underscores, que simplificaban el acceso al DOM o añadían utilidades; hoy en día, creo que ya no son necesarias, porque JavaScript a pelo cumple perfectamente. De todas formas, coincido absolutamente contigo: siguen existiendo (y existirán) frameworks que faciliten el trabajo a los programadores, y en el propio WordPress encontramos ejemplos con, por ejemplo, la reciente integración de React para Gutenberg.

  2. Avatar de Juan Carlos Estrada Nieto
    Juan Carlos Estrada Nieto

    Como dijo Juan David, en la vida real. En la vida real debes resolver rápido, al cliente no le importa cómo sino cuándo se soluciona el problema y definitivamente jquery te ahorra todo eso. El año pasado me propuse aprender javascript puro, aprendes a dominar muchas cosas, el dom, archivos, entre otras cosas, lo que si me pareció bueno fueron los patrones, el patrón module en particular permite tener el código bien ordenado y acceder a funciones y subfunciones de un módulo sin tener todo el código de una aplicación grande desordenado.

    1. Avatar de David Aguilera

      Totalmente de acuerdo: hay que ser rápido y resolutivo, y jQuery es una fantástica herramienta. De todas formas, nunca está de más conocer las alternativas ?

  3. Avatar de jesus parra
    jesus parra

    en realidad yo también usaba jquery, levanto la mano, pero realmente no es tan necesario como lo hacen parecer, si aprendes javascript correctamente, te das cuenta que estas insertando librería tras librería, tras libreria, y cuando menos piensas tu código no cumple con los estandares de Web Performance Optimization, bloquean la carga, luego los pones aincronamente, y unas funciones cargan despues de otras, todo un lio, y para cuando jquery o todas las librerías que usas se descargan, tu codigo javascript vanilla, ya ejecuto las funciones, siempre tienes que pensar ¿es realmente necesario?

    1. Avatar de David Aguilera

      Efectivamente, Jesús. Creo que jQuery es una fantástica librería que ayudó a unificar en cierta forma los navegadores cuando cada uno era de su padre y su madre. Pero hoy en día, y viendo que todos se están poniendo las pilas en cuanto a compatibilidad, vanilla javascript es una opción muy interesante.

  4. Avatar de Fco. Javier Rodríguez
    Fco. Javier Rodríguez

    Estoy totalmente de acuerdo con este análisis, cada vez hay mas framework que lo que hacen es aportar funciones que usan el código nativo para ahorrarte el trabajo, pero lo malo de esto es que esos framework te aportan una infinidad de funciones que la mayoría de las veces no usas, solo usas unas cuantas del mismo.

    No ocurre solo en javascript, ocurre en muchos otros lenguajes, yo soy mas partidario de cuando inicio un proyecto crearme un pequeño js con las funciones que mas vaya a usar. En el presente artículo se ha presentado 6 ejemplos de lo que puede hacerse desde js puro, pues bien, si no vas a necesitar mas nada que eso, te creas 6 funciones que hagan eso y listo y te ahorras todo el código extra que te aportan los framework, yo añadiría una función mas que es la de ajax y con eso te bastas y sobras.

    Además, con estas cosas nos echamos tierra encima los programadores, por que resulta que debes tener conocimiento de decenas de frameworks ( que al fin y al cabo es código ajeno ) y estar al día, cuando lo lógico sería estar al día de las técnicas de programación no de las distintas sintaxis de los distintos frameworks.

    1. Avatar de David Aguilera

      Muchas gracias por tus aportes 🙂

  5. Avatar de Pierre
    Pierre

    Muchísimas gracias por tus apuntes, Juan,
    personalmente ( por lo que hago) odio estas librerias con jquery and co.

    Ahora bien quiero comentar una curiosidad muy util de javascript ( facil de probar ) y que no he encontrado en internet ( salvo si alguien me diece done)
    yo, en lugar de escribir:

    var elt = document.getElementById( 'list' );
    elt.innerHTML = 'algo';

    yo escribo directamente:

    var unaVar = unID.innerHTML;
    unID.innerHTML = 'algo';
    unID.value

    Pruebaselo … funciona de maravilla por todo

    Pierre

    1. Avatar de David Aguilera

      Gracias por el comentario, Pierre. Efectivamente, esto es una característica que estaba disponible en las primeras versiones de JavaScript y que parece que sigue estando disponible en las nuevas versiones de HTML.

      De todas formas, yo personalmente no te recomiendo usarlo, porque puede dar problemas. Por ejemplo, si tengo un elemento con ID main y luego defino una variable en JavaScript llamada main, tu solución ya no funciona… y el problema es que es muy difícil saber si hay algún script que esté poniendo variables en el ámbito global que enmascaren los IDs de tu árbol DOM.

      Para mí, es una de esas «cosas raras de Internet» 😉

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

He leído y acepto la política de privacidad de Nelio Software

Tus datos personales se almacenarán en SiteGround y serán usados por Nelio Software con el único objetivo de publicar tu comentario aquí. Con el envío de este comentario, nos das el consentimiento expreso para ello. Escríbenos para acceder, rectificar, limitar o eliminar tus datos personales.