El estado de Angular

Hoy en esta presentación, quiero compartir con ustedes cuál es el estado actual de Angular. Sé que este es un evento general de JavaScript, más que una conferencia específica de Angular, por eso quería compartir algunas palabras sobre en qué ha estado trabajando nuestro equipo en Google.

Obviamente, estamos construyendo un framework, ¿verdad? Proporcionamos una API ergonómica para que puedas desarrollar componentes. Al componer tus componentes juntos, puedes desarrollar una interfaz de usuario web. A partir de ahí, tenemos un equipo de herramientas de Angular que es responsable de construir la interfaz de línea de comandos de Angular. El CLI de Angular te permite generar rápidamente aplicaciones Angular y también construir para producción, optimizando los activos al máximo para que tus usuarios obtengan los paquetes de JavaScript más pequeños posibles, así como una experiencia de carga optimizada en el inicio. El equipo de CLI de Angular también trabaja en la experiencia de migración. Así que de una versión a otra, queremos que tu experiencia de migración sea lo más suave posible. En general, apuntamos a que Angular sea siempre actualizado. O simplemente ejecutando ngupdate, puedes obtener la última versión de Angular y incluso integrarlo como parte de tu proceso de CI, obteniendo actualizaciones automáticas, solicitudes de extracción, ¿por qué no? Algunas personas de KOM lo están haciendo.

Por otro lado, también tenemos el equipo de Componentes de Angular. El equipo de componentes está trabajando en el CDK, que es el Component Development Kit. El CDK proporciona una base para el desarrollo de componentes de interfaz de usuario. Por ejemplo, utilizando esta base, puedes estilizar la cantidad mínima de componentes que proporcionamos allí para tus propios propósitos, así como utilizar las herramientas que estamos construyendo para aplicaciones accesibles de Angular. El equipo de componentes también está trabajando en componentes de interfaz de usuario de Angular basados en la especificación de Material. Así que si tienes una aplicación Angular que sigue esta especificación, puedes tomar directamente estos widgets y ponerlos en tu aplicación y todo funcionará sin problemas.

Además de eso, también tenemos un pipeline de internacionalización. Tenemos un servicio de idioma, enrutador, animaciones, y así sucesivamente. En general, proporcionamos este stack de desarrollo integrado para la interfaz de usuario web. Y creo que lo más único de esto es que ha sido probado en batalla en más de 2,000 aplicaciones web en Google. Estas aplicaciones web van desde un pequeño panel interno, por ejemplo, hasta aplicaciones empresariales grandes como la Consola de Google Cloud. Tiene millones de líneas de TypeScript y Angular en su interior. Nosotros, como ingenieros del equipo de Angular, no solo somos responsables de implementar correcciones de errores y nuevas características, como hacer cosas divertidas, sino que también somos responsables de asegurarnos de que todas estas 2,000 aplicaciones funcionen correctamente con Angular. Así que si introducimos un cambio en GitHub que rompe algo, se supone que debemos ir allí y solucionarlo. Esto nos ayuda a asegurarnos de que estamos al tanto de todos los cambios que están ocurriendo y asegurarnos de que no van a tener ningún efecto impredecible en tus aplicaciones. De esta manera, también al realizar cambios a gran escala, imagina que cambiamos una API pública, necesitamos asegurarnos de que funcione bien en Google Cloud, que tiene varios millones de líneas de código. Necesitamos implementar una migración automatizada, que es simplemente una transformación de código que hemos implementado en un par de cientos de líneas de código que toma todo este código de búsqueda de Google y lo migra al último cambio de API.

Podemos tomar este código fuente y hacerlo disponible externamente, y eso es lo que hacemos como parte del comando ng-update que mantendrá tu proyecto actualizado en diferentes versiones de Angular. No solo actualizará tu configuración, sino también tu código fuente.

Ahora, dado que todos estamos en la misma página, quiero hablar más sobre en qué hemos estado trabajando últimamente. La buena noticia es que la versión 10.0 RC de Angular está disponible. Dependiendo de cuándo estés viendo este video, tal vez la versión 10.0 aún no esté disponible. Es posible que estés considerando que esta es otra reescritura de Angular. Espero que con la explicación anterior te haya tranquilizado y seas consciente de que no estamos reescribiendo el framework con frecuencia. Esto se debe principalmente a que no es necesario y también tendríamos que migrar todos estos 2000 proyectos internos. Eso es mucho trabajo.

La versión 10.0 simplemente significa que hemos alcanzado otro hito. En general, lanzamos nuevas versiones principales de Angular cada seis meses. Lo hacemos por varias razones diferentes. Primero, queremos asegurarnos de tener un cronograma de lanzamiento predecible y que todos ustedes estén al tanto de cuándo exactamente llegará la próxima versión. Sabes que esta versión puede introducir algunos cambios menores incompatibles hacia atrás. Por supuesto, nos encargaremos de ellos principalmente cuando ejecutes ng-updates, pero imagina que también actualizamos la versión del compilador de TypeScript. Esto significa que es posible que tengas algunos problemas de tipos que debas solucionar por tu cuenta. Por supuesto, estos problemas de tipos solo harán que tu aplicación sea más estricta y, a partir de ahí, podrás obtener algunas sugerencias del compilador de TypeScript y detectar errores de antemano, pero aún así, esto es algo en lo que querrías planificar adicionalmente.

Ahora, permíteme dedicar un tiempo a hablar sobre algunas de nuestras motivaciones para avanzar con Angular. Creo firmemente que si comprendes los fundamentos teóricos de todo esto, estarás mejor alineado con nuestra hoja de ruta para Angular en general. Quiero hablar sobre la previsibilidad versus la flexibilidad. Obviamente, queremos tener ambas, ¿verdad? Queremos tener un sistema previsible que también sea muy flexible, pero esto a menudo no funciona muy bien, porque los sistemas previsibles tienen algunas restricciones. Para que un sistema sea previsible, debe seguir algunas restricciones predefinidas en las que sabemos que podemos confiar. Pero, al mismo tiempo, si queremos que un sistema sea flexible, debemos ignorar algunas de estas restricciones. Por eso llamo a esto el compromiso entre previsibilidad y flexibilidad. Como estoy bastante emocionado con los lenguajes de programación en general, por lo general, en ciencias de la computación, las personas se refieren a este compromiso como estático versus dinámico. Probablemente hayas oído hablar de la escritura estática versus la escritura dinámica. O la escritura fuerte versus la escritura débil. En este caso particular, como fuerte versus estático, estos son conceptos ortogonales. Así que pensemos en estático y dinámico por un segundo. Si intentamos ubicar diferentes lenguajes de programación populares en este eje, veremos algo como esto.

Idris es un lenguaje muy poderoso que tiene un sistema de tipos realmente restrictivo. También tenemos Haskell con un sistema de tipos muy restrictivo, y Rust también. Rust tiene muchas garantías en tiempo de compilación sobre la gestión de memoria.

Al mismo tiempo, sin embargo, puede ser realmente difícil enviar rápidamente un programa en Rust, porque tienes un compilador que te impone algunas restricciones para tener un sistema predecible. Necesita establecer algunas limitaciones.

Por otro lado, tenemos lenguajes muy dinámicos como JavaScript y Ruby. Son excelentes para prototipos rápidos, pero al mismo tiempo, no tenemos un compilador que pueda cuidarnos y asegurarse de que no cometamos errores tontos.

TypeScript está en algún punto intermedio. TypeScript es genial en general. TypeScript nos ayuda a obtener lo mejor de ambos mundos. Y podemos equilibrar usando diferentes indicadores de rigurosidad de TypeScript. Por ejemplo, si tienes verificaciones estrictas de nodos, nos inclinaremos ligeramente más hacia el lado estático en comparación con el dinámico.

Otra observación importante sobre estático versus dinámico es que es muy fácil pasar de estático a dinámico. Esto significa que solo debes relajar algunas de las restricciones, y tu sistema pasará de predecible a más flexible. Sin embargo, es realmente difícil pasar de un sistema muy dinámico a un sistema muy estático sin romper la infraestructura existente.

Si lo ponemos en términos más prácticos, podemos pensar en los sistemas estáticos como sistemas que son realmente bien optimizables en tiempo de compilación. El compilador puede razonar sobre tu programa mucho mejor si tiene metadatos sobre tus anotaciones de tipo. Puede analizar tu programa y transformarlo en una versión más eficiente de sí mismo. Los editores de texto y los IDE también pueden aprovechar esta función. Pueden examinar tu código fuente utilizando su servicio de lenguaje y brindarte sugerencias de autocompletado realmente excelentes e incluso mostrarte errores de verificación de tipos en línea que tengas.

La visualización del código fuente es una característica muy emocionante. En una de mis primeras ng-conf, presenté una charla llamada `La ciencia loca con el compilador de Angular`. Allí, implementé un compilador que toma tu aplicación de Angular y la compila a una realidad virtual. Puedes caminar dentro de esta realidad virtual con, digamos, Google Cardboard, y puedes mirar a tu alrededor y explorar tu aplicación en el mundo 3D, donde tus componentes son árboles con coronas que representan sus plantillas, y así sucesivamente. Sé que este es un ejemplo muy tonto y no muy práctico en un escenario del mundo real, pero muestra que un sistema estático puede ayudarte a lograr esto. Te permite realizar un análisis estático muy profundo de tu aplicación y hacer cosas locas.

Esto aplicado en un escenario del mundo real para una aplicación realmente útil podría ser un sistema para la ingeniería inversa de una aplicación. Puedes construir un visualizador de código fuente que muestre los módulos individuales en tu sistema, los componentes individuales y su relación entre sí. Este es un concepto realmente importante, especialmente cuando estás incorporando nuevos desarrolladores, porque visualmente es mucho más conveniente para nosotros, como humanos, razonar sobre sistemas. Por otro lado, por supuesto, si tienes un sistema estático, esto significa que necesitas tener un compilador que imponga algunas garantías y esta compilación lleva tiempo.

Tienes un proceso de compilación que puede, dependiendo de tu sistema de tipos, llevar desde unos pocos minutos hasta incluso horas si tienes un proyecto grande. Por otro lado, con sistemas dinámicos, no tienes un proceso de compilación porque no tienes nada que se deba cumplir en tiempo de compilación. Sin embargo, también tienes algunos beneficios. Puedes cargar componentes de forma perezosa con facilidad, puedes ensamblar dinámicamente la interfaz de usuario, y así sucesivamente.

Esta afirmación no es algo novedoso que se me haya ocurrido. En general, hay muchas personas, probablemente cientos de miles, que han llegado a la misma conclusión. Por supuesto, es genial si creamos programas que funcionen desde el principio, ¿verdad? ¡Es perfecto! Y todos queremos eso. Queremos crear programas sin errores y enviarlos a nuestros usuarios de inmediato. Pero en el mundo real, las cosas generalmente no van así. Somos desarrolladores, somos humanos, lidiamos con sistemas muy complicados, por lo que cometemos errores de vez en cuando.

Lo segundo mejor que te puede pasar después de enviar un sistema sin errores y que funcione desde el principio, es detectar esos errores muy temprano en el proceso, antes de enviar tu código fuente a producción. Si tu compilador te informa sobre algunos de los errores que existen en tu programa, eso sería ideal. Hay una encuesta, de hace algunos años, llamada `To Type or Not To Type`. Hay investigadores de la academia y de Microsoft. Están analizando TypeScript y Flow, y proyectos de código abierto. Al examinar los rastreadores de problemas de estos proyectos de código abierto, estos investigadores intentan averiguar cuántos de estos problemas podrían haber sido causados por el uso del sistema de tipos de TypeScript. De esta manera, podrías detectar este error durante tu proceso de desarrollo, sin que alguien te lo informe. Descubrieron que aproximadamente el 15% de estos errores podrían haber sido causados en tiempo de compilación mediante el uso del sistema de tipos. Observa cómo estos sistemas predictivos son bastante poderosos. Estamos detectando errores antes de tiempo. Y eso fue hace muchos años, cuando TypeScript todavía estaba en la versión 2.0. Ahora, está en la versión 3.9, y el sistema de tipos de TypeScript es mucho más poderoso, con muchas más restricciones que pueden ayudarnos a detectar errores antes de tiempo de manera mucho más fácil.

Muy bien, quiero comparar lo estático versus lo dinámico entre AngularJS y Angular. Si has sido desarrollador de AngularJS en el pasado, sabes que AngularJS era muy dinámico. Rara vez necesitabas algún proceso de compilación. Simplemente tenías tu framework. Simplemente publicabas algo de JavaScript y lo enviabas al navegador sin compilación, sin nada, y comenzabas a desarrollar. Y de vez en cuando obtenías algunos errores en tiempo de ejecución, ¿verdad? Y eso era perfectamente ideal para 2009, 2010, cuando no estábamos construyendo aplicaciones con millones de líneas de JavaScript. Sin embargo, ahora queremos tener más garantías.

Estamos construyendo sistemas más complicados. Y en Angular, con esto en mente, comenzamos con la versión 2.0 siendo muy estática, con muchas restricciones y un compilador muy estricto. Esto te restringía si estabas haciendo algo en contra de su especificación. Sin embargo, nos dimos cuenta de que esto ralentizaba el proceso de compilación. Además, queríamos habilitar un comportamiento más dinámico.

Entonces, lo que hicimos en la versión 4.0 fue relajar un poco las restricciones del compilador. Hicimos lo mismo con nuestros cambios más recientes en el compilador de Angular, bajo Ivy. Ahora, Ivy tiene más propiedades locales que realizan comprobación de tipos y cálculos de una manera ligeramente diferente. Estamos haciendo menos trabajo, por lo que las compilaciones son más rápidas.

Ahora, echemos un vistazo al futuro. Espero que ahora tengas una mejor comprensión de por qué los sistemas de tipos pueden ayudar a detectar errores y también a introducir algunas convenciones que permiten que diferentes herramientas se integren mejor. Ahora, quiero hablar un poco sobre la versión 10. En general, las cosas más importantes que estamos haciendo para la versión 10 son habilitar una bandera estricta opcional para proyectos de Angular y también un esfuerzo de la comunidad para aumentar la visibilidad sobre cómo tomamos decisiones.

Hablemos más sobre la segunda cosa. Durante muchos años, hemos estado formando y moldeando nuestra hoja de ruta simplemente recopilando comentarios de diferentes fuentes como Stackoverflow, GitHub, diferentes problemas allí, hablando con desarrolladores en eventos como el de hoy, en los foros, espero que pronto. También, hablando con clientes de terceros como empresas, grandes bancos, por ejemplo, hablando con clientes internos, y así sucesivamente. Aunque hemos estado haciendo esto y nuestras decisiones se basan completamente en los requisitos de nuestros usuarios, no comunicamos esto lo suficientemente bien. Tampoco comunicamos nuestra hoja de ruta lo suficientemente bien. Esto es algo que queremos mejorar. Así que simplemente sigue blog.angular.io para obtener noticias, espero que te sorprendamos de manera positiva.

Ahora, lo siguiente de lo que quiero hablar, y esto es algo que me emociona mucho, es en realidad la bandera estricta opcional. Con la versión 10, podrás crear nuevos proyectos con una configuración estricta. La configuración estricta va a habilitar un par de cosas. Una comprobación de tipos de TypeScript más estricta y también plantillas estrictas. Vamos a verificar mejor tus plantillas para asegurarnos de que se ajusten a ciertas especificaciones del sistema de tipos. También vamos a habilitar el soporte de ES5 bajo una bandera opcional, por lo que de forma predeterminada no enviaremos paquetes ES5 al usuario final. Sin embargo, si deseas admitir navegadores que utilizan ES y que aún no admiten ES 2015, puedes optar por utilizar ES5 mediante la carga diferencial. También vamos a desactivar el soporte de CommonJS de forma predeterminada. Si deseas optar por ello, si tienes algunas dependencias de CommonJS en las que confías, puedes hacerlo. Sin embargo, los módulos de CommonJS son muy dinámicos.

No nos permiten realizar optimizaciones estáticas deshaciéndonos de partes de estas bibliotecas que ya no estás utilizando. La última cosa es reducir los efectos secundarios. Si hacemos algunas suposiciones sobre tu código fuente y no tiene ningún efecto secundario global, como agregar variables globales, por ejemplo, podremos eliminarlo de manera más eficiente. Podremos deshacernos de las partes de diferentes bibliotecas, incluida la tuya propia, que ya no estás utilizando.

Hablando de la rigurosidad. Esto significa que si optas por el modo estricto que esperamos habilitar de forma predeterminada para todos, obtendrás más de estos. Y esto puede parecer aterrador. Pero recuerda, si tienes más errores en tiempo de vista, esto significa que estás atrapando más errores de producción antes de que tu código fuente llegue a los usuarios finales. Estos ejemplos de hacer tu configuración más estricta nos permiten hacer muchas cosas. Por ejemplo, podemos tener actualizaciones automatizadas, mucho más precisas. ngUpdate podrá consumir mucha más información de tipo si tienes banderas estrictas de TypeScript y podrá realizar estas migraciones de manera más precisa. También podemos, gracias a la naturaleza estática del ecosistema de Angular, optimizar el proceso de internacionalización.

Y finalmente, podemos tener una experiencia de desarrollo mucho mejor con herramientas como Angular Universal debido a algunas características estáticas de Angular. Primero, permíteme hablar un poco sobre el proceso de internacionalización sin sobrecarga. Ahora, muchas personas están buscando un comportamiento muy dinámico. Imagina que tienes una plataforma donde haces clic en un solo botón y cambiamos dinámicamente tu idioma sin recargar la página. Esto suena genial, pero tiene algunos problemas. Primero, para cada una de tus subcadenas de localización, debe haber otro enlace de datos. No importa si estás utilizando la detección de cambios de Angular o algún algoritmo de reconciliación en otro marco, esto agregará cierta sobrecarga en tiempo de ejecución. En segundo lugar, no podremos remodelar correctamente tus archivos de localización. Si solo usas el 10% de estas cadenas, no podremos deshacernos eficientemente del resto. Es por eso que en Angular estamos adoptando un enfoque ligeramente diferente. Lo que estamos haciendo es compilar tu aplicación una vez usando el compilador de Angular y donde tienes marcadores de internacionalización, agregamos información adicional que podemos usar para reemplazarlo con una subcadena específica para la localización específica que estás utilizando. De esta manera, estamos produciendo n compilaciones diferentes de tu aplicación para los n idiomas diferentes que admites. Y esto es sin sobrecarga en tiempo de ejecución y de la manera más eficiente en términos de rendimiento de inicio. Como ves, esto solo es posible gracias a algunas restricciones estáticas, algún procesamiento estático, algún paso de compilación.

Ahora finalmente, quiero compartir un par de cosas sobre Angular Universal, que nuevamente están relacionadas con el comportamiento estático. Con Angular Universal, ahora mismo puedes implementar tu aplicación fácilmente usando solo dos comandos. Puedes hacer ng add, angular/fire, esto va a iniciar automáticamente el proceso de implementación de Angular Universal, lo cual solo es posible nuevamente porque tenemos una convención específica sobre cómo tratamos diferentes paquetes y cómo ejecutamos sus esquemas para lograr cierto comportamiento cuando los agregas a tu proyecto. Justo después de eso, cuando ejecutes ng deploy, vamos a implementar tu aplicación de Angular Universal como una función de Firebase y enviar tus activos estáticos a un CDN.

De la manera más posible y óptima, podremos desplegar tu aplicación Angular Universal con solo dos comandos, porque estamos estableciendo algunas restricciones y convenciones sobre cómo funciona Angular CLI. Esto también es aplicable para el Jamstack. Por ejemplo, tanto en Angular Universal como en Scali, podemos descubrir todas las diferentes rutas de tu aplicación estáticamente sin ejecutar tu aplicación. De esta manera, más tarde podemos pre-renderizarlas y hacerlas disponibles a través de CDN. Nuevamente, esto solo es posible debido a algunas suposiciones estáticas que tenemos, que solo son posibles ya que actualmente estamos dirigiendo la estructura de Angular CLI y haciendo suposiciones sobre la estructura de tu aplicación también.

Entonces, si te quedas con dos cosas de esta presentación, la primera debería ser que no es aterrador actualizar tu aplicación a la última versión de Angular. Todo lo que necesitas hacer es ejecutar ng update Angular/CLI y Angular/core. Por favor, hazlo. Garantizamos que iremos mejorando con cada nueva versión en términos tanto de pasos de migración como de rendimiento en tiempo de ejecución e inicio.

En segundo lugar, espero que te des cuenta de las ventajas que esto nos brinda. Observa cómo, al tener una plataforma bien integrada con ciertas restricciones estáticas, podemos ofrecer una gran experiencia de desarrollo con dos comandos: desplegar tu aplicación Angular universal en la nube y proporcionar suposiciones sobre tu proyecto para poder migrarlo automáticamente con un solo comando.

Realmente te agradezco mucho por escuchar mi charla. Si tienes algún comentario, por favor déjalo en mgv.io. Si tienes alguna pregunta, estaré encantado de responder. Me encanta hablar sobre compiladores y optimizaciones estáticas, así que no dudes en contactarme en twitter.com.

Gracias. Gracias por la charla, Minko, fue realmente interesante. De hecho, fue tan interesante que no tuvimos muchas preguntas. Tenemos un par de ellas y las vamos a revisar. Pero esto es solo un recordatorio para todos los que están viendo que si aún quieren hacer sus preguntas, este es el momento y aún puedo hacérselas a Minko. Comencemos con esta pregunta de Albert. ¿Hay alguna posibilidad de que Angular incorpore web components con o sin lit HTML o lit element? Sí, buena pregunta. Hemos estado apoyando los web components durante un tiempo. Puedes aprovechar los web components en tu aplicación Angular ahora mismo si quieres. Además, admitimos la construcción de web components utilizando Angular mismo. A muchas personas les gusta utilizar las API de nivel superior que proporciona Angular para declarar tus entradas, tus salidas, incluso utilizar la inyección de dependencias si quieres. De esta manera, puedes envolver tus componentes de Angular en un web component utilizando el paquete Angular elements. Espero que esto responda tu pregunta. Tenemos muchas iniciativas diferentes donde estamos utilizando... Nuestros diferentes proyectos están utilizando web components en el fondo y están creando envoltorios de Angular en el otro lado. Ambas direcciones son posibles. Muy bien. Espero que Albert esté muy satisfecho con esa respuesta. La siguiente pregunta es de Ishan.

¿Cómo actualizar varios proyectos con un solo comando? Sí. Cuando ejecutas ngUpdates, esto migrará todas tus bibliotecas y proyectos de este espacio de trabajo específico de Angular CLI a la versión que has especificado. Supongo que esto también responde a tu segunda pregunta. En general, si tienes múltiples espacios de trabajo de Angular, debes ejecutar ngUpdates varias veces. Vamos a migrar automáticamente toda tu aplicación y todas las bibliotecas en este espacio de trabajo a la versión que has especificado.

Hubo un poco de compilación de seguimiento allí, pero eso es genial. Creo que has respondido perfectamente. De Janice, la siguiente pregunta, ¿se admitirán las traducciones que cambian dinámicamente en la nueva forma? Sí, tenemos... Hay algunas compensaciones en ambos enfoques. Hasta ahora, la internacionalización, la forma en que la hemos implementado, está optimizada para el rendimiento y la limitación que tienes es cambiar las traducciones dinámicamente sin actualizar la página. Creemos que esta compensación está justificada. Por eso estamos trabajando en este enfoque más estático, porque esto reduce el tamaño de tu paquete y también tiene cero sobrecarga en tiempo de ejecución. No tenemos ninguna vinculación y tu aplicación funcionará muy bien. Por otro lado, no podemos cambiar las traducciones dinámicamente sin actualizar la página. Para muchos clientes, muchos usuarios de Angular, muchos desarrolladores, esto no es una preocupación debido a los beneficios de rendimiento. Algunos prefieren tener el cambio dinámico de traducciones. Si esto es crítico para ti, si crees que los usuarios de tus aplicaciones cambiarán frecuentemente entre diferentes traducciones y quieres que esto sea lo más fluido posible, te recomendaría aprovechar el módulo de terceros ngxtranslate, en este momento. Algo que nuestro nuevo pipeline de internacionalización permitiría es cargar localizaciones individuales en tiempo de ejecución. Esto ha sido una característica muy importante para diferentes clientes que utilizan Angular, y también en aplicaciones móviles con Cordoba u otro entorno híbrido similar. Esto es lo que permitiría el nuevo pipeline de internacionalización.

Correcto. Pregunta completamente diferente de Bram. ¿Las variables en los puntos de salida de ng-template estarán estrictamente tipadas? Creo que sí. Sí, creo que sí. El modo más estricto posible que actualmente admitimos en las plantillas, creo que ya tiene una tipificación estricta para esto, a menos que me haya perdido algo. Muy bien. Veo a algunas personas escribiendo frenéticamente en la sala de preguntas y respuestas. Así que te haré una pregunta propia. ¿Qué opinas sobre el futuro de Angular? ¿Qué ves? ¿Qué ves en el futuro de Angular? Sí. Gracias por hacer esta pregunta.

En general, estamos considerando. Entonces, en general, estoy pensando en el futuro de los frameworks en general en tres direcciones diferentes. El rendimiento es uno de ellos. La ergonomía del desarrollador y la corrección. En cuanto al rendimiento, los navegadores web están trabajando muy de cerca con los frameworks en la actualidad hoy en día. Por ejemplo, el equipo de Chrome colabora constantemente con nosotros, y sé que también trabajan con React y consultan a menudo con Vue. En términos de rendimiento, hay muchas áreas diferentes, pero la hidratación progresiva será una de las partes principales allí. Otra cosa es que debemos reconsiderar qué capacidades heredadas de la plataforma web estamos utilizando y que nos están frenando. Por ejemplo, en la versión 8 de Angular, eliminamos el soporte de módulos ES 5 al habilitar la carga diferencial.

La ergonomía del desarrollador también es muy importante, desarrollar una plataforma integrada que te permita iniciar tus proyectos, desarrollarlos e implementarlos con un solo comando. Esto es algo en lo que, al menos en el equipo de Angular, hemos puesto mucho énfasis. Queremos reducir el umbral desde la creación de un nuevo proyecto hasta su implementación en producción, y la corrección. Hablé mucho sobre la corrección en mi charla. Hablé sobre la verificación de tipos y por qué esto es realmente algo bueno. Además, hay diferentes comprobaciones de conformidad para asegurarnos de que estás siguiendo el camino correcto, de que no estás cargando recursos en el orden incorrecto que ralentizarán tu aplicación. Esto es realmente importante tener una serie de diferentes comprobaciones. Esto es algo en lo que hemos estado trabajando, y también estamos colaborando con Google Chrome para asegurarnos de no retroceder en estos aspectos. Así que estas son tres áreas que considero importantes.

Interesante. Es algo que le pregunté a alguien antes de trabajar para una gran corporación y contribuir a un proyecto de código abierto. ¿Qué crees que hace que sea diferente para ti obtener el apoyo de tu empresa para trabajar en código abierto y en este proyecto? Tenemos bastantes colaboradores que trabajan fuera de Google. Por lo general, hay diferentes motivaciones. El framework es de una empresa externa. Lo llamo externo, pero en realidad Google es un cliente de Angular, al igual que cualquier otra empresa. Por lo general, la motivación es tener una visión interna de lo que está sucediendo a continuación, aunque estamos tratando de hacer todo público y disponible para todos. Tenemos mucho más trabajo por hacer en esta dirección para hacer las cosas bien, pero aunque todo es público, al participar en reuniones de equipo y contribuir activamente al framework, esto te brinda una mejor comprensión. Así que este es un gran beneficio para algunas empresas. Por otro lado, también tienes un conocimiento mucho más profundo de cómo funciona todo en el framework. Entonces, si alguien de tu empresa necesita un soporte Angular realmente profundo, tienes a los expertos en el lugar que podrán debug todo, desde el runtime del framework hasta el compilador, el CLI y muchas otras características. Supongo que estos son dos de los mayores beneficios que las personas pueden obtener.

Y otro, por supuesto, es con mayor visibilidad. Si estás trabajando en un proyecto público y altamente visible, es posible que tu empresa pueda atraer más talento.

Sí, absolutamente. Tal vez podamos hacer una última pregunta. ¿Cuáles son tus pensamientos sobre el uso de NX como una configuración de monorepo para aplicaciones de Angular? Lo siento, no escuché el principio. ¿Cuáles son tus pensamientos sobre el uso de NX como una configuración de monorepo para aplicaciones de Angular?

Sí, excelente pregunta. Entonces, sí, al elegir un monorepo, hay diferentes alternativas que puedes considerar. Puedes usar la configuración predeterminada del espacio de trabajo de Angular, que te proporciona lo básico, los cimientos. NX va un paso más allá y te brinda más incrementalidad en el almacenamiento en caché para Angular, especialmente para JavaScript. Sé que muchas personas están utilizando la CLI de Angular para aplicaciones de React y Vue también, gracias al gran trabajo que está haciendo NX. Y si quieres ir un paso más allá, y no quieres limitarte a usar solo JavaScript y TypeScript en el mismo monorepo, si tienes un backend en Java, por ejemplo, puedes considerar usar algo como Bazel, que es un sistema de compilación muy grande y escalable que se utiliza en muchas corporaciones diferentes, como Uber, Lyft y Google. Ha estado impulsando nuestra compilación durante los últimos 12 años, por lo que puedes obtener beneficios incrementales realmente excelentes. Puedes ejecutar pruebas solo cuando cambia tu backend, por ejemplo, cuando cambia el esquema de tu API, y así sucesivamente.

Absolutamente. De acuerdo, muchas gracias por esa respuesta. Y creo que eso concluye nuestra sesión de preguntas y respuestas, pero las personas aún pueden unirse a una de las salas de discusión que se abrirán a continuación, donde serás coanfitrión de esa sala de discusión junto con Maxim Solnykov, que en realidad es uno de mis colegas cercanos, así que eso es agradable, y me aseguraré de pasar un rato por allí. También hay otras salas de discusión, una sobre Alpine JS con Caleb, y luego sobre TypeScript con Tejas. Y también nos quedan un par de entradas para los talleres sobre TypeScript, así que puedes ir a live.jsnation.com para obtenerlas. Así que te dejo ir, Minko, y unirte a la sala de discusión, y las personas pueden ir allí y hacerte más preguntas. Genial, gracias por las preguntas aquí también. Nos vemos más tarde. Gracias.