Una hoja de ruta de Angular – El pasado, el presente y el futuro de Angular

Actualizaciones de Angular: Qué hay de nuevo en la versión 11

A partir de noviembre de 2020, la versión 11.0.0 de Angular ya está disponible. Aunque esta versión trae muchas actualizaciones a la plataforma, las características más significativas incluyen construcciones más rápidas con TypeScript 4.0, arneses de prueba de componentes y actualizaciones de ESLint.

Paleolithic JavaScript – SproutCore

En el principio, estaba SproutCore. Fue el primer marco de trabajo completo de JavaScript destinado a facilitar la construcción de aplicaciones web de una sola página con calidad de escritorio. No es que esto no fuera posible antes. Cuando Google lanzó Gmail, mostró al mundo que las aplicaciones web podían sustituir a las complejas aplicaciones de escritorio. Google incluso puso a disposición del público el kit de herramientas Closure, un conjunto de bibliotecas y un compilador de optimización que utilizó para crear Gmail.

El problema era que las herramientas Closure de Google no eran muy fáciles de desarrollar. Se basaban en gran medida en Java, lo que alejaba a los desarrolladores web que estaban acostumbrados a trabajar con JavaScript, PHP, Ruby y Python. Gmail fue una gran demostración de lo que era posible, pero el desarrollo de aplicaciones similares todavía se sentía fuera del alcance de muchos.

Algunos desarrolladores valientes consiguieron crear increíbles aplicaciones de una sola página utilizando una combinación de jQuery, cinta adhesiva y esperanza. Mientras que estas aplicaciones parecían increíbles para los usuarios finales, para los desarrolladores que trabajaban en ellas, las aplicaciones se convirtieron rápidamente en enormes montones de deuda técnica que hicieron que el equipo de desarrollo temiera ir a trabajar por la mañana.

Como resultado, algunos desarrolladores emprendedores empezaron a trabajar en frameworks que pondrían aplicaciones similares a Gmail al alcance de los desarrolladores web de todo el mundo. SproutCore fue el primero de estos marcos en despegar. Venía con un conjunto completo de widgets que hacían posible construir aplicaciones web complejas sin siquiera tocar HTML o CSS.

Esto terminó siendo genial para los antiguos desarrolladores de escritorio que habían sido arrastrados pateando y gritando a la web. Surgieron varios frameworks más con objetivos similares; GWT y Cappuccino fueron los más destacados. Estos frameworks incluso evitaban JavaScript transpilando otros lenguajes a JS. De nuevo, esto era genial para los desarrolladores de escritorio. Pero dejaba fuera a los apasionados desarrolladores web y les hacía sentir que sus habilidades en HTML, CSS y JavaScript, ganadas con tanto esfuerzo, no eran valiosas.

Esto dejaba un hueco para un framework que realmente abrazara la web, en lugar de tratar de enyesar sobre ella y fingir que era otra cosa. Aparecieron un par de primeros frameworks (Backbone y Knockout), y lograron un éxito moderado. Ember también apareció por esta época. Tomó SproutCore, lo redujo a su mínima expresión, y trató de reconstruirlo en algo realmente amigable para la web. Ember quería ser el Six Million Dollar Man del mundo de JavaScript: reconstruido mejor, más fuerte y más rápido.

Ninguno de estos frameworks se hizo popular. El mundo estaba esperando algo mejor. En 2010, ese algo mejor apareció: se llamó Angular.

La edad de oro de Angular

Incluso antes de que se lanzara la versión 1.0 de Angular, éste tomó por asalto el mundo del desarrollo front-end. Por fin teníamos un framework JavaScript fácil de usar que trataba al HTML como un ciudadano de primera clase. Los desarrolladores y los diseñadores podían ahora trabajar juntos para construir increíbles aplicaciones de una sola página. Esto supuso un alivio para los diseñadores, que se habían sentido molestos y ofendidos porque los antiguos frameworks habían tratado el HTML y el CSS como herramientas para bárbaros, herramientas que ningún desarrollador civilizado debía tocar.

Lo primero que pareció mágico a los desarrolladores que probaban Angular por primera vez fue la vinculación de datos bidireccional. Antes de esto, la mayoría de los desarrolladores sólo habían visto este tipo de vinculación de datos en frameworks de escritorio como WPF y Windows Forms. Era fantástico poder vincular formularios y otros elementos de la interfaz de usuario a objetos del modelo de JavaScript. Aunque la vinculación de datos bidireccional podía causar problemas de rendimiento cuando se usaba en exceso, los equipos que la utilizaban con criterio descubrieron que Angular les permitía crear aplicaciones frontales complejas mucho más rápidamente que antes.

Angular demostró ser popular por algo más que la fácil vinculación de datos a elementos HTML. Las directivas de Angular proporcionaron una manera fácil de crear componentes HTML + CSS reutilizables. Aunque otros frameworks de JavaScript proporcionaron esto antes de Angular, Angular fue el primero que se hizo extremadamente popular. Los componentes reutilizables llevaban mucho tiempo en uso en los frameworks del lado del servidor. Los controles de usuario de ASP.NET y las plantillas parciales de Rails y Django son sólo algunos
ejemplos.

Por último, Angular popularizó la inyección de dependencias en el mundo del desarrollo front-end. La inyección de dependencias había sido popular durante mucho tiempo en las aplicaciones empresariales, que es quizás la razón por la que no se había puesto de moda en el mundo de JavaScript. Los desarrolladores de front-end han sido durante mucho tiempo reacios a lo que consideran patrones de diseño de software empresarial innecesariamente complejos. Esta preocupación no carece de mérito. ¿Alguna vez, en el curso de la escritura de una aplicación, te has dicho «Lo que realmente necesito aquí es un «SimpleBeanFactoryAwareAspectInstanceFactory?»

La inyección de dependencia, sin embargo, ha demostrado su valor. Y Angular hizo que la inyección de dependencia fuera fácil de usar para una audiencia que no la había usado mucho en el pasado. ¿Necesitas un cliente HTTP? ¿O quizás quieras hacer alguna animación? No hay problema. Angular tenía servicios incorporados para eso. Sólo tienes que pedirlos, y Angular los inyectará en tus componentes. No es necesario instanciar nada por ti mismo.

¿O quizás querías usar los objetos window o location del navegador sin que fuera imposible probar tus componentes fuera de un navegador? Angular lo tiene cubierto también, con sus servicios incorporados $window y $location. En tiempo de ejecución, obtendrías los objetos del navegador que esperabas. Y cuando se ejecutaban pruebas unitarias del lado del servidor en Node.js, podías pasar servicios simulados a tus componentes para asegurarte de que se comportaban como se esperaba en varios escenarios.

Si todo esto no fuera suficiente, Angular también hizo que fuera sencillo registrar e inyectar tus propios servicios. Para los desarrolladores que estaban acostumbrados a vincular todos sus datos al DOM y esperar lo mejor, esto era impresionante. Si estuvieras escribiendo una nueva aplicación de front-end que llamara a APIs que le costarían mucho dinero a tu empresa si se sobreutilizara, probablemente preferirías poder escribir pruebas antes de tiempo para asegurarte de que tu aplicación no intenta hacer algo como llamar a la API de Twilio 800 millones de veces.

Así que crearías un servicio Twilio que se inyecta en tiempo de ejecución. En el momento de las pruebas, crearías un servicio falso que registre el coste de cada llamada a la API que tu aplicación intenta hacer. Escribirías pruebas que cubrieran los escenarios de uso más comunes y te asegurarías de que estos escenarios no provocaran que tu empresa recibiera una factura de 7 cifras. En general, la mayoría de los desarrolladores descubrieron que las directivas de Angular combinadas con la inyección de dependencias permitían escribir aplicaciones frontales modulares y comprobables mediante técnicas de ingeniería de software probadas. Muchos equipos de desarrollo decidieron que esto resultaba en un estado feliz de las cosas, y decidieron apostar por Angular.

¿El declive de Angular? El auge de React

Si bien las cosas eran en su mayor parte geniales en el mundo de Angular, no todo era sol y chupa. Los desarrolladores empezaban a tener graves problemas de rendimiento cuando intentaban vincular demasiados objetos modelo a demasiados elementos del DOM. Algunas aplicaciones se ralentizaban hasta el punto de no poder avanzar. Las llamadas directas a $digest y otros hechizos de magia negra empezaron a ser necesarios para conseguir un rendimiento aceptable. Alrededor de la misma época, apareció un nuevo retador: React. Al principio, React no parecía suponer un gran peligro para Angular. Después de todo, estos raros de React se habían tomado la molestia de inventar JSX, que se parecía mucho a una forma de mezclar el marcado en tu código. ¿No nos habíamos tomado muchas molestias para inventar los lenguajes de plantillas por la razón explícita de evitar mezclar el marcado y el código?

Como resultó, el enfoque de React fue bastante popular en la comunidad de desarrollo front-end. Sin embargo, no se disparó su popularidad. Angular seguía siendo dominante, y parecía que iba a seguir siéndolo. Hasta que la popularidad de Angular recibió una buena patada en los dientes de una fuente inesperada: el propio equipo de Angular.

La introducción de Angular 2

Angular 2 se anunció por primera vez en la conferencia ng-europe de 2014. Los planes del equipo de Angular fueron un shock para la comunidad de Angular, por decir lo menos. La reacción de los desarrolladores de Angular fue rápida y negativa… y no sin razón. Angular 2 se desharía de muchos conceptos conocidos de Angular 1, introduciendo un nuevo e incompatible lenguaje de plantillas (y oh, por cierto) también se programaría utilizando un lenguaje completamente nuevo.

AngularJS

Aunque tanto Angular 1 como Angular 2 se llamaban ‘Angular’, en realidad eran frameworks muy diferentes con algunas cosas en común. Para evitar confusiones, el equipo de Angular comenzó a referirse a la versión antigua de Angular como ‘AngularJS’, y a la nueva versión simplemente como ‘Angular’. Esto tiene un sentido intuitivo ya que AngularJS fue escrito en JavaScript, y Angular no. Para mantener clara la distinción entre los frameworks, me referiré a Angular 1 como AngularJS de ahora en adelante.

Como resultado de todo esto, los desarrolladores de AngularJS perdieron la fe en el futuro del framework. Amenazaron con pasarse a un nuevo framework en futuros proyectos, y eso es precisamente lo que hicieron muchos de ellos. React fue el mayor beneficiario del éxodo masivo de AngularJS.

Aunque React no hizo tanto como AngularJS, en cierto modo eso fue positivo. Si usas una librería de vistas que no intenta incluir todo más el fregadero de la cocina, es mucho más difícil que los desarrolladores de esa librería te tiren de la manta en el futuro. Al principio, el uso de React era un poco complicado en comparación con AngularJS. Tenías que improvisar un mosaico de librerías sólo para cubrir la funcionalidad que AngularJS proporcionaba fuera de la caja.

Muchos equipos vieron esto como una buena manera de reducir el riesgo, porque era poco probable que los desarrolladores de todas esas bibliotecas decidieran hacer cambios de ruptura incompatibles hacia atrás al mismo tiempo, que es esencialmente lo que Angular había hecho.

La aparición de Vue

Para agravar los problemas de AngularJS, otro marco llamado Vue apareció más o menos al mismo tiempo que el drama sobre Angular 2 estaba ocurriendo. Vue se inspiró en AngularJS pero pretendía simplificarlo y deshacerse de lo que el creador de Vue consideraba una complejidad innecesaria (por lo que Vue resultaba muy familiar para los desarrolladores de AngularJS existentes). Vue proporcionó un refugio seguro para muchos desarrolladores de AngularJS que no querían pasarse a React.

Esto no significa que los desarrolladores de AngularJS no estuvieran esperando pacientemente la aparición de Angular 2. Pero está claro que hubo un éxodo masivo de AngularJS a React y Vue debido a la incertidumbre causada por los planes para Angular 2.

Resurgir de las cenizas con Angular 2

Finalmente, Angular 2 fue lanzado. Como era de esperar, eliminó muchos conceptos familiares de AngularJS pero mantuvo algunas de las mejores piezas como los servicios y la inyección de dependencias. Afortunadamente para la cordura de los desarrolladores, Angular utiliza TypeScript simple y no una bifurcación como se planeó originalmente.

Para hacer las cosas más confusas, el equipo de Angular mantuvo un fork del nuevo framework que utilizaba el lenguaje de programación Dart en lugar de TypeScript. Inicialmente, las versiones de TypeScript y Dart se desarrollaron de forma sincronizada, generadas a partir de una única base de código. Eventualmente, las versiones TS y Dart de Angular decidieron tomar caminos separados, y Angular Dart ahora existe por su cuenta.

Aún con esta confusión, la popularidad de Angular comenzó a aumentar de nuevo después del lanzamiento de Angular 2. Sucedió lentamente. Como suele ocurrir en el desarrollo de software, las tendencias cambiaron. Los desarrolladores se dieron cuenta de que un framework grande y con las pilas puestas podría ser realmente útil. Después de todo, cuando tu aplicación crece lo suficiente, acabas necesitando realmente todas esas pilas.

Los desarrolladores de empresas, en particular, comenzaron a regresar a Angular. Esto tiene sentido. Normalmente, cuando empiezas una aplicación web empresarial, sabes que va a ser compleja. No tiene sentido empezar con un pequeño MVP cuando sabes desde el principio las 87 cosas que se espera que haga tu aplicación.

¿Dónde está Angular 3?

Aunque Angular 2 no era perfecto, muchos desarrolladores de aplicaciones web complejas empezaron a darse cuenta de que el nuevo y mejorado Angular se ajustaba a sus necesidades. Afortunadamente para ellos, Angular tenía algunas mejoras emocionantes en el almacén. Y lo que es más importante, el equipo de Angular demostró que podía publicar de forma consistente nuevas versiones del framework con pocos cambios de ruptura entre versiones

En un movimiento que pareció extraño en su momento, el equipo de Angular decidió saltarse por completo la versión 3 y pasar a la 4. Esto se hizo por una buena razón: el equipo que trabajaba en el paquete de enrutadores de Angular ya se había adelantado y había lanzado la versión 3, mientras que el resto de Angular seguía en la versión 2.3. Decidieron mantener todas las versiones de los paquetes de Angular sincronizadas de cara al futuro, y subir todo a la versión 4 para la próxima versión era la forma más fácil de conseguirlo.

Angular 4

Angular 4 tuvo algunos cambios significativos, incluyendo la adición de la compilación anticipada, que dio lugar a pequeños paquetes de JavaScript de producción y un menor tiempo de carga de la aplicación. Se añadió soporte para el renderizado del lado del servidor, lo que supuso un impulso para los equipos que querían renderizar su aplicación antes de tiempo para mejorar el rendimiento de la carga inicial. Se añadieron muchas otras mejoras en todo el marco, pero la actualización de las aplicaciones de Angular 2 a 4 fue rápida e indolora en la mayoría de los casos.

Angular 4.3 y Angular 5

Angular 4.3 añadió un nuevo cliente HTTP más fácil de usar que el antiguo servicio HTTP. En Angular 5, el antiguo servicio HTTP quedó obsoleto y sería eliminado en la siguiente versión. A pesar de este inconveniente, hubo relativamente pocas quejas porque la actualización en la mayoría de los casos fue sencilla. Angular 5 también añadió un mejor soporte de internacionalización y más optimizaciones de construcción.

Angular 6 y 7

Angular 6 y 7 fueron decepcionantes para algunos desarrolladores. No hubo grandes cambios, pero sí muchas pequeñas mejoras en la calidad de vida, especialmente en las herramientas de Angular CLI. La disminución del número de cambios visibles no es una indicación de que el equipo de Angular haya dejado de innovar. Por el contrario, muestra que el framework está maduro, por lo que el equipo de desarrollo es ahora libre de hacer más trabajo entre bastidores, corrigiendo errores y mejorando el rendimiento.

La estabilidad del framework desde el lanzamiento de Angular 2 ha atraído a algunos desarrolladores de la vieja escuela de AngularJS de vuelta al mundo de Angular. También ha atraído la atención de los equipos de desarrollo empresarial. Cuando se construyen aplicaciones empresariales que pueden vivir durante décadas, lo ideal es utilizar un marco de trabajo que tenga nuevas versiones en un calendario predecible, pero que no cambie demasiado rápido. Un desarrollador que sólo haya utilizado Angular 2 podría estar funcionando y contribuyendo a una aplicación de Angular 7 en cuestión de minutos.

Angular 8 y Angular Ivy

Y eso nos lleva a la actualidad. Como hemos visto, Angular ha recorrido un largo camino. Ha pasado de ser amado por los desarrolladores web a ser denostado a ser admirado, aunque todavía no vuelve a ser amado como en sus inicios.

En el horizonte, tenemos Angular 8. Se ha hecho una tonelada de trabajo en Angular 8 para facilitar su uso con el sistema de construcción Bazel, lo cual es una noticia absolutamente increíble para los 3 desarrolladores que lo están usando fuera de Google. Lea sobre los cambios de Angular 8.

Más emocionante, sin embargo, el equipo de Angular está trabajando duro en un nuevo renderizado llamado Angular Ivy. Se pretende que sea un reemplazo del renderizado actual. En su mayor parte, las aplicaciones actuales no necesitarán hacer ningún cambio para utilizar Angular Ivy.

Si Angular Ivy es un reemplazo drop-in, ¿por qué los desarrolladores deberían preocuparse? Dos razones importantes: la velocidad y el tamaño del paquete, dos preocupaciones muy importantes. Durante unos años, parecía que los desarrolladores web se habían vuelto un poco locos. Los equipos enviaban paquetes de JavaScript de 5 MB, 10 MB o incluso más, y pensaban que no había ningún problema. Después de todo, las aplicaciones funcionaban perfectamente en los MacBook Pros con i7 de los desarrolladores, así que deberían funcionar bien para todo el mundo, ¿no?

Desgraciadamente, en el mundo real, no todo el mundo tiene el último y mejor hardware. Cientos de millones de personas acceden a Internet únicamente con teléfonos Android antiguos con una potencia de procesamiento ligeramente superior a la de una patata, a través de conexiones a Internet sólo un poco más rápidas que el acceso telefónico. Para estos usuarios, un enorme paquete de JavaScript tarda una eternidad en cargarse, y aún más en ser analizado y ejecutado por su dispositivo. Incluso en casos menos extremos, hay innumerables usuarios en todo el mundo que no utilizan el último y mejor hardware. Para ellos, las aplicaciones masivas de JavaScript son utilizables (pero dolorosas).

Angular Ivy

El renderizador Angular Ivy ayudará de varias maneras:

1. Se está escribiendo pensando en la eficiencia, por lo que realizará las mismas tareas ejecutando muchas menos instrucciones de la CPU. Esto mejorará tanto la duración de la batería como la cordura de los usuarios con dispositivos poco potentes.
2. El renderizador se escribirá de forma mucho más modular que el actual. Esto hará que sea mucho más susceptible a la eliminación de código muerto. Como resultado, su paquete de JavaScript de producción incluirá sólo el código que se necesita para ejecutar su aplicación, en lugar de agrupar todo más el fregadero de la cocina como sucede a menudo con el actual renderizado.
3. Además de la reducción del tamaño del paquete y la mejora de la velocidad de renderizado, Angular Ivy tiene otras pocas mejoras de calidad de vida para los desarrolladores de Angular. Los tiempos de reconstrucción son significativamente más rápidos. Así que si estás ejecutando tu aplicación en modo de desarrollo y esperando a que aparezcan tus cambios, ahora vas a pasar mucho menos tiempo esperando.
4. Se ha mejorado la comprobación del tipo de plantilla, lo que significa que detectarás más errores en tiempo de compilación en lugar de en tiempo de ejecución. Los errores de plantillas en tiempo de ejecución son molestos, porque o bien te muerden durante las pruebas, o bien muerden a tus usuarios cuando intentan usar tu aplicación.
5. El compilador de plantillas de Angular Ivy generará código legible para los humanos, cosa que el actual compilador del motor de vistas no hace. Esto será muy útil cuando se trate de rastrear errores difíciles en las plantillas.

El resultado neto: aplicaciones más pequeñas, aplicaciones más rápidas, desarrolladores más felices y usuarios más felices.

Angular 9

Aquí tienes una visión general de Angular 9.

Los aspectos más destacados son:

• Características de Angular incorporadas
• Desarrollo maduro con Angular
• Entendiendo los motores de vista de Angular
• Angular Ivy resuelve problemas de larga data
• Angular Ivy y Mobile
• Selector-less Directives
• Mejoras en los diagnósticos de Angular
• Internacionalización con Angular Ivy
• DI y Type-Safe en Angular 9
• Cambios en la inyección de dependencias en Angular Core
• Angular Benchmarks (Angular 8.2.7 vs. 9.0.0-next.5)

Angular 10

La versión 10.0.0 de Angular se lanzó a finales de junio de 2020. Una versión importante, Angular 10 incluye cambios como un nuevo selector de rango de fechas en Angular Material, la actualización de las versiones de TypeScript, actualizaciones de la versión de la biblioteca, y más.

Las nuevas características incluyen:

• Interfaz del compilador Ngtsc
• Configurar tiempos de espera asíncronos
• Informe de archivos de bloqueo antiguos
• Cálculo perezoso de basePaths
• Fusión de archivos de traducción
• Mapeo explícito

Angular 11

La versión 11 de Angular.0.0 fue lanzada en noviembre de 2020. La versión principal de Angular 11 proporciona actualizaciones en toda la plataforma, incluyendo la CLI y el marco de componentes.

Las características significativas incluyen:

• Construcciones más rápidas con TypeScript 4.0
• Harnesses de prueba de componentes
• Actualización de ESLint
• Previsión actualizada del servicio de idiomas
• Soporte actualizado de sustitución de módulos en caliente (HMR)
• Informes y registros mejorados
• Inclusión automática de fuentes

Pasado de Angular, Presente y Futuro

Si has estado usando Angular desde sus inicios hasta ahora, ¡felicidades! Aunque ha habido muchos momentos difíciles, hemos terminado con un framework rápido y moderno que es divertido de usar.

Si eras un desarrollador de AngularJS pero te has pasado a React, Vue o cualquier otra cosa, te animo a que vuelvas a mirar Angular. Vale la pena tu tiempo, incluso si decides seguir con lo que estás usando ahora.

Y si nunca has usado Angular, ¿por qué no le das una oportunidad?

Acabamos de hacer un viaje relámpago por el pasado, el presente y el futuro de Angular. Sin duda, ha sido todo un viaje. Independientemente de tus antecedentes en Angular, ¡espero que hayas disfrutado del recorrido!

¿Con qué framework trabajas y por qué? Si tienes preguntas o comentarios asegúrate de introducirlos abajo.

¿Buscas componentes de interfaz de usuario agnósticos al framework? GrapeCity tiene un conjunto completo de componentes de interfaz de usuario de JavaScript, incluyendo rejillas de datos, gráficos, indicadores y controles de entrada. También ofrecemos potentes componentes de hoja de cálculo, controles de informes y vistas de presentación mejoradas. Tenemos un profundo soporte para Angular (así como React y Vue) y nos dedicamos a extender nuestros componentes para su uso en los modernos frameworks de JavaScript.