Por qué Angular (2, 4, 5 y 6) no mola

Menudo ‘anzuelo de clics’, pensaréis.. pero creedme, hay varios argumentos muy válidos.
En primer lugar, al equipo Angular, agradecerle los tres años dedicados a crear el nuevo Angular 2.0. Pero vuestro framework no mola. Y os diré por qué.
He creado docenas de aplicaciones con Angular 1.X. Grandes como la web GoAbout y algunos muy pequeños como Sporteventa. Me encantaba Angular 1.X.
Sin embargo, hay un principio simple que he seguido en todos mis proyectos, por grandes que fueran. Este principio dice:

¡Mantenlo sencillo, tonto!

Y es aquí exactamente donde el nuevo Angular falla.
Aunque la curva de aprendizaje de Angular 1.X no era la ideal, el propio framework era más o menos simple. No requería TS, compilador HTML, CLIs, una estructura específica, webpack, Three shaking, compilación AOT y otros. Funcionaba. Podías insertar un ‘angular.min.js’ en el fichero y empezar a escribir código (aunque usuarás Gulp para recargar o construir la aplicación).
La idea de un buen framework es que se empieza con algo sencillo y lo vamos complicado donde y cuando quieres. Con Angular se va en el sentido opuesto.
Vamos a detalla dónde Angular es innecesariamente complicado:

1. Está escrito en TypeScript

No os confundáis. TypeScript añade características buenas a JavaScript, como los tipos, y no sólo eso. Pero, ¿realmente lo necesitamos? No estoy codificando software para la NASA, sólo escribo aplicaciones web. Y me gustaría ser yo quien decide que lenguaje voy a usar. No tú. Si quiero usar TS, lo usaré. ¿Pero que pasa si sólo estoy haciendo un prototipo sencillo y no necesito TS?
JavaScript se hizo muy popular porque era sencillo de aprender, pero con tipos/intefaces/decoradores, se vuelve complejo de nuevo. Ahora hay cosas nuevas que aprender, necesitas un entorno para comprobar errores y un compilador para convertirlo en JavaScript. Hemos convertido el JavaScript en Java.
Soy consciente de que aún puedes usar JS en Angular. Pero en la práctica se hace imposible, porque tenemos que tratar con el hecho de que todo lo demás que rodea Angular está en TS (como plugins o documentación).

El HTML de Angular deja de ser HTML válido

Piensa en esto. El equipo de Angular 2 tuvo que escribir un compilador de ‘Angular HTML’ a HTML. Porque algunas de las etiquetas que usa Angular no son HTML válido.
No, este compilador no hace que el HTML sea más legible como Jade (Pug). El único propósito de este compilador es cambiar las etiquetas de Angular en algo válido y además añadir un montón de basura en tu HTML final.
Y no sólo eso. El compilador proporciona una gran cantidad de trazas inútiles, así que cuando tengas un error en tu HTMl, buena suerte para encontrarlo. La aplicación entera no arrancará hasta que lo encuentres.
¡Y además! Ahora no puedes usar Jade (Pug) en tu nuevo proyecto porque, como he comentado antes, el HTML ya no es válido y tendrás errores al compilarlo (incidencia en github).

Angular tarda una infinidad en recargar el código

Lo que mas me gusta de las aplicaciones JS es que puedes cambiar un trozo de código y ver los resultados inmediatamente en el navegador.
Bueno, con Angular 2.0 esto ya no es así. Tienes un portátil de cuatro núcleos y tara entre 3 y 5 segundos en recompilar una aplicación vacía. Para aplicaciones como ng2-admin tarda de 10 a 12 segundos. ¿Qué broma es esta?
Usando el antiguo Angular 1.X y una configuración sencilla de Gulp he conseguido recargar las páginas en medio segundo.

Enorme peso de la aplicación inicial

Esto es algo de lo que todo el mundo se queja desde hace tiempo. Sólo Angular 2.0 con RxJS pesa alrededor de un mega. Es como seis veces más que la versión anterior de Angular. Y 10 veces más de lo que espero que mis usuarios se descarguen con una conexión 3G.
Sé que Angular 4.0 será más pequeño, sé que puedes usar Tree Shaking y compilación ‘ahead-of-time‘ para reducirlo entre 3 y 5 veces.
Pero aún así. Piensa en ello. El código inicial de Angular es tan grande y complicado que lo han tenido que complicar más para reducir el código. En otras palabras, React o Angular 1.X son suficientemente pequeños desde el primer momento que ni siquiera tienen que lidiar con estas técnicas de optimización.
Podría continuar la lista pero creo que he dado argumentos suficientes.

Conclusión

Angular 2 no es tan malo. Es completamente modular, sigue una estructura concreta, usa tipos y te permite, en teoría, escribir código con menos errores.
Pero en mi opinión, las cosas deberían ser más sencillas al principio. Angular no lo es, es excesivamente complicado.
Hago aplicaciones web, no software para naves espaciales. Angular ha introducido una complejidad excesiva e innecesaria, lo que significa:

• Más puntos de error. Sin trazas útiles, es un dolor de cabeza que nos lleva a perder mucho tiempo.
• Es difícil configurar el framework a unas necesidades específicas. Nos peleamos con el framework en lugar de escribir la aplicación
• Es difícil iniciarse rápidamente. A veces, trabajo con desarrolladores menos experimentados y quiero que sean capaces de hacer cambios sin tener que mirar 200 tutoriales.

¿Necesitaría toda esta complejidad en mis pequeños proyectos? Seguramente no. ¿En proyectos de tamaño medio? No lo creo. ¿En aplicaciones empresariales donde 10 equipos trabajan en la misma aplicación? Si, quizás, entonces toda esta complejidad/modularidad/precompilación es algo bueno. Pero si estos equipos deciden usar otro framework, tal vez no necesiten tanta gente trabajando en él. 😉
Podría entender toda esta complejidad si fuera imposible hacer una buena aplicación web sin ella. Pero como todos sabemos, es posible e incluso más fácil. Basta con echar un vistazo a otros frameworks como Vue.js (mi favorito actualmente) o basado en React.
P.D. Adam ha añadido un interesante comentario (en inglés) contra mis argumentos que recomiendo leer si queremos conocer la otra parte de la historia. 🙂

Nota: puedes encontrar el artículo original en https://medium.com/dirtyjs/why-angular-2-4-5-6-sucks-afb36567ad68