Confesiones de un desarrollador que juró no volver
Si me hubieras preguntado hace tres o cuatro años qué opinaba sobre Angular, probablemente te habría puesto una mueca de escepticismo. Para ser totalmente sincero, hubo una época en la que consideraba que Angular era el 'monstruo' bajo la cama del desarrollo web. Lo veía como esa herramienta excesivamente burocrática, pesada y llena de conceptos complejos que solo tenían sentido en grandes entornos corporativos donde la estructura importa más que la agilidad.
Durante mucho tiempo, me sentí liberado en los ecosistemas de React y Vue. Me encantaba esa sensación de 'libertad' (que a veces terminaba siendo un caos, pero eso es otro tema). Sin embargo, hace unos meses, por una mezcla de curiosidad profesional y necesidad en un proyecto específico, decidí asomarme de nuevo a lo que Google estaba haciendo con su framework. Y lo que encontré me dejó, sinceramente, descolocado. No era el Angular que yo recordaba. Había algo diferente, algo mucho más liviano y, por primera vez en años, divertido de usar.
Mi traumática experiencia en el pasado
Para entender mi reconciliación, primero tengo que contarte por qué me fui. Mi relación con Angular (especialmente en las versiones 2 a 8) fue una montaña rusa de frustraciones. Recuerdo pasar horas intentando entender por qué un componente no se renderizaba porque me había olvidado de declararlo en un NgModule específico. Los módulos eran, para mí, el mayor obstáculo: una capa de abstracción que parecía añadir trabajo extra sin un beneficio claro para el desarrollador individual.
Luego estaba RxJS. No me malinterpretes, la programación reactiva es potente, pero Angular te obligaba a entrar en ella de cabeza desde el minuto uno. Intentar hacer un simple formulario o una petición HTTP se convertía en una odisea de observables, pipes y suscripciones que, si no gestionabas bien, acababan en fugas de memoria. Sentía que Angular me obligaba a aprender una enciclopedia entera antes de poder pintar un 'Hola Mundo' en condiciones. Así que, como muchos otros, decidí 'huir' hacia entornos que me permitieran ser productivo más rápido.
¿Qué ha cambiado para que decida volver?
Lo que me hizo cambiar de opinión no fue una sola característica, sino una filosofía renovada que parece haber permeado en el equipo de desarrollo de Angular. La llegada de los Standalone Components fue el primer gran 'clic' en mi cabeza. Por fin, podíamos decir adiós a la tiranía de los NgModules. Ahora, un componente es una unidad independiente, fácil de entender y de mover. Esto simplifica la arquitectura de una manera brutal y acerca la experiencia de desarrollo a lo que tanto nos gusta de otros frameworks.
Pero el verdadero cambio de juego, lo que realmente me voló la cabeza, fueron los Signals. Si vienes de otros mundos, los Signals son la respuesta de Angular a la gestión de estado reactiva pero de una forma mucho más humana y predecible. Ya no dependemos exclusivamente de Zone.js para que el framework sepa que algo ha cambiado (con el coste de rendimiento que eso implicaba). Con los Signals, el código es más limpio, más explícito y, sobre todo, mucho más fácil de depurar. Ya no siento que estoy peleando con el framework para que actualice la vista; ahora fluye de manera natural.
La estabilidad frente al caos de la elección
Otra reflexión que me ha traído de vuelta es el agotamiento que a veces produce el ecosistema de React. No me malinterpretes, me encanta React, pero a veces te cansas de tener que decidir qué biblioteca de enrutamiento usar, qué gestor de estado elegir o cómo estructurar tus carpetas esta semana.
Angular, en su madurez actual, ofrece un 'batteries included' que ahora valoro mucho más que antes. Tener un CLI potente, un sistema de rutas estandarizado y una forma oficial de manejar formularios (que, por cierto, siguen siendo los mejores de la industria) me permite centrarme en lo que realmente importa: la lógica de negocio de mi aplicación. Es como volver a una casa que ha sido reformada: la estructura es sólida y conocida, pero ahora todo es más moderno, eficiente y estético.
Lo que he aprendido en este regreso
Mi mayor aprendizaje en este viaje de ida y vuelta es que no debemos casarnos con nuestros prejuicios tecnológicos. El software evoluciona, y las herramientas que una vez nos parecieron toscas pueden convertirse en nuestras mejores aliadas si saben adaptarse. Angular ha sabido escuchar a la comunidad, ha eliminado la grasa sobrante y se ha quedado con un motor potente pero mucho más accesible.
He aprendido que la complejidad no está en la herramienta, sino en cómo la usamos. El 'nuevo' Angular me permite escribir menos código, entender mejor qué está pasando bajo el capó y, curiosamente, disfrutar de un tipado estricto con TypeScript que en otros entornos a veces se siente como un parche. Además, la mejora en el rendimiento de hidratación y las nuevas APIs de control de flujo en los templates (ese @if y @for que ahora son tan limpios) demuestran que el framework está más vivo que nunca.
Reflexiones finales
Si eres de los que, como yo, huyó de Angular hace años renegando de su complejidad, te animo sinceramente a que le des una segunda oportunidad. No intentes aplicarlo como se hacía en 2018; olvida los módulos, abraza los Signals y disfruta de la potencia del nuevo sistema de control de flujo.
Al final del día, nuestra labor como desarrolladores es elegir la mejor herramienta para cada problema, y hoy por hoy, Angular se ha vuelto a ganar un sitio privilegiado en mi cinturón de herramientas. No es el monstruo que recordaba; es, posiblemente, uno de los frameworks más sólidos, modernos y equilibrados que tenemos a nuestra disposición actualmente. A veces, alejarse un tiempo es la mejor manera de valorar lo que una tecnología puede ofrecerte cuando realmente madura.