Aquel viejo y fiel amigo llamado jQuery
Si llevas en esto del desarrollo web el tiempo suficiente, seguro que guardas un rincón en tu corazoncito para el bueno de jQuery. Yo, desde luego, lo tengo. Recuerdo perfectamente mis primeros años, cuando todo lo que necesitaba para sentirme un auténtico arquitecto de la red era importar aquel script desde un CDN y empezar a repartir signos de dólar por todo mi código. $(".mi-clase").hide() y ¡pum!, magia. Era una época más sencilla, o al menos eso nos queríamos creer.
El problema no era la herramienta, sino en lo que se acababan convirtiendo mis proyectos. Todavía tengo pesadillas con archivos main.js que superaban las tres mil líneas, donde encontrar la lógica de un simple botón era como buscar una aguja en un pajar de selectores encadenados. El famoso spaghetti code no era una advertencia, era mi realidad diaria. Manipulaba el DOM de forma directa, agresiva y, sobre todo, descontrolada. Si cambiaba un en el HTML, media aplicación se iba al traste porque mi selector de jQuery ya no encontraba lo que buscaba. Era un castillo de naipes aguantado con pinzas.
El choque de realidad: Mi primer encuentro con Angular
Cuando escuché por primera vez que el desarrollo frontend se estaba profesionalizando con frameworks como Angular, mi primera reacción fue de rechazo absoluto. "¿Por qué necesito TypeScript? ¿Para qué sirve un decorador? ¿Por qué tengo que compilar el código para ver un hola mundo?". Me sentía cómodo en mi caos, pero el mercado y la complejidad de los proyectos que me llegaban empezaron a empujarme hacia el abismo de lo moderno.
Mi primer contacto con Angular (en aquel entonces ya estábamos pasando del antiguo AngularJS a las versiones nuevas) fue frustrante, no te voy a mentir. Me sentía un junior otra vez. No entendía por qué tenía que crear cinco archivos para mostrar una lista de usuarios. Me parecía una ingeniería excesiva. Sin embargo, hubo un momento de iluminación, un clic mental que lo cambió todo: entendí que el desarrollo moderno no va de manipular elementos de la pantalla, sino de gestionar el estado de los datos y dejar que el framework se encargue de la representación visual.
El cambio de mentalidad: Del 'cómo' al 'qué'
Con jQuery, mi cabeza siempre estaba pensando en cómo cambiar el color de un botón o cómo añadir una fila a una tabla. Tenía que dar las instrucciones paso a paso: 'Busca este elemento, crea este otro, añádele esta clase, insértalo aquí'. Era agotador y propenso a errores.
Al pasar a Angular, empecé a pensar en componentes. La gran revelación fue darme cuenta de que el HTML ya no era un documento estático que yo modificaba desde fuera, sino una plantilla viva que reaccionaba a mis datos. Si mis datos decían que había tres usuarios, la interfaz mostraba tres filas. Punto. Yo ya no tenía que ir con el pincel pintando cada detalle; yo solo gestionaba la paleta de colores (los datos) y el framework hacía el trabajo sucio.
Lo que realmente me costó aprender
No todo fue coser y cantar. La curva de aprendizaje de Angular es, siendo generosos, una montaña empinada. Aquí te dejo un par de cosas que me hicieron sudar tinta:
- La Inyección de Dependencias: Al principio me parecía magia negra. No entendía cómo un servicio aparecía de la nada en mi constructor. Me costó asimilar que el framework era el que gestionaba el ciclo de vida de mis objetos.
- Los Observables y RxJS: Esto fue, sin duda, lo más duro. Pasar de promesas sencillas a flujos de datos reactivos me voló la cabeza. Recuerdo pasar tardes enteras intentando entender por qué un subscribe no me devolvía lo que yo esperaba. Pero una vez que entiendes el poder de la programación reactiva, volver atrás se siente como intentar conducir un coche con palancas de madera.
¿Mereció la pena tanto esfuerzo?
Rotundamente, sí. A menudo me preguntan si echo de menos la rapidez de montar algo con jQuery. Mi respuesta es que para un prototipo de diez minutos, quizás sí, pero para dormir tranquilo por las noches, me quedo con Angular mil veces.
La transición me enseñó a ser mejor desarrollador, no solo porque aprendí una herramienta nueva, sino porque aprendí arquitectura de software. Aprendí a separar responsabilidades, a escribir código testeable y a valorar la tipado fuerte de TypeScript. Ya no cruzo los dedos cada vez que hago un deploy esperando que un selector de CSS no haya roto toda la lógica del carrito de compra. Ahora confío en mi código.
A veces me encuentro con código antiguo mío de 2014 y me entra un escalofrío, pero a la vez siento orgullo. Fue necesario pasar por aquel fango de selectores y eventos globales para valorar la elegancia de una arquitectura modular bien estructurada.
Reflexiones finales y consejos
Si estás en ese punto en el que el cuerpo te pide dar el salto pero te da miedo la complejidad, mi consejo es: lánzate. No intentes aprenderlo todo a la vez. No necesitas ser un experto en RxJS el primer día. Empieza entendiendo los componentes y el enlace de datos (data binding). El resto vendrá con la práctica y con los golpes que te des contra la consola del navegador.
La web ha evolucionado y nosotros con ella. jQuery fue un puente maravilloso que nos permitió cruzar el río de la incompatibilidad entre navegadores, pero hoy en día estamos construyendo rascacielos, y para eso necesitamos herramientas más pesadas y seguras. No es solo un cambio de framework, es una evolución profesional que te abre las puertas a entender cómo se construye el software de calidad hoy en día.