Esta Angular obsoleto?

desu

Estoy tocando haciendo un cliente SPA en Angular y veo que hoy en día a nivel de arqutiectura se trabaja con stores, ngrx y todo reactivo.

Se basa el Angular moderno en copiar a React/Redux? Elm también se basa en las mismas ideas, menciono lo que la gente conoce más.
Entonces por qué usar Angular?
Que beneficios tiene Angular actualmente? Teneis algun recurso moderno? P.e he estado leyendo:

Contexto: He hecho una SPA sencilla y he utlizado el doble binding de Angular, @input, @output y he hecho las componenetes fuertemente acopladas... Pero si tuviese que tener algo más de complejidad, notificaciones push desde servidor, varias fuentes de actualizacion de los estados... Veo que es una tontería utilizar las herramientas básicas de Angular, solo me creará "technical debt" y la gente leo que te recomienda usar estas arquitecturas / librerias.

Disclaimer: Obviamente se tiene que utlizar la arquitectura correcta y se que hoy en dia mucha gente usa react con redux cuando ni entienden el por que ni lo necesitan. React me la suda y el titulo es clickbait.

kidandcat

Angular se basa en Stores y UI declarativa, como el resto de frameworks web. La ventaja de Angular sobre su principal competidor React es que Angular tiene una forma de hacer las cosas (tiene todas las piezas que vas a necesitar ya encajadas por asi decirlo). Con React por otro lado tienes que ir buscandote el resto de las piezas y encajarlas tu.

Angular puede ser más fácil en entry level, pero por otro lado React te da más flexibilidad.

Aprende el que más te guste, al final sabes uno sabes todos.

1 respuesta
kidandcat

Y entre los dos está Vue que lo está petando porque los devs te dan todas las piezas oficiales, pero que se pueden desacoplar, entonces puedes empezar como Angular, con todo mascadito y preparado, pero conforme avanza el proyecto y/o tus conocimientos, puedes ir desacoplando partes y usar alternativas.

1
desu

#2 Angular se basa en stores? Desde cuando? xd
Yo siempre he pensado que la gracia es el doble binding, los viewChild..

Hacia 3 años que no lo tocava.

1 respuesta
kidandcat

Por mucho dual binding que tengas, ahora todas las apps tienen su estado local (una BD de toda la vida), y en eso se basa, Angular con dual binding sin estado centralizado no lo he visto desde hace 5 años

De hecho la gente que yo conozco que hace cosas en Angular no usan el dual binding

2 respuestas
_Rpv

#4 tocava

4
desu

#5 Es decir lo que he dicho en #1. 5 años no creas... Yo aún lo veo y hay muchos tutos que te lo enseñan. El tour héroes que es el tuto oficial no te lo enseña. Por eso he abierto el hilo porque yo ni sabía que se hiciese el patrón xd

Que recurso existe para angular reactivo? Los que he puesto son decentes?

No me gusta hacer web como hace diez años y encontrarme problemas que ya se han resuelto.

Gracias por tu comentario. Me ha servido, a ver si comenta alguien más. Para 1 semana al año que hago FE me es imposible estar informado.

Entiendo entonces que Input, Output, ViewChild son patrones antiguos si no es casos super sencillos y súper concretos. O nunca usarlos?

1 respuesta
kidandcat

#7 Yo no estoy puesto en angular como para decirte por donde tirar, solo te cuento lo que veo en el curro dia a dia, echale un ojo al twitter de https://twitter.com/Carlillo o preguntale directamente, seguro que está encantado de contestarte

bLaKnI

Joder, y yo que me quedé en jQuery...
El otro dia trasteaba con React y leía sobre su fw mas famoso Native, y aluciné... Como se han "facilitado" las cosas... ¡Antes te lo hacías todo a mano!

Absolutamente todo React se centra en objetos/clases mapeadas contra elementos HTML? Siempre? No permite algo de JS vanilla?

2 respuestas
desu

#5 Ahora estoy mirándome esto en casa y Redux tiene 5 anios... Todos los tutoriales de este y ngrx que veo tienen 1-2 anios... xd "Angular con dual binding sin estado centralizado no lo he visto desde hace 5 años" veo que trabajas en un buen sitio.

En fin, yo aprendí lo que "era" react/elm hace 1 mes o 2 como mucho y de pura casualidad. A partir de mi conocimiento "teorico" hoy me iba a implementar mi propio "ngrx" y he visto los links que he puesto, luego he abierto el hilo por que aun no entiendo que aporta angular. Seguramente nada.

Después de esto tengo curiosidad en comparar internamente redux con librerías reactivas que se usan en back end.

2 respuestas
isvidal

Es increíble la cantidad de palabros que usas para decir que has creado una aplicación básica de angular con 2 componentes

#9 Eso no es React, eso es JSX que no tienen porque ir juntos. Puedes usar React sin JSX pero evidentemente la sinergia es lo que lo hace tan apetitoso.

1 respuesta
desu

#11 Escribo muy mal gramaticalmente pero Intento hablar con propiedad y relacionar conceptos en cuanto al contenido.

Si he dicho algo mal o tienes algo que aportar puedes corregirme. Si no se entiende algo puedo expandir.

A mi me interesaba conocer el estado del arte de las tecnologías de front end y en concreto angular, que es lo que me hacen tocar. En este campo tengo 0 idea y soy ignorante, aprecio lo que podáis aportar. Se que la mayoría de gente de aquí hace web.

Coincido en gran parte con este tío.

isvidal

#9 Y bueno, React es JS no se muy bien que quieres decir con eso de permitirte js vanilla, al final solo es una librería que usas. El codigo sigue siendo js de toda la vida.

Ejemplo que programe ayer para el blog que estoy haciendo en react, puedes ver arriba como accedo a un elemento de DOM fisico y lo incremento en 1 como si fuera javascript de toda la vida.

Dicho esto y hablando de React, Redux tiene mucho hype porque fue el primero, pero ahora react ya trae una api nativa React.Context que no es tan tan tan potente como redux, pero sirve el 999% de las veces, y quizás es mejor punto de entrada para entender bien cómo cambia el flujo de las cosas que Redux desde el principio.

HiGher

#10
https://www.youtube.com/watch?v=SaO-7Lk5hZ8
https://gist.github.com/sw-yx/9bf1fad03185613a4c19ef5352d90a09

Angular va a remolque y por eso ha perdido la tracción de la comunidad.
React no tiene mucho que ver con Elm. Redux fue un intento de replicar "The Elm Architecture" que se hizo famosísimo y la gente acabó considerando React y Redux como un todo, usándolo aunque fuera matar moscas a cañonazos. Si te mola Redux, mira Redux Observable.

1 2 respuestas
kidandcat

#10 'Ahora estoy mirándome esto en casa y Redux tiene 5 anios... Todos los tutoriales de este y ngrx que veo tienen 1-2 anios... xd "Angular con dual binding sin estado centralizado no lo he visto desde hace 5 años" veo que trabajas en un buen sitio.'

Llevo 5 años trabajando principalmente de frontend developer, y mi empresa se dedica unica y exclusivamente a eso, asi que si, trabajo en un buen sitio en cuanto al desarrollo web se refiere

PD: ngrx no es la unica libreria para manejar el estado con angular, de hecho puedes usar redux con angular, es lo que se hacia cuando salió, luego ya sacaron librerias que funcionaban mucho mejor con el ecosistema angular

1
kidandcat

#14 Exacto, de hecho el patrón flux viene de bastante antes incluso que Elm, pero Elm demostró que funcionaba muy bien, luego ya llego Redux, pero Facebook venia varios años usando Flux en sus desarrollos internos, pero era bastante complejo porque lo seguían al pie de la letra, asi que no hicieron nada publico (librerias)

1 respuesta
desu

#14 Menciono react y elm juntos porque son los dos que conozco un poco (aunque no los he utilizado) por nada mas, vue no tengo ni idea de en que consiste o que lo hace diferente internamente. Me gustan esas fuentes que pones a primera vista, me lo mirare.

Para aprender, en mi caso, me interesa hacer ReasonML. Pero tengo demasiadas cosas ahora mismo... Aprovecho estos días que soy js artisian para ponerme al dia en como esta todo y quizás algún día le doy.

#16 Sobre este tema de arquitectura, es lo que he mencionado de que me gustaría comprarlo mejor con como se hace en backend e ,imagino, como se hará en todo lo que es móvil. MVC no se hace desde hace anios pero a mi es lo que me han enseniado en la uni.. xd

1 respuesta
HiGher

#17 Para aprender y trastear, te recomiendo Elm. Sobre todo suponiendo que tienes background de Haskell. Es básicamente Haskell sin higher kinded types (por decisión de diseño) y con menos académicos insufribles en su comunidad

1
desu

Hago update, no hemos usado redux porque no hacia falta pero he logrado darle visibilidad para proyectos mas grandes. Pese a esto he logrado usar stores con servicios y tener todo unidireccional y reactivo con rxjs. Me costo 3 dias de tocar los huevos hasta que me hicieron caso.

Ahora tengo que mirarme un poco situaciones asincronas como se hacen.

1 respuesta
bLero

Hola,

En mi empresa hemos estado desarrollando una App Web en Angular + Node/Express durante los últimos 3 años (y aún seguimos).

Inicialmente tuvimos que decidir que framework/librería utilizar, cumpliendo las siguientes premisas:

  • Tenía que ser Javascript puesto que trabajamos intensivamente con WebGL en el cliente y el servidor era un stack Node/Express por lo que el intercambio de datos entre cliente-servidor y cliente-webGL se simplificaba enormemente.
  • Tenía que ser suficientemente conocido / testado ya que se trataba de una App a muy largo plazo, y con vistas de mantener mucho tiempo.

En aquel momento encontramos 2 alternativas principales: Angular y React, aunque también exploramos otras como Meteor, Ember ... que descartamos rápidamente.

Entre Angular y React en realidad nos hubiese servido cualquiera, de hecho dedicamos un tiempo a probar ambas pero nos decantamos por Angular porque:

  • Es un framework y no una librería, es decir, ya viene todo "montado" para desarrollar una App y era menos propenso a incompatibilidades entre módulos que React.
  • React aún estaba algo en pañales, brillaba sobretodo por generar bundles más pequeños y renderizar más rápido, lo cual lo hacía ideal para la ejecución en dispositivos móviles. Sin embargo, por la naturaleza de nuestra App, sería muy difícil su uso en un dispositivo móvil y por tanto no nos importaba este hecho.

El desarrollo inicial de la app lo comenzamos utilizando los patrones recomendados, es decir, un MVC vitaminado (cada componente tiene su responsabilidad y ciclo de vida, varios tipos de bindings, uso intensivo de rxjs...). Conforme fue creciendo la App nos empezamos a dar cuenta de algunos problemas:

  • El doble binding es el infierno: Al principio nos encantaba y lo usábamos para todo, era simplemente perfecto. Una bananabox y todo se sincronizaba como por arte de magia. Sin embargo, el rendimiento de la app fue mermando progresivamente y de vez en cuando teníamos problemas de llamadas circulares que básicamente ponian la CPU al 100% y petaban la app, siendo estas bastante complicadas de depurar. La solución -> binding unidireccional
  • Con la arquitectura clasica los componentes acaban siendo "sacos de mierda". Aunque en la teoría todo es muy bonito ya que cada componente tiene su responsabilidad, está aislado, etc, cuando varios componentes dependen del mismo estado y pueden alterarlo independientemente, la comunicación con el resto se vuelve insostenible. Me recordó mucho a Android cuando introdujeron los Fragments (analogía de componente), donde la idea estaba bien, pero al final liberaba a las activities para convertir a los fragments en sacos de mierda. La solución fue introducir una librería para la gestión de estado basada en Flux. Revisamos varias alternativas como Akira, NGRX, NGXS, Redux ... y todas tenían sus ventajas e inconvenientes pero al final nos decantamos por NGXS ya que tenia un buen equilibrio entre rendimiento, peso, características y boilerplate necesario para la gestión del estado. El refactor que tuvimos que hacer fue importante, pero a día de hoy estamos muy contentos con cómo ha simplificado los componentes y mejorado la legibilidad de los mismos. Por contra, también decir que hace la depuración más complicada, y que es necesario añadir mecanismos adicionales de log para saber quién escribe en el store en cada momento.

Conclusión para cualquiera que se vaya a adentrar en el mundo de Angular:

Si vas a montar una app web sencilla (1-5 pantallas) que no esperas que crezca con el tiempo, entonces sin duda utiliza la arquitectura recomendada. Vas a desarrollarla más rápido y no vas a tener problemas de rendimiento. Si por el contrario vas a comenzar una app más compleja cuyo desarrollo vaya a tener que mantenerse en el tiempo, entonces lo mejor que puedes hacer es implementar una arquitectura con la gestión de estado centralizada y mantener los componentes lo más desacoplados posible.

3 1 respuesta
Nedaim

Yo llevo usando Angular desde Angular2 y te puedo contar un poco mi experiencia.

Personalmente me costó bastante empezar a encajar las piezas comparado con otras librerías/frameworks, pero como ha dicho ya alguno por ahi tiene una curva de aprendizaje un poco lenta.

Respecto a las capacidades de Angular, en mi opinion es muy potente y con todas las herramientas que tiene se desarrolla extremadamente rápido. Para que te hagas una idea yo ahora mismo mantengo dos proyectos en silex y cuando tengo que hacer una vista nueva la desarrollo de 0 en angular para hacer un mockup y no tener que pelearme con los estilos de los proyectos (que son un infierno heredado). Cuando el mockup esta al gusto de los que mandan lo hago desde 0 en el proyecto de silex y tardo menos que en ir probando las cosas en silex desde el principio.

Sobre lo que comentáis de stores. En principio en Angular, haciendo las cosas bien, no hay ni necesidad ni tanta ventaja en usar una implementación de store. Pero cada maestrillo tiene su librillo, y si alguien está más cómodo usando stores hay buenas implementaciones. Yo la que conozco y he usado es ngrx.

Respecto a la comparación con React. Como ya han dicho anteriormente React no es un framework completo como Angular con todo lo que eso conlleva. Yo con React directamente no he tenido ninguna experiencia pero si probé React Native y fue una de las peores experiencias de mi vida. Fue nada más salir eso sí.

#20 Lo que cuentas me extraña. Que version de angular usabais que os daba problemas con el double binding? Yo ahora mismo tengo una web bastante más grande de lo que comentas y no tengo ningún problema con la arquitectura de Angular. Eso si, con unos cuantos módulos, lazy loading etc...

1 respuesta
B

Respuesta corta, si.

Respuesta larga, no tengo ni puta idea.

bLero

#21

Empezamos con Angular2, y lo quitamos aproximadamente en Angular4.

El problema del rendimiento creo que es más bien intrínseco de la naturaleza de nuestro proyecto. Digamos que abusábamos demasiado del doble-binding (podíamos tener facilmente 1000 objetos por vista bindeados) y era muy fácil caer en llamadas circulares. Básicamente el estado podía actualizarse desde dos sitios diferentes (capa 3D y capa Web), y cuando eso ocurre a la vez da muchos problemas. No creo que esto ocurra en una App Web "normal", de introducción de datos, listados, etc.

Troyer
#1desu:

Entonces por qué usar Angular?

Voy a explicarte por que principalmente se utiliza angular en entornos donde se gana dinero, dejando de lado todos los tecnicismos del sistema, curva de aprendizaje, redundancias o eficiencias.

Angular es el framework (JS) más popular, ya sea por la comunidad o por la enseñanza, tiene una base solida y una gran empresa detrás desarrollándolo (Google). Dentro de los frameworks de javascript angular es sin duda el que más estandarizado tiene el sistema de directorios, paquetes y directivas, dando de entrada a los desarrolladores una caja de trabajo estandar en la que empezar o en el supuesto caso de que les caiga un proyecto de otra persona -muy importante esto, continuar.

En resumidas cuentas esto quiere decir que si eres un desarrollador de angular y te pasan un proyecto a medias, si se han seguido los procedimientos estándares deberías de tardar poco tiempo en poder seguir avanzando el proyecto.

El día que haya otro framework con una estandarización similar y menor riesgo de perder el proyecto si una persona falla, seguramente angular deje de ser el framework favorito de las empresas.

Definición de framework

Resumen: Angular se usa tanto porque te permite ciclar a los picateclas cuando deciden cobrar un sueldo decente y aumenta las ganancias de la empresa.

JuAn4k4

#19 Si el estado lo has centralizado y lo has hecho con observables, el async es tan trivial como que el resultado de tu operación async es un observable también.
Es más, En angular su servicio http devuelve observables. Por lo que sería subscribe al async y next al estado central.

1 respuesta
desu

#25 Si es lo que hice.

Hoy me he re implementado una version simplificada de redux para añadir la capa de store-actions y tener immutabilidad de estados... Para mi caso de uso overkill pero.. He entendido bastante bien la idea ya, lo complicado es cuando tienes paralelismo y eventos que modifican/leen de varios states sea push de servidor o lo que sea.

En mi caso he decidido por tener solo un service con 2 estados que necesito conocer por entidad, tengo listas y el elemento seleccionado, y a cada modificacion del usuario propago los cambios... Sencillo y claro.

No sé como de bien esto de tener la "selectedEntity"... No se me ha ocurrido por ahora otra manera más limpia de pasar este elemento al resto de vistas.

Zerokkk

Chavales, el double-binding está genial, pero LÓGICAMENTE tiene sus cons.

Si se tiene una vista muy grande, con muchos componentes que realizan muchos cambios de estado y/o operaciones costosas, el double binding es algo que debe evitarse a toda costa, y debe cambiarse el change detection para hacerse manual:

@Component({
    selector: 'app-place-page',
    templateUrl: './place-page.component.html',
    styleUrls: ['./place-page.component.scss'],
    changeDetection: ChangeDetectionStrategy.OnPush
})

(aún así, para la gran mayoría de casos, esto no es necesario).

Por otra parte, creo que es importante dar cierto crédito a que la versión 8 ha mejorado el rendimiento drásticamente (al menos en las apps de Ionic creadas con Angular, se ha notado mogollón). Esto no quita que Angular requiera de cierta comprensión de cómo funciona si queremos conseguir un buen rendimiento, ni que no tengamos que a veces tirar de herramientas externas para mejorarlo (como sería Ngrx cuando se manejen ingentes cantidades de datos que deban controlarse en una store centralizada; algo que no pasa siempre, pero que en muchos casos es necesario).

Yo diría a día de hoy, que si hay que hablar de debilidades de Angular, éstas serían las siguientes:

  • Lo sumamente overengineered que está. Hay tantas herramientas, muchas semi-redundantes entre sí, que ceñirse al 100% a la arquitectura propuesta, se vuelve realmente difícil.
  • Pobre manejo de los módulos que nos lleva a necesitar, para SPAs, el típico "módulo de componentes" que importamos en los módulos cargados en loadChildren. Lo óptimo sería importar directamente los componentes en los módulos donde son necesarios, sin que nada pete, y que haya un check que evite la recarga de un módulo que se ha cargado anteriormente. Al final, la solución requerida es poco elegante, a mi parecer.
  • El change detection por defecto es algo que me parece tremendamente útil, pero que entender y manejar para optimizar una app puede ser más dificultoso de lo que debería, además de que a veces hace checks sin sentido.
  • El que en las templates no se pueda usar *ngIf y *ngFor a la vez en el mismo elemento, puede resultar un poco tedioso. Que se soluciona fácil, vale, pero es algo que debería poder hacerse.
  • Los cambios nuevos que han implementado al @ViewChild, si bien le dan más dinamismo, creo que lían un poco al personal. Debería seguir habiendo una opción por defecto que no requiriese estipular el parámetro "static" (supongo que poniendo este a "true" por defecto).
  • Mucho ojo con abusar de RxJs. Es genial, lo sé, y a mí me gusta mucho, pero sobreutilizarlo puede ser problemático y un puto lío. Si se quiere usar para más que unas pocas cosas, es mejor tirar de Redux.

Por lo demás, a mí el framework me gusta y me facilita mucho la vida. O bien trabajo con Angular, o bien directamente tiro a hacer una web simple sin siquiera Jquery. Quizá algún día dé el salto a React o Vue, pero es que por ahora sencillamente no veo que haga falta.

pd: eso sí, HUID de angularjs y MIGRAD las apps de ng2/3/4 a la actual, que solventa muchas cosas.

1

Usuarios habituales

  • desu
  • JuAn4k4
  • bLero
  • Nedaim
  • HiGher
  • kidandcat
  • isvidal