Suspenso Ingenioso

Mi nombre es Minko Gedev. Estoy trabajando en frameworks web en Google, donde una de las tecnologías de las que soy responsable es Angular. Y hoy, en esta presentación, me gustaría explorar las compensaciones de la carga diferida en Angular y React.

Primero, sé que el React Summit está sucediendo mañana. Solo tengo curiosidad, ¿cuántos de ustedes están usando React? Levanten la mano. Sí, diría que alrededor del 80% de las personas. ¿Cuántos de ustedes están usando Angular u otra tecnología? Oh, en realidad, genial. Así que alrededor del 40 al 50% de las personas.

He estado en muchos círculos de React, ya sea en persona o en redes sociales. Y a menudo escucho esta narrativa, Angular es malo. Usualmente, a veces incluso palabras peores, pero, ya saben, código de conducta. Y React es bueno. A veces también escucho lo contrario. O Angular es difícil y React es fácil. Diré que generalmente cuando escuchas eso, hay algo de verdad en ello. Pero al mismo tiempo, cuando hay una declaración muy fuerte, generalmente es un poco unilateral. No ha sido, como, holístico sobre todo el conjunto de características de un framework o diferentes contextos de ejecución.

Así que por eso quería que tuviéramos una perspectiva un poco más matizada al mirar solo una característica de los frameworks de frontend, que es la carga diferida. Diré que hay cientos de otros aspectos de un framework que podríamos querer revisar para tomar una decisión más informada. Pero la carga diferida es algo que probablemente podamos cubrir en los próximos 20 minutos.

Así que en la presentación de hoy, vamos a ver una aplicación de comercio electrónico que tengo en Angular y que implementé yo mismo en React. Vamos a mejorarla con modelos de lenguaje grandes. Porque, ¿por qué no? Me ha encantado lo que los modelos de lenguaje grandes pueden proporcionar a la interfaz web. Vamos a usar suspense para la carga diferida de características y recursos particulares y vistas diferidas, que es la alternativa de Angular a eso. Y al final, vamos a tocar un patrón llamado hidratación incremental.

Solo por curiosidad, ¿han oído hablar de la hidratación incremental? ¿Levantarían la mano? Bien. Genial. Así que, para contexto, he estado involucrado en Angular de una forma u otra durante unos 12 años. He sido un contribuyente de la comunidad. Antes de eso, estaba usando AngularJS. Después de eso, me uní al equipo como contratista. Y he estado liderando la hoja de ruta del producto durante los últimos tres, cuatro años más o menos.

Todo comenzó para mí con este correo electrónico justo aquí. Acababa de terminar mi pasantía y me preguntaba qué hacer. Fui a tomar un café. Y vi que en mi bandeja de entrada estaba este correo electrónico, una startup respaldada por capital de riesgo quería que les ayudara a construir su interfaz web. Y tenía que elegir una tecnología para el propósito. Nunca estuve realmente alineado con mis valores fundamentales en ese entonces para escribir código comprobable y mantenible. Así que elegí AngularJS. Y comencé a codificar este proyecto. Literalmente estaba en mi dormitorio universitario en Bulgaria. Estuve enviando mucho código durante unos dos meses antes de que mis exámenes finales terminaran el proyecto. Así que, en general, fue un éxito. La startup no tuvo ajuste de mercado, por lo que fracasó. Pero mi aplicación Angular funcionó.

Después de eso, hablé con los mismos inversores y fundadores de la startup y les mostré una idea que tenía sobre el uso de máquinas virtuales en el navegador. Y convertimos eso en una idea, en una empresa llamada Rime.com. Y tuve que construir un front end para esta startup, para este producto. Era bastante ambicioso, diría yo, varios cientos de miles de líneas de código. Y eso estaba sucediendo unos años después, en 2014, 2015, cuando mis elecciones tecnológicas eran AngularJS, React y Angular. Era un desarrollador experimentado en AngularJS en ese entonces. Pero también sabía que AngularJS pronto desaparecería. Angular al mismo tiempo estaba lejos de ser estable, así que sabía que si usaba Angular, probablemente tendría que reescribir mi aplicación varias veces hasta que se graduaran a estable en la versión 2. Así que terminé eligiendo React.

Y realmente me encantó React. Era como, me encanta su sólido modelo de respaldo teórico con programación funcional. Me gusta el diseño ortogonal donde tienes conceptos no superpuestos. Así que terminé usando React. Todo mi equipo lo adoptó. Y construimos un producto que terminé presentando en ng-conf, una conferencia de Angular. Así que me sentí un poco como un caballo de Troya allí. Estaba contribuyendo a Angular en mi tiempo libre.

Así que estaba en esta conferencia, pero mi producto se lanzó con React. Pasó el tiempo. Coursera terminó adquiriéndonos. Y en lugar de unirme a Coursera, terminé uniéndome al equipo de Angular en Google debido a mis contribuciones en mi tiempo libre. Así que tengo algo de experiencia con React, pero definitivamente no soy un experto en React. Y he estado usando Angular y desarrollándolo durante los últimos años también.

Así que para esta presentación, tenemos dos aplicaciones, una aplicación de Angular, una app de comercio electrónico. Y construí un clon de esta aplicación con React en un par de días con Curser. Fue un gran impulso de productividad para mí. Esta es mi primera aplicación no trivial de React en unos siete años. Así que aprendí muchas cosas mientras lo hacía también.

Por supuesto, estoy trabajando en frameworks web. Así que uso otros frameworks solo para ver qué conjunto de características tienen. Pero generalmente, construiré una pequeña app, y profundizaré mucho en un conjunto de características en particular. Esta vez, construí una aplicación que está más cerca de una app del mundo real, aún muy pequeña, aún muy básica, pero usando una gestión de estado adecuada, teniendo algunas acciones asincrónicas y cosas. Aquí es cómo se ve. Puedes simplemente explorar, como navegar en diferentes productos, agregarlos a tu carrito. Y tenemos la funcionalidad exacta, la misma funcionalidad exacta para Angular también.

También hay algo de asistencia de AI que quería demostrar aquí mismo en la aplicación de Angular porque simplemente se ve mejor porque alguien más que tiene mejor sentido del diseño la construyó en lugar de que yo construyera la aplicación de React. Así que tenemos la funcionalidad aquí. Y tenemos este chat donde podemos hablar con Jim y yo y preguntarle sobre productos. Y Jim y yo responderíamos con lo que tenemos en la tienda. Y puedo preguntarle. Déjame ir al carrito primero. Angular. Podemos pedirle que realice acciones en mi aplicación, como, por ejemplo, agregar artículos a mi carrito y realizar el pago.

Vas a ver por qué tengo esta funcionalidad en un momento. Quería construir una experiencia de chat un poco más sofisticada. Y funciona de manera bastante similar allí. Es bastante simple, en realidad. Lo que tienes es simplemente una función async enviar mensaje en el cliente. Cuando enviamos este mensaje al servidor, lo procesamos aquí. Estoy instanciando el modelo GenKit que está respaldado por Jim y yo 2.0 Flash. Estoy enviando solicitudes a Jim y yo y obteniendo una respuesta. Y eso es todo. Ni siquiera estoy usando streaming aquí, porque quería mantenerlo lo más simple posible.

La funcionalidad para agregar artículos al carrito es un poco más interesante. Es algo llamado function calling. Porque podemos pasar una cadena a Jim y yo, y puede devolver parámetros de función que luego podemos invocar en nuestro sistema. Así que lo que hice con el chat es que el cliente envía una solicitud al servidor. En este caso, con un prompt, agregar camisetas de Angular a mi carrito. El servidor reenvía esta información a Jim y yo junto con un esquema de todos los métodos disponibles que tenemos en nuestra aplicación. Desde allí, Jim y yo, mirando el esquema, devuelve la acción particular, digamos agregar al carrito, y proporciona los parámetros.

En este caso, dos camisetas. Y la camiseta es un artículo con ID, en este caso, 123. Llamamos a add to cart en el servidor, y también actualizamos la UI. Así es básicamente cómo funciona. Y la funcionalidad tiene una implementación bastante simple también.

Muy similares características, muy similar código que te mostré, con la diferencia de que también estamos añadiendo una herramienta, que es esta funcionalidad de añadir al carrito, la cual proporciona un esquema. Y proporcionamos la herramienta como parte de la llamada AI.generate. Y en el cliente, enviamos el mensaje usando nuestra función async.

Añadimos este mensaje a la lista de mensajes que tenemos en el chat para que podamos visualizar todos los diferentes mensajes en nuestra app. Después de eso, verificamos si hay un producto que necesitamos añadir al carrito, si el usuario ha invocado alguna acción en particular. Y si hay uno, simplemente lo añadimos al carrito. Eso es básicamente todo, bastante simple. Genial, así que ahora estamos listos para AI.

Ahora, podemos acelerar esta aplicación. Tenemos nuestra elegante funcionalidad de AI, pero aún así, la mayoría de las personas están acostumbradas a usar tiendas de comercio electrónico simplemente navegando y haciendo clic a través de la aplicación. Así que diré que la gran mayoría de los usuarios realmente no usarían este chatbot, aunque lo tengamos. Entonces, ¿por qué tenemos que cargarlo como parte del tiempo de carga inicial de la aplicación? No realmente tenemos que hacerlo. Podemos retrasarlo. Y tenemos exactamente la misma funcionalidad en React aquí.

Para cargar esto de manera diferida en React, asumo que usarás suspense, ¿verdad? Primero, usamos react-lazy para que podamos crear este componente diferido que luego podemos cargar con suspense. Declaramos este estado local en nuestra aplicación con use states, si el cuadro de chat está expandido o no. Si está expandido, renderizamos el límite de suspense. Y mostramos una carga de reserva. Eso es básicamente todo. Diré que es bastante sencillo.

Hay algo de lógica imperativa, pero es muy fácil de razonar. Aquí está la implementación alternativa en Angular. Está completamente en la plantilla. Angular tiene plantillas que añaden algunas semánticas adicionales. Tenemos algo llamado vistas diferibles, que proporciona este bloque diferido, donde especificamos una condición cuando queremos cargar algo como parte de la UI. Y proporcionamos un marcador de posición, o un indicador de carga. Genial. Eso fue todo. Diré que las funcionalidades aquí eran bastante equivalentes, un poco más imperativas, potencialmente, en React, porque lo hicimos con JavaScript. También hay carga de datos. Ahora, veamos.

Podríamos querer configurar nuestro chat de cierta manera. Digamos proporcionar el nombre del usuario para que podamos pasarlo como parte del prompt, o como parte de los parámetros de URL que estamos enviando a Gemini más adelante. Así que en este cuadro de chat aquí, nos gustaría proporcionar algunos datos.

En React, podemos usar suspense nuevamente. Tenemos nuestra promesa en caché y la función getConfig. Que verifica si la promesa existe, si la hemos establecido en un valor. Si no es así, no. La devolvemos. Alternativamente, enviamos una solicitud para obtener el nombre del usuario, y asignamos la promesa, devuelta por fetch, a la promesa de datos.

Y más adelante en el chat, usamos el hook use para que podamos llamar a nuestro getConfig e implementar esta suspensión de datos. Y todo esto parece genial, ¿verdad? Pero bueno, al no usar React durante siete años, obtuve este error. No funcionó. ¿Puedes adivinar qué salió mal aquí?

Ojalá hubieras estado allí conmigo, entonces. Pasé algún tiempo. Afortunadamente, también pude pedir ayuda a Jim y a mí. Y descubrí que el problema venía de mi async. No me di cuenta de que tenía una función async que está devolviendo una promesa. Así que mi promesa está siendo robada por otra promesa. Y cada vez estoy obteniendo una nueva promesa, así que debido al modelo de ejecución de React, suspense simplemente no funciona, ya que cada vez estoy obteniendo una promesa diferente y esta función se invoca cada vez para que pueda producir el DOM virtual para que React pueda realizar la reconciliación. No es muy obvio, pero puedes aprenderlo, ¿verdad? Después de un poco de dolor de cabeza.

Otra observación interesante aquí es que este componente particularmente depende de sus propios datos. Y en este caso, es un componente de chat que hemos envuelto en suspense. Pero también podría ser cualquier otro hijo transitivo de este componente. Así que si tenemos un árbol de componentes más complicado, el chat consta de muchos otros componentes, si alguno de estos componentes, incluso como un componente hoja en el árbol de componentes, tiene algunos datos no resueltos, nuestra aplicación seguirá cargando. Así que tiene sus propios compromisos. No es necesariamente bueno o malo. Es bueno en cierto sentido que cada componente tenga sus propios datos, como depende directamente de ellos. Al mismo tiempo, a veces puede no ser muy trivial de depurar. Así que necesitaríamos herramientas de depuración un poco más sofisticadas que nos muestren los componentes y sus dependencias.

Aquí es cómo logramos lo mismo en Angular. Creamos un recurso HTTP donde enviamos una solicitud a través de la red, API user. Y siempre que el recurso se esté cargando, mostramos un indicador de carga. Siempre que hayamos cargado los datos, simplemente los pasamos al chat. Así que hay un par de diferencias aquí. Diré que la principal diferencia es que hemos extraído la carga de datos en el componente padre. Así que el hijo siempre recibiría los datos que está esperando. Es un flujo de datos muy explícito. Nuevamente, no es bueno ni malo, solo diferente. Será más fácil de depurar. Diré que probablemente sea más fácil de razonar. Ahora veamos otro ejemplo. Cargando componente antes de debajo del predeterminado.

Así que obtuve la inspiración para esta funcionalidad de amazon.com, donde hay una sección con productos patrocinados en la parte muy inferior de la página. Y solo quiero cargarla de manera diferida porque está por debajo del predeterminado. Probablemente no tengo que esperar por ella. Simplemente no tengo que esperar a que esta funcionalidad se cargue para poder mostrar el conjunto inicial de elementos al principio. Me gustaría cargar esta funcionalidad y renderizarla cada vez que el usuario se desplace hacia ella.

En React, usamos un enfoque similar con suspense. Así que tenemos nuestro flag showRecommended, que siempre que sea verdadero, vamos a renderizar el suspense boundary. Y vamos a renderizar nuestro producto recomendado de manera diferida. Aún bastante sencillo y mayormente declarativo. La parte complicada viene cuando establecemos el showRecommended a verdadero. Hay algo relacionado con la visibilidad del elemento de productos recomendados. Así que probablemente tengamos que usar la API del navegador, IntersectionObservers. Y aquí es cómo podemos gestionarlo. Usamos efectos. Pasamos un array vacío de segundos argumentos porque eso es lo que haces, supongo.

Y llamamos a IntersectionObserver. Seguimos cuando este elemento se hace visible. Y cada vez que se hace visible, en algún lugar justo allí después de la declaración if, establecemos nuestro showRecommended a verdadero. También necesitamos recordar desconectar el IntersectionObserver para no tener fugas de memoria. Y esa fue la funcionalidad en React. Y aquí está el equivalente en Angular. Prácticamente lo mismo que el ejemplo anterior. Tenemos una vista diferible donde especificamos que cada vez que este componente entra en el viewport, nos gustaría renderizarlo. Alternativamente, estamos mostrando un espaciador.

Se complica aún más cuando queremos añadir prefetching. Así que tenemos la funcionalidad de antes. Y si quisieras hacer prefetch de esta funcionalidad, los productos recomendados, cada vez que el navegador esté inactivo, digamos, necesitamos hacer otro use effect con requestIdleCallback y usar preloadModule, especificando la ruta. Si queremos hacer eso en Angular, todo lo que necesitamos hacer es añadir la directiva prefetch on idle. Genial.

Así que en la última parte de la presentación, quería tocar el tema del renderizado en el servidor. Porque si estamos construyendo una plataforma de comercio electrónico, probablemente querríamos renderizar la aplicación en el servidor para poder mostrar rápidamente los productos al usuario y aumentar su tasa de compromiso. Algo con el renderizado en el servidor es que enviamos una solicitud al servidor. El servidor renderiza nuestra aplicación. Recibimos HTML. El navegador analiza este HTML. Y comenzamos a descargar todo el JavaScript asociado con la página. Desde allí, ejecutamos el JavaScript. Y finalmente, podemos manejar las interacciones del usuario, lo que significa que cuanto más JavaScript tengamos, mayor será esta brecha.

Y por más tiempo, no podemos responder a las acciones del usuario. Así que lo que podemos hacer es renderizar parte de la página, por ejemplo, las recomendaciones de patrocinadores, pero no cargar el JavaScript asociado con ella. Porque nos gustaría cargarlo e hidratar esta parte de la aplicación solo cuando esté en el viewport o cuando el usuario interactúe con ella. Esta técnica se llama hidratación incremental o parcial dependiendo de dónde la estés usando. En la definición, no hay definiciones muy específicas. Todos están usando el término un poco diferente. Para hacer eso con Angular, tenemos esto llamado snippets. Todo lo que necesitamos hacer es cambiar el bloque predeterminado, en lugar de estar solo en el viewport, para ser hydrate on viewport. Y eso es todo.

Estoy seguro de que también podemos lograr eso en React. También podemos usar server components modificando toda nuestra aplicación. Pero es bastante sencillo hacer eso en Angular.

Ahora, ¿significa eso que React es malo y Angular es bueno? ¿O que React es difícil y Angular es fácil? Bueno, diré que se trata de compensaciones. En esta presentación, en los últimos 20 minutos más o menos, pudimos explorar algunas de las compensaciones de los sistemas de plantillas, o el tipo de composición de todos los frameworks, Angular y React.

Podemos ver que JSX es muy minimalista. Es fácil de aprender. Y lo compones con JavaScript. Puedes volverte productivo muy rápidamente con él. Las plantillas de Angular son muy expresivas al mismo tiempo, porque este es un lenguaje que el equipo de Angular está manteniendo. Así que podemos expresar características muy complicadas de una manera muy compacta. Además, las plantillas son optimizables estáticamente.

Así que tenemos un modelo de ejecución diferente. No necesariamente tenemos que invocar cada componente en cada renderizado, o usar diferentes trucos con la memorización. Podemos simplemente llamar al componente una vez para el renderizado inicial, y desde allí actualizar las partes dinámicas. Simplemente diferentes compensaciones. Y hay muchos otros aspectos de un framework frontend que podemos observar, como la creación de plantillas, el modelo de componentes y el ciclo de vida, la abstracción en tiempo de ejecución, la elección del lenguaje, ya sea solo JavaScript o TypeScript, la reactividad. Y hoy solo vimos la carga diferida.

Así que supongo que evaluar un framework de JavaScript es mucho más interesante que el binario, bueno o malo. Es un problema multidimensional, y es bastante divertido, en realidad. Para tomar una solución realmente buena, como una decisión realmente buena sobre qué framework deberíamos usar, podemos mirar el espacio del framework de manera más holística y mapear las características individuales a los problemas que estamos resolviendo.

Así que supongo que mi llamado a la acción aquí será ir y probar tantos frameworks como puedas, y ver cuál funciona mejor para ti. Gracias. Eso es todo lo que tengo para ti.

¿Cómo funciona suspense con SEO usando renderizado del lado del servidor? Así que, por ejemplo, lo que mostraste con la sección de artículos patrocinados. Sí. Sí. Bueno, puedo comentar sobre las vistas diferibles, porque solo mostré el equivalente en Angular. Eso tiene sentido, sí. Todo se renderiza, así que supongo que el bot, el rastreador, podrá ver el contenido e indexarlo. No va a tener JavaScript, así que eventualmente si hay una acción que aparece dinámicamente, probablemente el rastreador tendrá que interactuar con ella para ver qué está pasando allí.

Sí, supongo que hay una especie de, ¿hay una manera de bloquear que sea recogido por SEO? Porque normalmente, creo que no quieres que tus artículos patrocinados, por ejemplo, aparezcan necesariamente en tus resultados de búsqueda. Sí, puedes si quieres, sí. Muy bien, encantador. ¿Qué más tenemos? OK. Por supuesto, hay mucha emoción sobre el lado de la IA. Así que hubo una pregunta rápida sobre Gemini, y cómo sabe esa API de Gemini cuáles son las funciones en el servidor. Por ejemplo, tu funcionalidad addItemToCart.

Sí. Así que como parte del registro de herramientas, esto es en realidad estoy usando un envoltorio específico de la API de Gemini por GenKit. Allí estás especificando todas las funciones disponibles, lo cual es una forma muy declarativa de especificar cuáles son las funciones y cuáles son sus parámetros. Así que Gemini puede mapear el texto a una función y parámetros. Sí, en realidad soy bastante fan de GenKit. No creo que muchas personas, y creo que suficientes personas conozcan GenKit todavía. Es muy genial. Ve a ver GenKit para hacer este tipo de cosas. Tienes que entrar y describir esas cosas. Todo en el prompting y Gemini y todo tipo de cosas de Gen AI se trata del prompt. Así que solo le dices que tienes estas funciones, y funciona.

Preguntaré, esta pregunta tal vez llegó en un momento específico. No, acaba de suceder ahora mismo. ¿No sería fácil crear un componente JSX que abstraiga la misma lógica de la que has estado hablando? Así que supongo que si estás trabajando en React. Sí, puedes extraer la lógica de los intersection observers en si va a ser un componente o algo más. Sí, puedes hacer eso. Aún necesitas escribirlo una vez. Sí, eso es cierto. Sí, todavía no es tan fácil como simplemente estar allí.

Fue algo mágico verte simplemente decir, oh, esto. Pero, ¿qué pasa con estas cuatro líneas? Sí. Pero sí, no te impide hacerlo. Sí, si React es lo tuyo, todavía va a estar allí. Ups, dije eso. Lo siento, estoy recibiendo repeticiones allí por alguna razón. OK, ¿hay algún plan para agregar más estrategias de precarga de rutas a Angular, como la biblioteca ngx-quicklink en la que aparentemente trabajaste? Sí, probablemente no funciones integradas que vayan a ser parte del framework. Pero puedes declarar, como, personalizadas, el quicklink. Todavía lo estoy manteniendo, así que si quieres usarlo. Ahí lo tienes.

No need to. Sí, sí, genial. Y bien, ¿puedes explicar más sobre cómo y cuándo se llama a requestIdleCallback, y cómo lo manejarías específicamente en Safari? Sí, entonces el navegador vería cuándo hay ancho de banda disponible para la ejecución. Y si tiene un par de milisegundos libres, va a invocar las funciones que hemos programado en requestIdleCallback. No sé si esta API está disponible en Safari específicamente. Si no lo está, probablemente puedas hacer un polyfill de manera subóptima con, como, alguna programación de pruebas. Es un polyfill difícil, ¿no? Sí. Genial.

Bien, esto podría ser algo controvertido. No lo sé. ¿Van a reemplazar los signals a RxJS en Angular? Bueno, para cosas particulares, hemos querido usar signals, específicamente cuando estás gestionando los estados locales de los componentes. RxJS, sigue siendo muy conveniente cuando tienes un flujo de datos. Y prefieres usar los operadores de alto nivel allí que proporcionan. Sí. Supongo que tal vez lo que la pregunta intenta abordar es, tratar todo como un flujo fue tal vez demasiada abstracción para cosas que no piensas como un flujo. Sí, eres genial leyendo entre líneas. Quiero decir, eso es lo que siempre he pensado con cualquier tipo de cosas reactivas, de todos modos, es que es como, todo es un flujo. ¿Y si no es un flujo? Sigue siendo un flujo. Sí. Veo a personas así con expresiones regulares, también. Puedo resolver este problema con expresiones regulares. ¿Por qué no? Así que todo tendría. Tan cierto. Sí.

El mejor consejo con las expresiones regulares es intentar otra cosa primero. Sí. Absolutamente.

OK, todavía tenemos algunas preguntas aquí en la sección pendiente, que, oh, están allá arriba. OK, genial. Lo sé, lo siento.

¿Crees que la gente, OK, esta es una pregunta más amplia sobre todo el asunto. ¿Crees que la gente elige frameworks basándose en la popularidad y familiaridad en lugar de sus pros y contras? Sí, diría que ese es un punto muy válido también. Si vas a elegir un framework, querrás elegir algo con lo que vayas a encontrar personas para construir tu aplicación, como personas con experiencia. Correcto, sí. Las preocupaciones son más que solo sobre el código. Sí. Sí. Sí, necesitas personas que puedan construirlo contigo. Sí. También está el modelo de mantenimiento, si este producto simplemente desaparecería si el mantenedor se quema o quiere tomarse un descanso. Sí. Muchas cosas diferentes. Creo que también mencionaste al final de la charla que lo importante es probar un montón de frameworks. Y de esa manera, estás lidiando con tus propias experiencias y no solo con lo que tiene más estrellas en GitHub o más descargas en NPM. Sí, diría que lo que sea más de moda en Twitter o en hacker news, tomar una decisión basada en eso, diría, podría salir mal a largo plazo. Sí. O podría no ser simplemente la opción más óptima para ti. Correcto. Correcto, sí. Y no ser la más óptima no es lo peor del mundo. Pero solo tienes que ser consciente de ello. Sí, sí. Genial.

Oh, OK. ¿Disfrutaste usar React después de tanto tiempo? ¿Y hay alguna característica interesante que descubriste en React mientras jugabas con él que te gustaría ver de vuelta en Angular? Bueno, tienen modelos de ejecución muy diferentes. Diré que disfruté la simplicidad de la experiencia de alteración en React. Y hay algunas otras características en React, que también hay características en otros frameworks, como Svelte, por ejemplo, donde puedes directamente importar un componente y usarlo en tu plantilla. ¿Por qué necesitas tener múltiples dinámicas diferentes co-ops para declarar? Estas son algunas cosas que hemos estado considerando durante mucho tiempo. Sí. Sí, agradable. Supongo que sí. El equipo de Angular, supongo que en general, está mirando otros frameworks, lo que están haciendo, para aprender de ellos. Sí. ¿Y traer lo mejor? Sí, y algunas cosas simplemente tienen sentido. Algunas decisiones las tomamos hace mucho tiempo. Y podemos revisarlas. Sí, agradable. Agradable.

OK. ¿Qué tan diferente es este DSL de Angular cuando estás escribiendo en TypeScript? Este es específicamente un formato de plantillas, que se compila a TypeScript. Tenemos un compilador que convierte nuestras plantillas en instrucciones de TypeScript. Así que no es diferente. Si quieres, teóricamente la gente puede escribir este código ellos mismos. Pero no lo recomendaría. Nuestro compilador sabe cómo optimizar las plantillas. Es una característica que tienes. Es una de las razones por las que usas Angular, es para que haga mucho trabajo por ti. Sí. Agradable.

Muy bien. Nos queda aproximadamente un minuto. Voy a hacer esta la última pregunta por ahora. Porque también tengo que prepararme para hablar a continuación.

¿Existen desventajas en la partial hydration en Angular? ¿Hay un retraso visible entre la acción del usuario y la respuesta, particularmente en internet móvil lento o 3G? Sí. Voy a añadir algo durante cinco segundos sobre la pregunta anterior. Y voy a responder a esta. La pregunta anterior, también, estamos tratando de mantener nuestras plantillas lo más cercanas a TypeScript como sea posible para que sean fáciles de usar. Sí, agradable. Sobre la partial hydration, sí, puedes dispararte en el pie si tienes muchos niveles de anidamiento y tienes un waterfall. Así que evita los waterfalls. Sí. OK, agradable. Bien. Bueno, eso es todo el tiempo que tenemos para esto. Me gustaría que todos los demás agradecieran a Minko nuevamente por una charla maravillosa. Muchas gracias. Sí. Gracias a todos.