De HTML a Node.js

Una de las primeras cosas que aprendí a hacer cuando comencé a programar, por allá en el año 2010, fue animar elementos en HTML con la etiqueta </marque>, y claro, eventualmente me di cuenta que eso no era parte de lo que se conoce como “programar”. Aún así, solo con el uso de esa etiqueta se podían lograr efectos bien choros para el año 2000 como el de Matrix.

Pasó el tiempo y mientras aprendía HTML y CSS conocí Javascript, y lo encontré bastante complicado, no entendía qué era cada cosa ni cómo utilizar las funciones ya existentes para crear mis propias funciones y así controlar el DOM (ni [REDACTED] idea qué era eso) con suerte sabía qué era una función. Y por no saber nada de eso fue como me topé con jQuery, el famoso framework librería del momento con el que podías hacer que se movieran las cosas en tu página, el cual me fue mucho más fácil de entender. Solo tenía que utilizar la función .animate() y todo se movía como yo quería, aunque no tuviera la más mínima idea de lo que estaba haciendo por debajo, generalmente copiaba código que encontraba en Stackoverflow u otros sitios similares.

Y sí, me gustaba que se animaran los divs o que los botones cambiasen de color de forma gradual cuando pasaba el mouse por encima (menos sabía que se podía hacer tal cosa en CSS3) y que una imagen se agrandase al hacerle click. Caché también lo que eran los eventos… Y que manera de usar el .click() para mostrar u ocultar divs, hacer un efecto acordeón o simplemente capturar los datos de algún formulario y validar su contenido. Después fue el .on() y el .live() para cuando se cargaban cosas dinámicas que no se renderizaban al momento de cargar la página por primera vez, sino que venían desde el servidor a través de una llamada a la función .ajax() en respuesta a una acción del usuario. Ahí PHP se encargaba de procesar mi petición y retornar el listado de “posts”, “comentarios” o “likes”. Sí, porque cómo hoy en día hacer tu propia aplicación tipo Uber está de moda (aunque cada vez menos), en ese tiempo hacer tu propia “Red Social” era la moda, y eso fue lo que intente hacer para aprender cómo funcionaban realmente.

Eventualmente, conseguí un trabajo real, en donde pude utilizar mis conocimientos en PHP y jQuery para extender las funcionalidades de varios sitios web en Wordpress y otros más en diferentes frameworks que en cierta ocasión leí su nombre en los resultados de alguna búsqueda por ahí, pero estaba demasiado intimidado por toda esa falta de conocimientos para en serio aprender a usarlos.

Fue justo en esa época en donde de verdad entendí cómo funcionaba AJAX y el resto de opciones que tiene la función .ajax() de jQuery. Que su existencia era para estandarizar el uso de de XMLHttpRequest entre diferentes navegadores, por qué claro, cada navegador tenía su propia forma de hacer las cosas y que básicamente estandarizar todo ese enredo, era el fin de jQuery.

Ya entre el año 2013 y 2014, me obsesioné en entender cómo funcionaban los chats. Simplemente no entendía cómo funcionaban, es extraño porque nunca me lo había preguntado cuando MSN Messenger estaba vivo y lo usaba a diario. Quizás porque era una aplicación de escritorio, y como no podía ver su “código fuente” apretando ctrl+u, era algo más mágico e inalcanzable a mi entendimiento. En fin, como sabía ya más o menos el funcionamiento de HTTP y todo esto de AJAX, sabía también que no se podía hacer algo así con AJAX; no puedes mantener una conexión con el servidor y esperar a que te mande mensajes, sino que debes enviar una petición y el servidor te tiene que responder de manera inmediata (al menos en un tiempo razonable) o fallaría por timeout. No entendía nada de nada. Otra vez me sentía como cuando empecé jugando con la etiqueta marquee.

Y así pasó el tiempo. Me topé con la técnica del long polling, en donde hay que hacer requests constantemente al servidor y esperar a que haya algo nuevo desde la última vez que se consultó. Pero eso no era lo que quería, no era así cómo funcionaba la cosa en realidad. Habían otras siglas raras; XMPP u otra cosa rara llamada Comet que menos entendía.

Hasta que me encontré con el protocolo TCP y sus Sockets y que HTTP es solo otro protocolo que funciona sobre ese estándar de forma sincrónica, que existía otra forma asincrónica de hacer las cosas y tuve que buscar cómo diferenciar tales cosas. Al entender esto y con una rápida búsqueda en Google; "how to use sockets in a browser" llegué a los famosos websockets que a su vez me llevaron a la librería socket.io que provee de una API estándar para el uso de websockets en diferentes navegadores (Sí, la misma idea de jQuery y un montón de librerías más), además de una lógica de salas a las cuales un socket o cliente se puede unir y recibir eventos que son publicados por otros clientes. Pero lo más interesante de todo esto es que socket.io funciona sobre Javascript, en el lado del servidor con node.js.

Inmediatamente instalé node.js (copié y pegué los comandos), hice el código que genera el servidor en websockets (copié y pegué el ejemplo que sale en la documentación) ejecuté más comandos y listo, ya tenía corriendo mi servidor en node.js con websockets. Esa fue la parte simple, porque para poder hacer las funcionalidades que quería tuve que aprender Javascript. Al fin entendí lo que eran los callbacks y al poco tiempo lo que eran los Promises, después llegaría el async/await y quizás qué es lo venga después. Entendí también que Javascript es un lenguaje funcional y que no habían clases como en Ruby o Python (también intentaba aprender de esas cosas), si no que se tenían que usar funciones como prototipos y en base a esto crear instancias que heredan propiedades o algo así, acá hay una buena comparación de cómo se usaban las clases en node.js antes de ES6 y después.

Me di cuenta, que Javascript no era tan difícil como creía. Que no pasaba nada si dejaba de usar las palabras reservadas class o new, y que de hecho, no las echaba para nada de menos. También entendí que se podían hacer sitios completos solo con node.js, conectar una base de datos y servir HTML con un sistema de templates, tropezandome con el framework Express.js que es algo similar a Sinatra de Ruby (ya no usaba tanto PHP) y significaba algo simple, compacto, fácil de entender; defines tal ruta, cuando alguien quiere hacer algún requests se ejecuta tal función en donde puedes buscar registros en alguna base de datos o conectarse con otro servicio a través de requests (Que ya está marcada como obsoleta, así que es mejor usar algo como axios o fetch).

Todo esto fue hace varios años ya. Hoy en día el entorno ha evolucionado bastante, cada día la comunidad crea nuevas herramientas y se desechan otras. A veces es difícil mantenerse al tanto de todas las cosas que existen, y es mucho más complicado saber qué cosa aprender, por qué apostar para enfocarse y lograr ganar experiencia. Es por eso que a continuación dejo un par de consejos completamente personales y que en ningún caso son completamente válidos para quién esté leyendo esto. Si algo creen que está mal o se puede mejorar, los invito a dejarnos comentarios en nuestras redes sociales.

Abstraer. Más que a nivel de código, me refiero a nivel de conceptos. Tratar de buscar una capa superior de qué es cada cosa. Por ejemplo, si estás aprendiendo node.js con Express.js, un framework minimalista, bastante bueno para desarrollar APIs REST, es probable que en otros lenguajes de programación exista lo mismo, como por ejemplo Flask o Bottle para Python, Sinatra en Ruby, Lumen en PHP, Fiber en Go e incluso alternativas dentro del mismo lenguaje como Koa para node.js. Identificar qué elementos se comparten como por ejemplo los middlewares. Si aprender a usarlos en alguno de estos frameworks, habrás entendido el concepto y será mucho más fácil aplicarlo para el resto.

Aplicar primero, entender después. Hay veces en las que haces algo y no tienes idea de qué está haciendo por detrás que te puede llegar a frustrar e incluso desmotivar. Por eso una de las cosas que siempre hago es ignorar el por qué e ir directo al resultado, la explicación llegará después, de alguna forma. Si paso mucho tiempo con algo que no entiendo, simplemente lo dejo de hacer, cambio de foco y cuando vuelvo a tomar el mismo tema lo puedo mirar de otra forma y verlo tan claro como el agua de una vertiente.

Errores. Todo falla. Siempre. Si funciona a la primera, es porque hay algo raro. Lo mejor que puede pasar para aprender, es que salgan montones de errores, ver por qué ocurren, pero más importante es saber leer un error. He visto a muchos principiantes que cuando les da un error entran en pánico, abren el código en algún editor y se ponen a buscar por todas partes la falla, sin ni siquiera leer el detalle del error, no se fijan en qué archivo pasó ni el número de línea. Mientras más errores veas y los puedas solucionar, más sabrás a futuro, cuando tu o alguien más se encuentre con ese mismo error. Por eso es importante que todo falle. Literalmente aprendes de tus errores.

Buscar. Sí, buscar en Google, Stackoverflow, Duck Duck Go, Bing, en todos lados. Principalmente buscar en inglés, la mayoría del contenido está en este idioma y aunque te cueste un poco el inglés no es necesario algo tan avanzado, con inglés tarzán encontrarás muchas coincidencias en tu búsqueda, incluso más que si describes el tema con el mejor inglés que tengas. La idea es acostumbrarse a usar inglés en tus búsquedas hasta en las que no estén relacionadas con el área y te darás cuenta que obtendrás mejores resultados y de paso mejorarás tu inglés.

Practicar y enseñar. Esto es un poco obvio, pero para aprender algo de verdad se debe poner en práctica inmediatamente con lo que sea, haz scripts que resuelvan algún problema específico, no es necesario hacer cosas nuevas, puedes hacer cosas que ya existan y mejorarlas o sacar alguna idea de este listado. Cuando sepas un poco más del tema, tratar de enseñarlo. Buscar una forma simple de cómo explicarlo. Te darás cuenta de que en realidad no lo sabes tan bien y tendrás que volver a buscar e investigar y esto es altamente recomendado hacerlo mientras estás enseñando, así de paso enseñas a cómo investigar, cuáles son los que sigues, cuál es la lógica que aplicas y lo más valioso de todo es que se comparten las ideas y los puntos de vista aprendiendo mucho más!

Esto es lo que hoy en día considero clave aprender al momento de iniciar como programador basado en mi experiencia personal de estos últimos diez años. Será entretenido ver cómo va a cambiar todo de acá a 5 o 10 años más. No se debe nunca dejar de aprender.