Renacimiento de Angular

Mi nombre es Minko, como escucharon, soy el líder de producto de Angular en Google, lo que significa que soy responsable de lo que construimos para Angular, por qué y cómo lo compartimos con los desarrolladores.

Así que la comunidad ha estado hablando últimamente sobre este renacimiento de Angular. Y es posible que se pregunten qué ha cambiado realmente en Angular. ¿Qué pasó? Bueno, realmente sucedieron muchas cosas y estoy ansioso por compartirlas con ustedes. El año pasado, Angular y React eran efectivamente el mismo framework.

Ahora, esto puede sonar extraño, porque React tiene JSX y funciones, Angular utiliza plantillas y clases para los componentes, ¿cómo podrían estar remotamente conectados? Bueno, al construir tu aplicación, esto es diferente, pero en tiempo de ejecución, las cosas son muy similares. Yo diría que más del 50% de la responsabilidad de un framework frontend es mantener el estado dentro de tus componentes sincronizado con la UI.

Entonces, cuando construyes tu aplicación, utilizas cualquier formato, alterando el formato que tienes en tu framework. A partir de ahí, en tiempo de ejecución, el framework convierte estos componentes en un árbol de componentes. Y cuando algo sucede, cuando cambia el estado, el framework va a reflejar el cambio de estado en la UI, y en el mundo del front-end, nos referimos a esto como reactividad.

Sorprendentemente, Angular y React han tenido un modelo similar en los últimos años. Veamos cómo funciona la reactividad. Primero, especificamos que algo ha cambiado. En React, lo hacemos explícitamente. En Angular, hay algo llamado zone.js que intenta determinar cuándo algo podría haber cambiado para poder programar desde aquí una detección de cambios o reconciliación donde recorremos todo este árbol de componentes para averiguar todos los lugares donde podría haber cambiado, donde puede haberse mantenido actualizado, ir a la UI y actualizar en. Eso es prácticamente todo.

Veamos un ejemplo más práctico para ver cómo funciona esto en la práctica. Tenemos un componente de aplicación aquí que utiliza dos componentes, el perfil de usuario y el carrito de compras. El perfil de usuario es bastante simple, solo muestra el nombre de usuario, y el carrito de compras recorre la lista de elementos en el carrito de compras, y para cada uno de ellos muestra la cantidad. A su vez, el framework va a convertir esto en un árbol. Tenemos el componente de aplicación en la parte superior. A la izquierda, tenemos el componente de perfil de usuario, y a la derecha, tenemos el carrito de compras.

Ahora, si algo cambia, digamos que actualizamos la cantidad del primer elemento en el carrito de compras, tanto Angular como React comenzarán a recorrer este árbol, tratando de encontrar qué cambió. Primero, irán al componente de la aplicación aunque no haya cambiado. Después de eso, realizarán esa primera recorrida, por lo que irán al componente de perfil de usuario aunque no haya cambiado allí tampoco, y finalmente, luego irán al componente de carrito de compras y reflejarán la actualización. Ahora, tanto en Angular como en React, tenemos una forma de optimizar esto manualmente. En Angular, tenemos nuestra propia estrategia de detección de cambios push. En React, podemos usar la memorización. Esto nos permite podar partes de este árbol de componentes, por lo que solo realizaremos la detección de cambios o reconciliación en el componente de aplicación y en el componente de carrito de compras. Si aún no confías en que Angular y React son muy similares en cómo realizan la reactividad, veamos algunas pruebas de rendimiento. Puedes ver que Angular y React tienen un patrón de rendimiento muy similar aquí. Ambos no se desempeñan bien al intercambiar filas, y les va bien para las actualizaciones parciales. Ahora, estas son pruebas de rendimiento con el flujo de control heredado de Angular, por lo que optimizamos las cosas desde entonces, pero así es como funcionaban las cosas el año pasado. Con este ejemplo, recorrer este árbol de componentes con tres elementos no parece ser un gran problema, ¿verdad? Solo recorremos tres elementos y verificamos las actualizaciones de estado. Pero las aplicaciones del mundo real no son realmente tan simples. Tenemos árboles de componentes mucho más grandes. Aquí tenemos más de 100 componentes, y lo sé porque construí este árbol a mano mientras volaba hacia la conferencia.

Puedes imaginar que, si tenemos que recorrer este árbol para descubrir todos los cambios de estado, esto podría llevar algún tiempo. Las aplicaciones del mundo real son mucho más grandes que estos 107 componentes aproximadamente. Tienen miles de componentes en tiempo de ejecución.

Angular estaba pensando qué podíamos hacer para optimizar la detección de cambios en el sistema de reactividad. Consideramos expandir nuestro compilador para tener un seguimiento de dependencias estáticas, pero decidimos que no era el camino correcto porque introducía cierta magia que podría generar desafíos al depurar. También exploramos las señales. Nos unimos al club de las señales, junto con Vue, Solid, Svelte y otros. Dentro de las señales, simplemente envuelves el estado local del componente dentro de una señal. A partir de ahí, puedes leerlo dentro de tus plantillas, y esto es suficiente para notificar al framework, para que el framework sepa exactamente dónde se está utilizando este estado, de modo que cuando actualices el estado, el framework pueda ir allí y realizar la detección de cambios, digamos, solo en esta parte particular de tu componente.

Cuando observas el árbol de componentes más grande y, digamos, actualizamos item.quantity y lo establecemos en uno con una señal, solo iremos a los componentes que hayan leído la señal. En este caso, digamos que estos dos componentes, y el resto, no tenemos que recorrerlos, por lo que esto mejora significativamente el rendimiento en tiempo de ejecución.

Las señales se hicieron populares no solo en la comunidad externa, sino también dentro de Google. En Google, tenemos dos frameworks para el desarrollo de aplicaciones web que están disponibles en general. Tenemos Angular y WIS. Angular se ha centrado más en experiencias empresariales, y WIS en clientes de consumo. Digamos que la búsqueda de Google se construye con WIS, Google Photos, Google Drive y más. En la terminología externa de los frameworks externos, puedes pensar que WIS es más similar a Eleventy o Quick. De hecho, WIS inventó el concepto de razonabilidad hace diez años. Originalmente, estos dos frameworks ocupaban segmentos muy diferentes, pero con el tiempo, notamos cómo estos requisitos para las aplicaciones que estábamos construyendo con Angular y WIS comenzaron a fusionarse. Las personas que construyen aplicaciones con Angular querían más de las características de Angular. Las personas que usaban WIS querían algunas de las características de experiencia de desarrollo de Angular. Comenzamos a colaborar juntos de cerca.

Fue mi responsabilidad descubrir qué código podíamos compartir. Estaba en el canal de chat de Google en el canal de WIS, y vi algo como esto. Definitivamente no fabriqué la captura de pantalla ayer. WIS estaba trabajando con YouTube para reescribir toda su interfaz de usuario y pasar de una implementación basada en el DOM virtual heredado a WIS, y estaban explorando señales para una reactividad detallada. Angular, por otro lado, estábamos diseñando la implementación de señales de Angular en ese momento, así que decidimos unirnos y construir una solución juntos. YouTube adoptó las señales de Angular a través de WIS, y actualmente maneja el 100 por ciento de su tráfico web móvil de YouTube. Notaron algunas mejoras. Por ejemplo, en las salas de estar, es decir, en las Smart TVs, vieron una latencia de entrada aproximadamente un 35 por ciento mejor en las TVs de gama baja, y al deslizar en YouTube web móvil, notaron 60 fotogramas por segundo en comparación con la implementación heredada del DOM virtual que proporcionaba 25 fotogramas por segundo. Al ver que estas señales realmente funcionan, y funcionan en Angular y WIS, y podemos compartir la misma implementación de señales exacta, nos acercamos a los organismos de estandarización y a los representantes de otros frameworks que también han estado utilizando señales.

Como mencioné, Solid, Vue, Svelte, Preact, Amber y nosotros comenzamos a explorar juntos cómo podemos hacer que las señales formen parte de la plataforma web, cómo podemos agregarlas al lenguaje JavaScript. Actualmente, las señales están en la etapa 1 para T39, y la implementación de referencia está utilizando las señales de Angular porque demuestra que escala para YouTube, el segundo sitio web más grande del mundo, y también puede funcionar en diferentes frameworks. Angular y WIS.

Muy bien. Esa fue la parte de la experiencia del desarrollador, aunque también tenemos algunas mejoras de rendimiento. De hecho, significativas con el modelo de reactividad. Permítanme hablar un poco sobre el rendimiento. Hemos tenido algunas mejoras importantes aquí, y la primera fue con algo llamado vistas aplazables que nos permite especificar de manera declarativa parte de la plantilla que podemos cargar de forma perezosa. Podemos extraerlo como un paquete separado y precargarlo, prefetch y cargarlo de forma perezosa cuando sea necesario.

De esta manera, puedes acelerar significativamente el tiempo de construcción inicial, tu tiempo de carga inicial, perdón. Vue.com comenzó a usar vistas aplazables y vieron una mejora del 50 por ciento en el tamaño de su paquete, y quería mostrarte rápidamente cómo funcionan. ¿Cuántos de ustedes les gustan las demostraciones en vivo? Genial. A mí también me gusta verlas. Veamos si puedo averiguar cómo hacer el espejo ahora. Muy bien, vemos lo mismo. Tengo muchas cosas aquí. Tengo una plataforma de comercio electrónico simple aquí, construida con Angular, y tiene este cuadro de chat en la parte inferior.

Sabemos que muy pocas personas van a interactuar con este cuadro de chat, ¿verdad? ¿Por qué te involucrarías con el soporte? Vas allí a comprar, por lo que tal vez el uno por ciento de los usuarios interactuaría con él. Sin embargo, por defecto, podemos ver que forma parte del paquete principal de la aplicación. Simplemente retrasa innecesariamente el tiempo de carga inicial. Podemos cargarlo de forma perezosa cuando sea necesario. Idealmente, nos gustaría cargarlo cuando entre en el viewport. Luego expandimos el cuadro de chat y comenzamos a escribir algo que ya será interactivo. Con las vistas aplazables, podemos usar la primera sintaxis, especificar que nos gustaría precargarlo cuando entre en el viewport. Y especificamos un marcador de posición. Y guardamos. Eso es prácticamente todo. Si vamos al paquete principal ahora, podemos ver que ya no lo cargamos de forma ansiosa. Tenemos una importación dinámica que el compilador de Angular creó para nosotros.

Cuando expandimos el cuadro de chat y comenzamos a escribir, y vamos a la pestaña de red, veremos que se carga de forma perezosa, tal como se esperaría. Lo interesante de esto es que maneja automáticamente toda la complejidad de los estados de carga y los observadores de intersección para nosotros.

Muy bien, ahora veamos cómo puedo volver a mi presentación. Decidimos construir sobre esta abstracción. Te mostraré cómo en un momento. Y lo hemos integrado profundamente en nuestra solución de representación híbrida. Hablaré sobre la iteración parcial en un momento, pero antes de eso, quería contarte cómo actualizamos nuestro pipeline de construcción. Ahora utiliza Vite y ESbuild de forma predeterminada. Estamos migrando proyectos existentes. Vanguard informó que la velocidad de construcción mejoró tres veces después de cambiar a este nuevo pipeline de construcción. Así que gracias al equipo de Vite y a ESbuild por crear una infraestructura tan maravillosa.

Cuando utilizamos el renderizado en el lado del servidor, ocurre el proceso de hidratación. Primero obtenemos HTML. Puede ser generado estáticamente, pre-renderizado o puede provenir del renderizado en el lado del servidor. Justo después, descargamos todo el JavaScript asociado. A continuación, debemos ejecutar este JavaScript y, finalmente, agregamos los event listeners y hacemos que nuestra aplicación sea interactiva. Este proceso es conocido como hidratación, como sabemos. Puede llevar algún tiempo. Entre el momento en que tenemos algo visible en la pantalla y la aplicación es interactiva, perderemos eventos del usuario. El usuario puede comenzar a interactuar con la aplicación y no sucederá nada. Por eso queríamos mejorarlo e introdujimos una funcionalidad llamada reproducción de eventos.

Aquí, la aplicación aún no está hidratada. El usuario interactúa con ella. Capturamos los eventos y los reproducimos. Esto está inspirado en nuestra asociación o fusión con Wists, y utiliza la misma funcionalidad de reproducción de eventos que Google Search ha estado utilizando durante los últimos diez o quince años, que está disponible aquí en el repositorio de Angular en GitHub. Hay una cosa más que podemos mejorar aquí. Cómo podemos reducir esta ruta de hidratación, cómo podemos asegurarnos de cargar la cantidad mínima de JavaScript, para que el tiempo de ejecución sea significativamente más corto y tengamos menos event listeners que agregar. Como mencioné, con la movilidad, hemos estado pensando juntos cómo podemos introducir gradualmente la hidratación parcial en Angular utilizando vistas aplazables. Quería mostrarte otra demostración rápida. Es posible que no tenga que cambiar al espejo aquí.

Veamos. Sí, aquí vamos. Esta aplicación aquí parece una maqueta pero es un carrito de compras en funcionamiento. Así es como construimos nuestras aplicaciones. Por defecto, cargamos un par de componentes, el pie de página, la navegación y el encabezado, y el carrito de compras. Los cargamos casi al instante y los hidratamos, pero el resto de la aplicación no está hidratada. Además, he agregado algunos retrasos artificiales para que puedas ver lo que realmente está sucediendo.

Aquí tenemos la aplicación, solo estos pocos componentes se descargarán e hidratarán. Al principio, toda la aplicación estará en gris. Solo tendremos esta capa de reproducción de eventos que se encarga de capturar los eventos del usuario, descubrir qué es responsable de manejarlos, descargar el code asociado y reproducirlos. Aquí, por ejemplo, si hago clic en agregar al carrito, esto va a desencadenar la descarga de este componente. Cuando el componente se descarga e hidrata, vamos a reproducir el evento y agregar el artículo al carrito. No tengo conexión a internet, o he detenido mi servidor de desarrollo.

Veamos. Si hago clic en el componente del carrito, esperamos obtener lo mismo. Tenemos esta isla que va a detectar automáticamente qué JavaScript es responsable de manejar este evento, va a ir al servidor y agregar el artículo correspondiente al carrito. Veamos qué está sucediendo aquí. Permíteme ejecutar la aplicación. Muy bien. Sí, por eso dije que me gusta ver demostraciones. No me gusta hacerlas. Y si abro la pestaña, no tengo conexión a internet aquí, así que no puedo descargar JS Action. ¡Disculpa por eso! Muy bien. La forma en que esto funciona es que crea diferentes islas en nuestra página.

En este caso, la navegación podría ser una de estas islas. En el lado derecho, tenemos otra isla que es responsable de otra cosa. Pueden vivir de forma independiente y el resto de la UI no necesita ser hidratado de ninguna manera. Esto es muy similar a la arquitectura de islas de Astro. Es específico de Angular y tiene algunas adiciones. Por ejemplo, puede detectar dependencias de datos.

Ahora, actualmente estamos en el proceso de diseñar la iteración parcial. Tenemos un prototipo funcional que funciona cuando tienes conexión a internet, y vamos a lanzar una vista previa para desarrolladores, o una versión experimental en las próximas semanas. Estamos ampliando la historia de los datos, así que nos encantaría asociarnos. Si estás construyendo una aplicación grande a escala que tiene requisitos críticos de rendimiento, por favor contáctanos, nos encantaría asociarnos para determinar los requisitos de la iteración parcial, algo que no existe realmente en todos los populares frameworks, y nos gustaría implementarlo juntos.

Ha habido mucho acontecimiento en Angular, y también hemos visto mucha innovación en la comunidad. Brandon Roberts lanzó la versión 1.0 de Analog, que es un meta framework impulsado por la comunidad para Angular. TANstack introdujo la adaptación de Angular en TANstack query, TANstack table, store, y también forms. Pero había algo que me ha estado molestando durante un tiempo, y es este logotipo. Tenemos todas estas características geniales, pero este logotipo no ha cambiado en casi 15 años. Así que el año pasado, decidimos actualizar el logotipo también y asegurarnos de que refleje la naturaleza orientada al futuro que tiene Angular. Junto con esto, actualizamos la página web de documentación de Angular, e introdujimos un recorrido de inicio que te permite experimentar con Angular directamente en tu navegador en Angular.dev.

Así que hemos cubierto muchas cosas hoy, y hay mucho más por venir. En primer lugar, nos gustaría asegurarnos de que, si deseas adoptar señales, solo puedas adoptarlas para los componentes que tengan sentido en tu aplicación, y si prefieres utilizar la reactividad muy gruesa en Angular, puedes seguir haciéndolo, de manera que puedas adoptarlas sin ningún cambio disruptivo. Estamos trabajando en la hidratación parcial, sin zonas y mucho más. Todas estas características están en apoyo de nuestra misión de apoyar a los desarrolladores para entregar aplicaciones web con confianza.

Eso es todo lo que tenía para ustedes hoy. Gracias, y me encantaría responder a sus preguntas.

Sí, entonces, vamos a responder algunas preguntas ahora. Nuevamente, el code es 1317. Si quieres unirte a Slido, vamos a hacer algunas preguntas difíciles.

Muy bien. Bueno, la primera pregunta debe hacerse, ¿no? Oh, no, me la perdí. Hubo una que decía, ¿está React muerto? Podría ser. Muchas personas van a una conferencia de React mañana. Deberías tener cuidado. Creo que React está funcionando bastante bien. Recientemente compartieron una versión experimental de su compilador.

Sí. Excelente. Entonces, ¿las señales reemplazarán o funcionarán en conjunto con algo como NgRx? Sí, hay un paquete introductorio de RxJS que te permite convertir tus señales en observables, y viceversa. Queremos hacer que RxJS sea opcional en Angular para que las personas que no quieran usarlo no tengan que hacerlo, pero al mismo tiempo proporcionar mejores integraciones con él.

Genial. Esta es probablemente una pregunta similar, en la misma línea, ¿cuál es el futuro de RxJS, y Angular considerando la inversión principal en las señales? ¿Va a desaparecer? RxJS es muy exitoso. Puedes ver que tiene muchas más descargas que cualquier otro framework. Es posible que no queramos agregarlo como parte del proceso de aprendizaje principal de Angular. Aún así, seguiremos teniendo integraciones con RxJS cuando tenga sentido.

Excelente. Un mosquito está tratando de picarme aquí. Un mosquito está tratando de picarme aquí. Tal vez estén escondidos aquí. Hay un nido allí. No se lo decimos a nadie. La capacidad de reanudación y la repetición de eventos son buenas, pero ¿cuáles son las posibilidades de mejoramiento progresivo como alternativa cuando el paquete de JavaScript no se carga con Angular? Sí, definitivamente es una alternativa cuando se utiliza el renderizado del lado del servidor. Puedes cambiar algunos de los enlaces en tu página, por ejemplo, para que lleven a una actualización completa. No toda la funcionalidad funcionaría. Gran parte de ella depende de JavaScript. Como vimos, las transiciones de vista, en cierta medida, admiten algunos de estos casos de uso, pero no completamente.

Tienes muchos casos de uso dependientes de JavaScript. Fantástico. Hay tantos. Por cierto, estás recibiendo muchas preguntas, así que no te moverás por un tiempo.

Creo que esta también era para ti. ¿Puedo tener tu configuración de VS Code? Claro. Debería estar en mi GitHub. ¿Cuál es tu nombre de usuario en GitHub? Mghetchv. Estoy seguro de que está vinculado a tu Twitter o algo así. Solo búscate en Google.

Estoy usando la API web en memoria de Angular pero no puedo encontrar ninguna documentación. ¿Todavía se mantiene? Lo estábamos usando específicamente para la documentación. Realmente no lo hemos promovido mucho fuera de eso. No es algo que queramos mantener abiertamente para todos en este momento, así que te recomendaría dejar de usarlo, a menos que ya hayas invertido mucho en él. Si lo has hecho, ven y habla conmigo después y podemos encontrar una solución.

Genial. ¿Los formularios reactivos recibirán soporte de primera clase para señales, como una señal de cambio en lugar de un observable? Sí, vamos a evaluar exactamente dónde estamos usando observables en los formularios reactivos y determinar dónde tiene sentido usar señales. Es una de las características que está en nuestro plan de desarrollo.

Excelente. Entonces, si ya se está mostrando, ¿está por venir muy pronto? Sí, tenemos un plan de desarrollo masivo para ti. Está en camino.

La facilidad con la que se hicieron las alternativas y la carga diferida también fue increíble. Es muy genial. También tengo curiosidad por esto. ¿La integración de Wiz requerirá alguna migración? Sí, es una buena pregunta. La forma en que estamos planeando converger Angular y Wiz juntos es simplemente agregando algunas de las características de rendimiento de Wiz a Angular. Así es como funcionarán las cosas. No será una reescritura de Angular ni de Wiz. En general, acercaremos las implementaciones entre sí.

Tenemos un cronograma muy largo para esto. Por lo tanto, estamos entregando características de inmediato que puedes ver ahora mismo con la iteración parcial y las señales en Wiz y la repetición de eventos, pero no estamos necesariamente alineados al 100% en la implementación de todas ellas. Así que todavía estamos trabajando en progreso para descubrir cómo hacer esa migración.

Sí, queremos hacerlo. Muy nuevo. Sí, también queremos ofrecer valor lo más rápido posible porque a nadie realmente le importan los detalles de implementación de los desarrolladores que usan Angular o Wiz.

Tengo curiosidad por esto, así que también lo voy a poner en el directo si puedo encontrarlo. Volverá a aparecer. ¿Las referencias de vista son iguales que tus nuevas señales o son aún más performance? Supongo que esta es una pregunta basada en la vista, así que podría ser la persona equivocada para preguntar sobre esto. Sí, probablemente sea Evan. Sí, molestaremos a Evan nuevamente después. Tenemos que tener una lucha de brazos arriba para decidir quién es mejor... Supongo que tenemos consultas basadas en señales, consultas de vista que son similares. No sé si esa es la pregunta, pero hay otras preguntas que podemos dejar para después... Podemos discutirlo después, seguro, en el stand de preguntas y respuestas.

Y luego, ¿cuándo te desharás de la inyección de dependencias? Sí, nunca. Esa es la característica más amada. A todos les encanta la inyección de dependencias. De hecho, tenía un par de diapositivas más. También tenía un par de diapositivas más sobre esto porque es una gran similitud entre Angular y React también. Allí no lo llaman inyección de dependencias, lo llaman API de contexto, pero utilizan las mismas estructuras de datos en el fondo, tienen los mismos casos de uso, su API se ve ligeramente diferente. Así que es una parte fundamental de la mayoría de los frameworks. ¿Entonces nunca? Nunca, sí. Nunca. De acuerdo. Al menos esa es una respuesta firme para que todos lo sepan. Mencionaste mucho a React en tus comparaciones, así que ¿cuánto observa el equipo de Angular los planes de otros frameworks, y cuánto influye eso en cómo estás desarrollando o qué estás desarrollando también? Sí, definitivamente estamos mirando a nuestro alrededor. Cuando estamos diseñando vistas diferibles, puedes ver que para los desarrolladores de React, se les recordará el suspense. Queremos asegurarnos de aprender de otros frameworks cuando estamos construyendo nuevas características, y al mismo tiempo estamos recopilando muchos requisitos de los desarrolladores y viendo hacia dónde se mueve la web para poder dirigirnos en esta dirección también y hacer crecer el framework basado en una base más sólida, no necesariamente obteniendo inspiración de otras alternativas. No robando. Inspirados. Inspirados por otros frameworks. Aprendiendo, sí.

Supongo que esa es la diversión del código abierto. Puedes aprender mientras hacemos estas cosas también. Puedes ver cómo, por ejemplo, trabajamos con Ryan de Solids para asegurarnos de que la Reactividad de Angular con señales funcione muy bien, y ahora T39 está utilizando la implementación de señales de Angular como base para las señales en JavaScript. Genial. Creo que eso es todo lo que tendremos tiempo para el Q&A en este momento. ¿Vas a ir al stand de preguntas y respuestas después de esto? Sí, perfecto.