Hace algo más de un año empecé a jugar con AngularJS, en parte por curiosidad y en parte por la necesidad que tenía en ese momento de desarrollar una aplicación web para dispositivos móviles. Seis meses depués comenté por aquí la que, hasta entonces, había sido una experiencia muy satisfactoria con AngularJS.
Siempre he tratado de mantener una postura medianamente objetiva, intentando identificar los que (al menos para mi caso de uso concreto) eran los puntos fuertes y débiles de angularjs, y tengo que reconocer que, con el tiempo, las partes que no me gustan están empezando a ganarle la partida a las partes que sí.
Al César lo que es del César
Antes de empezar a quejarme, creo que es importante dejar una cosa clara: la aplicación que desarrollamos usando angularjs está siendo un éxito. Esto no se trata de haber tenido una mala experiencia «comercial» y echarle la culpa de ella a una decisión tecnológica.
Lo más importante es que, probablemente, en ese momento conseguir este éxito no hubiese sido posible sin la ayuda de angularjs (o algún framework parecido).
Cuando empezamos el desarrollo de esta aplicación, nuestro equipo no tenía experiencia en el desarrollo de aplicaciones complejas usando HTML5/JS, y angularjs nos dio todo lo que necesitábamos, no sólo por el framework en si, sino por «guiarnos» hacia una forma de estructurar nuestro código y un conjunto de herramientas basadas en javascript que nos permitieron desarrollar la aplicación en un tiempo relativamente corto y aun así cubrir con creces nuestras expectativas.
Desde este punto de vista, no me arrepiento en absoluto de haber elegido angularjs en aquel momento ya que nos permitió cumplir el objetivo que teníamos.
Lo que me empieza a cansar
De todos los puntos de fricción que he ido notando con angularjs, lo peor, para mi, ha sido la manera de estructurar el código. Tender a encajar todo dentro de las primitivas de angular ( Controller, Scope, Service, Directive, Filter) nos ha llevamos a hacer cosas un tanto retorcidas para resolver problemas aparentemente sencillos.
Soy consciente de nuestra parte de culpa porque realmente podríamos haber puesto más énfasis en trabajar con funciones y objetos tradicionales, pero angularjs te «lleva» a encapsularlo todo en sus primitivas, y a juzgar por los proyectos que se suelen ver por ahí, creo que no somos los únicos a los que les ha pasado esto.
El encorsertar toda la aplicación dentro de las primitivas de angularjs tiene un problema adicional, y es que obliga a depender de los sistemas de testing de angular para poder construir módulos, inyectar dependencias y demás, lo que hace que tus tests resulten innecesariamente complicados.
Nuestra aproximación actual a este problema se basa en intentar aislar los objetos y funciones con lógica de los objetos y funciones con interacción, exactamente igual que haríamos en otras plataformas. De esta forma el comportamiento complejo queda encapsulado en objetos o funciones que no depende de angularjs para nada.
En ocasiones, angularjs es excesivamente complejo y mágico, y comprender lo que está pasando requiere demasiado esfuerzo. Hay cosas que son inherentemente complejas y no queda más remedio que buscar la mejor forma de lidiar con esa complejidad, pero en angularjs se ha optado (como en muchos otros frameworks) por homogeneizar todos los casos. Esto hace que los casos complejos sean complejos y los casos simples… también; y acabes descendiendo a un mundo de services, factories y providers.
Un ejemplo de esto son las directivas. Poder crear pequeños «controles» de usuario es muy cómodo y ayuda a mantener la capa de presentación organizada, pero las directivas permiten cubrir tantos escenarios que, en los escenarios más simples (y frecuentes) acaban siendo bastante complicadas de seguir. Cualquiera que haya escrito un plugin simple de jQuery y la directiva equivalente de angularjs sabe a lo que me refiero.
Es muy fácil terminar abusando del sistema de inyección de dependencias. Podríamos decir que esto es no culpa de angularjs sino de usarlo mal, pero lo cierto es que no es raro encontrar funciones que reciben demasiadas dependencias en casi todos los proyectos que he visto con angularjs.
Al ser tan fácil de usar y añadir nuevas dependencias, acabas teniendo muchas funciones que dependen de muchos servicios, y un sistema pensado originalmente para desacoplar componentes de la aplicación consigue acoplar toda la aplicación hasta límites insospechados. Utilizar inyección de dependencias manual te hace detectar más fácilmente este tipo de problemas y te ayuda a conseguir diseños más cohesivos.
Ciertamente esto es algo que se podría achacar a cualquier contenedor de inversión de dependencias, pero mientras que en otras plataformas parece que se empieza a tener más consciencia del problema, en angularjs todavía queda bastante camino por recorrer.
Conclusiones
Escribir este post ahora, cuando han surgido unas cuantas voces críticas con angularjs (por ejemplo, ésta y ésta), puede parecer ventajista, pero en realidad es la consecuencia lógica de escribir sobre algo que realmente utilizas: con el tiempo tu opinión sobre ello va cambiando (para bien o para mal) según aprendes cosas nuevas.
Muchos de los problemas que he descrito anteriormente se pueden achacar al mal uso de angularjs por nuestra parte, pero no creo que sean exclusivos de nuestra forma de trabajar. La mayoría de código basado en angularjs que puedes encontrar en internet adolece de problemas similares.
Es verdad que angularjs es un framework bastante extensible y eso permite solventar parte de estos problemas y moldearlo hasta cierto punto para trabajar de una manera más independiente del framework, pero llega un momento en que sientes que estás dando demasiadas vueltas para conseguir lo que quieres y que, tal vez, hubiese sido mejor no utilizar angularjs directamente.
¿Quiere todo esto decir que angularjs es un mal framework? Yo no diría tanto. Para una aplicación CRUD en la que puedas resolver el 80% de la aplicación con un par de directivas y un uso razonable de $resource para acceder a un API Rest, angularjs es una buena solución. La cosa se complica cuando tienes una aplicación con flujos de trabajo complejos, donde el sistema de rutas de angularjs empieza a ser un obstáculo; o cuando tienes reglas de negocio complicadas y los controladores/servicios no son la mejor forma de expresarlas.
Lo que sí tengo claro es que, después de haber adquirido más experiencia en el desarrollo de aplicaciones complejas con HTML5/JS, ahora mismo me plantearía otras opciones antes que usar angularjs y buscaría soluciones menos invasivas, que me permitiesen un control mayor sobre la arquitectura de la aplicación sin necesidad de plegarla a las necesidades de un framework determinado.
No sabía sobre AngularJS, creo sería bueno combinarlo con otro Framework, pues más bien parece un complemento al HTML y no otra cosa.
Voy a experimentar con él en mis proyectos en curso.
¡Saludos!
¿¿ Por qué framework te decantarías ??
Creo que ahora mismo intentaría no usar ningún framework. Al menos, no un framework all-in-one que controle todos los aspectos de la aplicación.
Trataría de buscar librerías para cada problema (binding/templates, routing, etc.). Por ejemplo, ReactJS tiene buena pinta para la parte interfaz de usuario (cubriría una parte comparable al binding + directivas de angularjs).
Ningun FrameWork es perfecto, o por lo menos no que yo conozca o haya escuchado de alguno. Lo importante de todo esto es conocer bien el framework a una buena profundidad antes de realizar un proyecto comercial con el. Espero que realizes otro proyectos con otro framework en particular y nos cuentes tus experiencias!!
Estoy de acuerdo contigo, personalmente en momentos me siento encajonado en el framework y me seria mas facil realizar algo directamente con JQuery en un elemento del DOM contenido en el ambito del controller pero es complicado acceder a éste desde afuera de la funcion del controller y se vuelve mas complicado algo que seria mas sencillo, quiero decir que hay casos que no deberian necesitar crear una directiva para conseguir lo que se quiere.
Después de hacer el típico ejemplo de lista de tareas con varias opciones ([1] solo Backbone, [2] Backbone + Marionette), al final he llegado a una que realmente me ha convencido, que es usando Backbone + React + Mustache [3]. Me gusta más la simplicidad y flexibilidad de Backbone y usar para cada tarea necesaria una opción adecuada que la filosofía de otras opciones como Angular. Sin embargo, en los ejemplos [1] y [2] hacer la interfaz con Backbone me pareció algo con cierta complejidad, y algo más complejo que la lista de tareas podría ser mucho mas difícil.
Pero con React en gran parte se elimina toda la complejidad en la parte de la interfaz, de Marionette (Collection, ItemView, CollectionView, Layout, …) y similar con solo Backbone. Me gusta que con React el concepto de las cosas se entienda como si fueran componentes, es decir, piezas de código que pueden reutilizarse y que encapsulan la lógica para tratar con la interfaz, actualizar el modelo y actualizar la vista según el nuevo estado del modelo, el código queda bastante bien organizado, es más simple y fácil de entender. Hacer las vistas con React es muy más sencillo que con Marionette o solo Backbone.
[1] Ejemplo lista de tareas con Backbone, RESTEasy y Tapestry
[2] Ejemplo lista de tareas con Marionette
[3] Ejemplo lista de tareas con Backbone y React
Yo en estos momentos le estoy hechando muchas ganas a aprender AngularJS para realizar un sistema escalable y mantenible (Un proyecto grande), y me encuentro con tu sitio que se me hace una muy buena iniciativa para compartir conocimientos.
Yo en un principio quería elegir un Framework para hacer aplicaciones RIA, observando BackboneJS como primera instancia, pero después supe que Google tenia consigo un Framework que ofrecía muchas posibilidades al momento de realizar aplicaciones grandes y fue cuando mi vista cambio (Como cuando estas con tu novia y vez a otra muchacha).
Es cierto lo que dicen «No te cases con un Framework» pero creo que todos aquí coincidimos que si eres experto en una sola cosa lograrás hacerlo de calidad y profesional.
Mi duda va para todos, vale la pena seguir con angularjs y Llegar hasta la cúspide ? Sería mejor batallar más usando BackboneJS pero garantizará un proyecto escalable y de calidad con el tiempo ??
Yo pregunto todo esto por que a pesar de que soy nuevo con angular y backbone, tengo experiencia en desarrollo web, y la verdad que es un arma de doble filo las directivas en el html y algunas cosas que usa angularjs, pero muchas personas comentan de que eso es la luz del framework.
De antemano muchas gracias.
Saludos.
Hola José,
Me alegro de que te resulten útiles mis posts.
Sobre lo que comentas, tanto angular como backbone (o cualquiera de los otros frameworks que hay por ahí) son perfectamente válidos para desarrollar una aplicación compleja de forma mantenible. Cada uno tiene sus puntos fuertes y débiles, y la elección depende de muchos factores, incluyendo algunos externos al propio framework (conocimientos del equipo de desarrollo, preferencias personales, etc.).
En lo que no estoy de acuerdo es que ser experto en una sola cosa, y más si esta es un framework, te permita alcanzar más calidad y profesionalidad. Yo creo que es más importante conocer los conceptos básicos que conocer un framework concreto. Veo probable que javascript se siga usando (aunque seguramente sin tanto hype) dentro de 5 años, pero tengo mis dudas sobre el futuro de cualquier framework basado en javascript, máxime teniendo en cuenta lo joven que es todo ese ecosistema y lo rápido que evoluciona.
Un saludo,
Juanma
No comparto tu opinión, el lenguaje del futuro es JAVASCRIPT, es por eso que Google se está tomando en serio esto y creó AngularJS, que junto con NodeJS serán un boom..¡
Hola Luis,
Tal vez no me haya explicado bien, pero en ningún momento pretendía decir que Javascript no sea un lenguaje con un futuro prometedor, o que node.js (del que he hablado unas cuantas veces, y en general bien) no sea una plataforma muy interesante.
Un saludo,
Juanma.
Hola a todos en la actualidad tengo un proyecto realizado en zf 1.12 http://edelh.com/quiero-trabajar , y me encontré con este tema de los frameworks mvc del lado del cliente y me confundía un poco : «decia para que usar un framework mvc del lado del cliente si usaba zend framework en php» me volvía loco (me gusta aprender tecnologias interesantes) así que investigando un poco y por ahi me comentabn que si quería aplicar angularjs en este caso, tendria que crear mi proyecto backend como api rest
en ese momento dije:»ahhh asi era la cosa» se aclaraba todo .
Si desarrollo mi proyecto backend como api rest puedo usarlo también para mis aplicaciones moviles.
En la actualidad estoy probando angular de la siguiente forma:
Estoy desarrollando nuevamente mi proyecto bajo este modelo:
frontend : angularjs + stylus
backend : zf2 apirest + mysql
mas que nada para ver hasta donde puedo llegar y hasta donde puedo ir con angular, si va todo bien pienso desarrollar de esta forma mis próximos proyectos, espero que asi sea.
Quisiera sus comentarios sobre si vale la pena migrar un desarrollo normal como el que tengo a un desarrollo angular.
Saludos
Muy buen post, y mejores aún los comentarios. En estos momentos estoy por enfrentar un proyecto bastante grande en donde angularJS ha sido seleccionado. Me gustaría volver a leerlo dentro de unos meses a ver en que coincido contigo.
Con respecto a «casarse con un framework», pienso que está errado, debemos aprender más «Javascript» y conocer los frameworks.
Saludos desde Venezuela.
Si bien soy un principiante en angularJS, en aplicaciones de escritorio la inyección de dependencias e inversión del control te crea una aplicación muy compleja a pesar de algunas ventajas como la alta cohesión y bajo acoplamiento y por ende puedes tener clases mucho mas faciles de testear, respecto a las funciones comunes yo creaba un proyecto algo que aquí sería equivalente a un API con funciones comunes que puedan ser reutilizadas en los diferentes controladores y que esten completamente testeadas ¿Es posible realizar esto con angularJS y otra cosa que tambien tengo duda es posible hacer uso de patrones de diseño en base a tu experiencia?.
¿Has usado MEAN o tan sólo AngularJS? ¿MEAN te haría cambiar de opinión, o las limitaciones que has visto en AngularJS limitarían el alcance de un proyecto con MEAN?
Estoy pensando en aprender una tecnología nueva, y pensaba en MEAN o DJANGO.
Hola Carlos,
No me haría cambiar de opinión con respecto a angular. El hecho de usar una tecnología de servidor u otra (en el caso de MEAN express y mongo) no creo que influya demasiado en las ventajas e inconvenientes de la librería que uses en la capa de presentación, excepto en casos en los que la integración es muy grande (meteor, rails+ember), pero esos escenarios tampoco me acaban de convencer, prefiero no estar atado de antemano a un stack tan pesado y rígido.
Un saludo
Hace poco me dieron una breve explicación de este Framework, y yo quedé: «WTF?!!!», no solo por la potencia que brinda, sino también por su dificultad para realizar algunas cosas, en este punto coincido contigo, hay cosas fáciles que se complican al usar Angular :S Llegue por otro articulo, pero me gustó el titulo de este post :D
Gracias, en este momento estoy analizando los frameworks de JavaScript para el desarrollo de Front-End, y bueno, pues empezare con Angular.
Excelente Post. me gustaria preguntarte regresastes a trabajar en visual studio c# ya que ahora en la version 2015 trae soporte hasta para angular jejejeje.. veo mas facil usar el html5, javascript json jquery, ajax con c#, boostrap y css3 hago de todo y facil. me gustaria saber tu opinion bendiciones.
Nunca he usado Visual Studio para desarrollar con javascript. Prefiero un editor (uso emacs, antes sublime) y herramientas de línea de comandos.
Amigo te felicito por este excelente análisis, pensé que era el único que pensaba que angular es un poco repetitivo y cansón. Yo estoy metido de cabeza en un proyecto con angular y ya me toca terminar. Me dejas pensando en que voy a hacer para los proximos proyectos.. xq la verdad no creo que sea tan buena idea dejar de lado los frameworks que nos ahorran trabajo en la mayoría de las ocasiones.
Excelente este post y todos los demás que escribió sobre AngularJS.
Gracias por toda la información!
Alguno de todos los comentaristas de este tan interesante artículo me puede comentar cual es la ventaja de usar un framework con respecto a no usarlo ??
Yo tengo hechos un par de sitios sin usar ningun framework y me resulta de los mas comodo el mantenimiento como el agregar nuevos modulos?
Que me aportaría utilizar un framework ??
Saludos a todos.
Hola Juan, muy buen articulo.
Entonces en conclusión, que otro framework elegirías antes que Angular??
Saludos
Cristian
En las últimas 4 aplicaciones he usado React. No es perfecto, pero me gusta bastante.
Estoy por empezar un proyector CRM y hemos decido usar la Ultima Version de Angular 7 con Mysql, que me recomiendas usar para la parte de Diseño, si uso esto para la Aplicacion.