AngularJS, 6 meses después

Logo de AngularJS

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.


9 comentarios en “AngularJS, 6 meses después

  1. Mauricio Stand dijo:

    Igual tenes que tener en cuenta que Knockout por si solo, es un framework de mvvm en un solo sentido, quiero decir que no es full stack como Angular.

    Angular es mucho mas completo, tiene rutas, testing y hasta para ajax, encambio knockout solo aparte de crear tus propios custom bindings, siempre la relacion es de observables, viewmodels y dom y no se encarga de mas nada..

    Por eso es la razon del proyecto de Durandal que obviamente es mucho mas completo y puedes ya con el compararlo con Angular o Ember que son frameworks full stack.

    De hecho, a mi en mi caso personal, aun no uso Durandal y si quiero implementar rutas,, he estado usando una libreria que se integra a knockout que se llama PagerJS..

    En todo caso, buen articulo y saludos.

  2. Juan María Hernández dijo:

    Muchas gracias por tu comentario, estoy de acuerdo contigo. Angular es mucho más completa (para bien y para mal) que Knockout, y sería comparable a Durandal, no a Knockout.

    En el post menciono Knockout sólo en referencia al data binding (que sí es algo cubierto por esa librería), por lo que creo que la comparación tiene sentido.

  3. Llevo utilizando angularjs fuertemente desde hace algunos meses igual que tu y creo q el artículo está muy cercano de lo que yo podría escribir.. ya que me he identificado completamente con casi todo lo escrito.. incluso con “Hay un exceso de magia”.. sí, eso que hace un poco complejo comprender como o porque se toman las decisiones de si usar directivas, varScopes o cualquier otro método de lógica para mostrar, ocultar o cambiar algo en el cliente.

    Muchas gracias por compartir de la experiencia.

    Saludos

  4. Juan María Hernández dijo:

    Hola Xavi,

    Lo tengo instalado y lo he usado alguna vez para resolver dudas sobre scopes, pero si te digo la verdad, tampoco le he conseguido sacar demasiado partido.

    En cualquier caso, una herramienta más a tener en cuenta.

    Gracias por la aportación!

  5. oduber vasquez dijo:

    buenas tardes gracias por el aporte!! Una Pregunta!!! con angularJs podemos hacer aplicaciones robustas? por ejemplo; tengo un sistema de gestion administrativa para una gobernacion

  6. Hola, Juan María.
    Muchas gracias por compartir tú experiencia con nosotros. Estoy empezando a trabajar con AngularJs en la realización de una “app Demo”, con el fin de verificiar este framework para ser utilizado en una arquitectura para un sistema de tamaño significativo.

    Gracias por esta información, y ya mismo estoy leyend tú post… “AngularJS, gracias por los servicios prestados”. Lo cual por su nombre me asusta un poco…

    Saludos y continúa escribiendo buenas entradas…

Deja un comentario

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

*

Puedes usar las siguientes etiquetas y atributos HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>