Hace ya unos seis meses que decidí que en mi siguiente aplicación web usaría algún tipo de framework, y que éste sería AngularJS. A raíz de aquella decisión, aproveché para escribir algunos posts sobre los conceptos básicos de AngularJS y contar lo que me parecía mejor y peor de AngularJS.

Ahora, esa aplicación lleva un tiempo en producción, ha tenido que convivir con múltiples navegadores y dispositivos y ha cubierto su cuota de bugs y mejoras correspondientes, por lo que me parece interesante hacer un balance de cómo nos está yendo la cosa trabajando con una aplicación desarrollada íntegramente en Javascript y con AngularJS.

OJO: ésta es una visión personal, basada en mi experiencia en un proyecto concreto y con un equipo concreto. Todo lo que digo puede ser completamente falso para otros proyectos. Además, es posible que dentro de otros 6 meses, con más experiencia, mi opinión sea totalmente distinta.

Actualización (23/06/2014): como era de esperar, unos meses después mi punto de vista es ligeramente distinto.

Estabilidad

Una de las cosas que puedo resaltar es que, de momento, AngularJS se ha mostrado muy estable.

Tengo que reconocer que era una de las cosas que más me preocupaba, porque cuando usas un framework tan completo (para bien y para mal) como AngularJS, si el propio framework no es estable, suele ser difícil solucionarlo. Además AngularJS me sigue pareciendo bastante invasivo y no sería fácil migrar la aplicación a otro framework sin reescribir partes importantes.

Rendimiento

En cuanto al rendimiento, no hemos tenido ningún problema. He leido algunas críticas al databinding de AngularJS basado en comparar propiedades (en lugar de utilizar un patrón observer tipo INotifyPropertyChanged), pero el rendimiento es bastante bueno.

Nuestra aplicación es una aplicación para teléfonos móviles y tablets que sustituye a una aplicación desarrollada para Windows Mobile con .NET Compact Framework, y el rendimiento que tenemos con AngularJS sobre el hardware actual es mucho mejor que el que teníamos con esa aplicación para Windows Mobile.

Obviamente, el rendimiento que tendríamos con una aplicación nativa para iOS o Android sería mejor, pero para nuestra aplicación, el rendimiento con AngularJS es más que suficiente, incluso en dispositivos de gama media-baja (teléfonos Android de hace un par de años).

Mi opinión es que, en la mayoría de aplicaciones típicas de «línea de negocio», el rendimiento que puedes conseguir con AngularJS es lo bastante bueno como para que no sea una preocupación.

Mantenimiento

Un factor clave en todo proyecto de software es cómo de fácil o difícil es mantener la aplicación, tanto para resolver bugs como para añadir funcionalidad. En ese sentido, hay algunas características de AngularJS que han resultado especialmente beneficiosas.

El sistema de databinding es muy bueno. Recientemente he tenido que tocar otra aplicación (mucho más simple) desarrollada con Knockout, y me ha parecido mucho más incómodo. No sé si en Knockout 3 mejorará, pero comparando uno y otro, para mi el de AngularJS gana por goleada, aunque haya otros que opinan diferente.

Si a esto le unimos la potencia de las directivas para encapsular HTML y comportamiento, al final mantener y añadir nuevas vistas a la aplicación es realmente sencillo.

En la parte negativa, entre la mala documentación de AngularJS y la cantidad de opciones que tienen las directivas, a veces es complicado depurarlas y saber qué está pasando y por qué. Hay un exceso de magia que resulta un poco incómodo.

Una parte que nos ha tocado revisar un par de veces ha sido el manejo del $rootScope, que permite almacenar datos «globales» a la aplicación para que sean accesibles en todos los controladores. Es difícil mantener un equilibrio entre lo que es cómodo inyectar en el $rootScope para no tener que inyectarlo en cada controlador, y no pasarse para evitar convertir el $rootScope en un cajón desastre.

En ese apecto, a veces me gustaría poder aplicar algo similar a property injection para propiedades ambientales de los controladores, por ejemplo $q para las promesas, el usuario logeado o el servicio de localización de texto. Esto es algo que, con algo de ganas, se puede implementar interceptando la creación de los controladores.

Flujo de trabajo

Otra cosa que suele inquietar, especialmente a los que estamos acostumbrados a trabajar con lenguajes estáticos, es si desarrollar una aplicación en un lenguaje dinámico es realmente práctico. De momento, eso no hay sido un gran problema.

Es verdad que a veces se echan en falta herramientas de análisis estático, por ejemplo al renombrar un símbolo, pero también es verdad que con un buen flujo de trabajo (en nuestro caso automatizado con grunt) y una suite de tests decente, no es demasiado grave.

Además, se acaba escribiendo menos código que en un lenguaje estático, por lo que cada refactorización afecta a menos partes y es menos frecuente (al menos hasta ahora, ya veremos dentro de otros 6 meses).

En este sentido también ha ayudado que AngularJS ofrece muchos puntos de extensión y muchas veces ha sido posible añadir cosas sin tener que tocar código que ya existía (y funcionaba).

El sistema de tests de extremo a extremo de AngularJS ha demostrado ser extremadamente útil. De hecho, tenemos muchos más tests de extremo a extremo que unitarios (seguramente también porque toda la lógica «complicada» y útil de cubrir con tests unitarios reside en un servidor externo).

No me ha gustado la estructura de carpetas que hemos utilizado. Tal vez inspirados por ASP.NET MVC y por el tutorial de AngularJS, que pone todas las vistas en las misma carpeta, hemos particionado los ficheros por tipo (Controllers, Services, Views, etc.). Esta organización resulta poco práctica y probablemente si empezara de cero (o cuando tengamos tiempo), la cambiaría por una organización por funcionalidad.

Conclusiones

Todas estas experiencias no dejan de ser eso, experiencias en un proyecto concreto y por un equipo concreto, pero pueden resultar útiles a gente que se encuentre en una situación parecida a la nuestra (mucha experiencia trabajando con C# y pocos proyectos previos con HTML/JS).

A día de hoy, AngularJS me sigue pareciendo una muy buena solución para desarrollar aplicaciones SPA. ¿La mejor? No lo sé, no he probado todas, y este tipo de cosas, como la elección del lenguaje de programación, dependen de muchos factores. Lo que sí puedo decir es que, hoy por hoy, no me arrepiento de haberlo utilizado.

Actualización

Si has llegado hasta aquí y estás decidido a utilizar AngularJS, tal vez te interese leer cómo evolucionó mi opinión sobre este framework y por qué me acabé cansando de AngularJS.