En mis últimos post he hecho un buen repaso de las características que me parecen más interesantes de AngularJS, empezando por los conceptos básicos, siguiendo con la organización en módulos con servicios e inyección de dependencias, las directivas y filtros para mejorar el mejorar el interfaz de usuario y terminando con las herramientas que ofrece angular para realizar tests unitarios y de extremo a extremo.
En este post voy a tratar de sintetizar lo que más y lo que menos me ha gustado de angular.
Como siempre, este tipo de cosas son bastante personales, por lo que cualquier opinión (especialmente si es distinta) será bienvenida en los comentarios.
Un poco de contexto antes de empezar
Angular es una solución completa que incluye prácticamente todos los aspectos que puedes necesitar para crear una aplicación cliente en javascript. Esto incluye la generación de vistas, el uso de databinding, las rutas, la organización de componentes en módulos, la comunicación con el servidor…
Eso quiere decir que no tiene sentido compararlo con librerías como jQuery, Knockout, Handlebars o PagerJs. Eso son librerías orientadas a resolver un problema concreto, pero no proporcionan una solución global para desarrollar aplicaciones.
No hay que olvidar que angular está diseñado para desarrollar aplicaciones, no páginas web. Si lo que estás desarrollando es una página web, donde prime el contenido, necesites una buena indexación y un html limpio y cristalino, angular no es una buena solución, pero no porque sea un mal producto, simplemente no está diseñado para ello.
Las partes buenas
El sistema de databinding es muy completo y potente. De serie permite hacer casi cualquier cosa que necesites, pero además se trata de un sistema de databinding fácilmente extensible mediante directivas y filtros, lo que permite a crear pequeños componentes que facilitan que la capa de presentación sea algo organizado y no el típico jaleo que acaba siendo muchas veces.
La idea de poder anidar los $scopes (ViewModels), aunque al principio parezca un poco extraña, acaba resultando bastante natural y posibilita crear diseños bastante interesantes.
Aunque al principio era un poco reticente al uso de un contenedor de inversión de control en javascript (no así a la inyección de dependencias), después de trabajar con angular tengo que reconocer que he cambiado de opinión.
Es cierto que hay que definir explicítamente las dependencias y la sintaxis es un poco desagradable para evitar problemas con los minifiers y uglifiers, pero al final compensa porque te permite concentrarte en la clase que estás desarrollando sin tener que preocuparte de la implementación y el ciclo de vida de sus dependencias.
Desde el principio, angular está diseñado para ser fácilmente testeable. Teniendo en cuenta lo imporantes que son los tests en javascript, esto es una cosa muy de agradecer. A través de karma se pueden crear tanto tests unitarios (ayudados por los mocks que se incluyen en angular) como tests de extremo a extremo, y eso es un factor crítico para mantener la estabilidad de la aplicación.
Las partes malas
Una de las cosas que más confusas me han resultado al trabajar con angular es la nomenclatura elegida para las cosas. La mayoría de los conceptos que se manejan con angular son conceptos habituales que ya conocía, pero la forma de llamarlos es un poco rara.
La mayoría de los filtros no filtran nada, sino que formatean. El estado se mantiene a través de servicios. Los ViewModel se convierten en los $scope. No soy muy bueno poniendo nombres a las cosas, pero yo los hubiera llamado algo así como Components, Transformers y ViewModels.
Esto además nos lleva a otro problema muy frecuente en proyectos opensource y especialmente en la comunidad javascript, que está evolucionando tan rápido: la falta de documentación.
La documentación oficial de angular no es que esté mal, pero no es todo lo completa que a uno le gustaría, muchas veces falta ejemplos y no siempre está actualizada. Es verdad que es fácil encontrar documentación en forma de videos, tutoriales y posts, pero la velocidad a la que se desarrolla angular hace que se queden obsoletos muy pronto. En cuanto sales de los ejemplos típicos y encuentras problemas, no encuentras mucha ayuda.
Por último, hay que tener en cuenta que si decides usar angular, te casas con angular. Esto está motivado por la propia concepción de angular como solución «todo incluido», por lo que tampoco es muy achacable al propio angular, pero no deja de ser un factor importante.
Me parece complicado desarrollar una aplicación completa con angular y luego tratar de migrarla a otro framework, porque la mayoría de la funcionalidad va a estar muy integrada con clase que dependen de angular.
Es un riesgo que puede merecer la pena asumir, pero que hay que tener presente.
Conclusión
Ante la pregunta de si usaría angular para mi próximo aplicación con javascript, la respuesta es, a día de hoy sí (de hecho lo estoy haciendo).
La curva de aprendizaje se hace un poco dura, sobre todo por la falta de documentación y la elección de nombres, pero luego resulta bastante productivo gracias a cosas como el databinding y el contenedor de inversión de control.
El aspecto más preocupante de utilizar angular es el mismo de utilizar cualquier framework de estas características: te atas mucho a él y asumes un riesgo grande al ligar tu aplicación al destino de angular.
La parte positiva de esto es que se trata de un proyecto opensource y con un código relativamente fácil de seguir, por lo que en caso de apuro, siempre podrás meterlo mano para solucionar los problemas que te vayan surgiendo.
Actualización
Si has llegado hasta aquí, tal vez te interese ver cómo evolucionó mi opinión de AngularJS después de utilizarlo durante seis meses y, sobre todo, por qué me acabé cansando de AngularJS.
Un par de comentarios sobre los puntos negativos:
La nomenclatura no me parece que esté mal del todo. Por cierto, el $scope no es el modelo, si no el sitio donde pones los modelos. Esta distinción es importante y si no la tienes clara te vas a encontrar con problemas en tu aplicación (hablo por experiencia). Por ejemplo, la nomenclatura que propones es todavía más ambigua, ¿qué entenderías por un Component? puede ser cualquier cosa. ¿un transformer? Algo que transforma, pero esto es en vista o transforma las peticiones o las respuestas ajax, son interceptores que transforman entradas o salidas de servicios. Un ViewModel es la vista del modelo, el modelo de la vista o un mix de vista y modelo. No quiero meterme con tus sugerencias, sino simplemente comentar que la nomenclatura es un tema siempre muy controvertido, pero por experiencia con varios proyectos de AngularJS, su nomenclatura resulta muy precisa en lo que transmite (le han dado muchas vueltas como se puede ver con los refactors y evoluciones de las versiones 0.x del proyecto).
Por otra parte, otro apunte sobre el te «casas con AngularJS»: es cierto. Ahora mi matiz: tras mi experiencia con otros frameworks MVC como BackboneJS, puedo decir que el divorcio de AngularJS es más sencillo, principalmente porque trabajas con funciones planas sin «heredar» de clases propias del Framework y porque dispones de inyección de dependencias, que siempre desacopla elementos pudiendo ir intercambiando distintas partes.
Saludos!
Unos puntos interesantes.
Coincido en que la nomenclatura es una cuestión muy personal y también en que hay frameworks más intrusivos que angular de los que es más complicado despegarse.
En cuanto al $scope vs ViewModel, yo veo el $scope muy similar (por no decir idéntico) al ViewModel de otros frameworks como Knockout, Caliburn, etc. Ojo que hablo de ViewModel, no de modelo. El ViewModel sirve como adaptación del modelo a las necesidades de la vista, pero no es el modelo como tal, y es sobre lo que realizas el databinding. En ese sentido, el $scope se ajusta bastante bien a esa definición.
Gracias por tu opinión.
Yo recien empiezo con angularjs y lo veo muy bueno pero la documentacion es lo mas importante de todo frameworks, yo vengo de Extjs para mi es el mejor framework documentado que existe, aun cuando no usaba algo o no sabia como funcionaba no tenia que ir a otro lugar que no sea su propia documentacion. Solo el problema que tengo con angularjs es ese.
Hola estoy usando angular llevo una semana y esta muy complicado pero tiene un gran potencial una pregunta, Tengo un problema que estoy usando una consulats hechar por angular y al dar click en un enlance todo el html llamado o mejor dicho toda mi vista llamada con angular se pierde alguien sabe el porque o como evitarlo?
Anderson, debes estudiar estas partes…
ngRoute, ngController y el ngModule
Debes especificar en un div la pagina que quieres cargar a travez del ngRoute, así solo va a variar ese div en vez de la página completa.
Uso angular en la parte cliente de muchos de nuestros servicio. Dado a que sus caracteristicas de heredad son pocas en comparacion con backbone.js realmente depende el uso o orientacion que le demos a este simpatico framework, quien esta acostumbrado a java server faces o a esquemas mvc le viene comodo un angular para variar.
AngularJS no se lo recomiendo a nadie, es una basura. Perdí 15 días tratando de que consumiera un servicio post. No hay forma de que deje de tirar el error «No ‘Access-Control-Allow-Origin’ header is present on the requested resource». En ningún foro supieron cómo solucionarlo (inclusive en stackoverflow).