Viviendo al Límite

Espero decepcionar a todos aquí. Ha pasado un tiempo. Han pasado dos años desde que estuve en el escenario. Mi nombre es Sunil Pai, trabajo en Cloudflare en el equipo de workers. Solía estar en el equipo de React. Se deshicieron de mí bastante rápido.

Y tenemos cosas de React de las que hablar, pero antes de hacerlo, quiero comenzar diciendo que los he extrañado mucho a todos. Esto es tan extraño. Conocí a muchas personas en la cena de los oradores ayer. Es agradable intercambiar historias, hacer los mismos abrazos incómodos. Está el abrazo de hermano, está el abrazo de 200, está el choque de puños, está el extraño saludo de codo y creo que es hora de retirarlo. Pero las cosas han cambiado para mí. Como pueden ver, ahora me corto el cabello mucho mejor. Me visto un poco mejor y especialmente para la ocasión, saludos a Tom Dale. Espero estar haciéndote sentir orgulloso. He estado comiendo mejor, haciendo ejercicio mejor, pero lo que más me enorgullece y lo comparto con todos mis amigos personales aquí es que hace dos días, terminé 500 días sin fumar. Dejé de fumar. Lo cual es algo bueno. Muy feliz. Estoy muy orgulloso de ello. Esto es lo que he estado diciendo a todos. Me deja con una complicación. Esta ha sido mi imagen de perfil de GitHub durante los últimos 10 años. Desde que tengo uno. Es genial. Usé Photoshop en el pasado cuando tenía una copia pirata. Pero realmente no me representa más. Pero un amigo mío sugirió una pequeña modificación y la subiré más tarde hoy. Creo que es bastante buena. Esto fue hecho por Siddharth Kshetrapal. No está aquí hoy porque su visa se arruinó. Es una lástima, pero espero con ansias su charla. Pero creo que es una buena modificación. Y esa es mi historia hasta ahora. Genial.

Vamos a hablar de la charla. Hay tres cosas que debes saber sobre la charla que estoy dando en este momento. Es un poco aburrida. Hablaremos de un par de APIs, pero si todo va bien, probablemente no tendrás que usarla. Las cosas simplemente sucederán. Y eso es agradable. Eso es algo bueno de React. Todas las mejoras son ligeramente incrementales. Nadie tiene que hacer reescrituras masivas. Puedes dejar el código antiguo tal como está. Esta charla es una charla en versión beta. Al igual que las APIs reales y el hecho de que React 18 está en el horizonte, pero generalmente hay alrededor de un año, dos años de experimentación cuando se lanzan estas cosas. Al igual que eso, esta charla en sí también está en versión beta. Es la primera vez que la he preparado, de lo que estamos hablando, y también significa que tal vez durante el próximo año, mejoraré la charla. Así que si encuentras algún error, lo siento, pero mejorará. Pero esta charla en sí está en versión beta. La charla también trata sobre el futuro. Normalmente no hago charlas sobre APIs, me gusta hablar sobre el trabajo que he hecho, pero esto, creo, es lo suficientemente emocionante como para ser parte del lanzamiento de React que nadie está notando realmente. Todos están hablando de las cosas nuevas y emocionantes, como los componentes del servidor y la concurrencia y todo eso, pero siento que esto en realidad es mucho más definitorio para todas las cosas que haremos en el futuro. Esas son las tres cosas.

Sumergámonos en ello. Este es un Internet Explorer. Así que la E significa Internet, un clásico. Es el único navegador que conozco. Y está hablando con UGLE.com. Es conveniente que ambos sean una E, creo. Y le haces una pregunta. ¿Qué me puedes decir sobre la selva amazónica? Escribes selva amazónica en el buscador. Y el motor de búsqueda dice, OK, espera. Te tengo. Te lo haré saber. Y vuelve a sus servicios, y dice, hey, equipo, todos ustedes, ¿qué tenemos para pi que podamos decirle sobre la selva amazónica? Tal vez haya un equipo de fotos que diga, OK, aquí están todas estas fotos que tengo sobre la selva amazónica. Toma esto. El motor de búsqueda dice, OK, genial. Eso está bien. Funciona. Hay un servicio de vuelos. Imagínate eso, un motor de búsqueda que te ofrece boletos de avión. Creo que sería un servicio increíble. Nadie más lo está haciendo, por supuesto. Y dice, hey, tal vez a pi le gustaría volar a la selva amazónica este fin de semana. Aquí están los boletos. Por supuesto, creo que comienza en diciembre. Va a ser dentro de un tiempo, pero aquí están los boletos más adelante. Hay noticias sobre la selva amazónica, porque no está en un buen estado en este momento. Se está quemando y siendo destruida. Y hay noticias al respecto si quieres leerlo y deprimirte más sobre el estado del mundo. Pero, por supuesto, también hay un pequeño servicio de video. Y dice, hey, aquí hay algunos videos. Si quieres una transmisión de siete horas de exuberante vegetación, también tenemos eso. Increíble. Entonces el motor de búsqueda vuelve y dice, OK, tengo cosas para ti. Aquí está. Permíteme presentártelo. Olvidé. Olvidé que habrá ocho anuncios antes de que llegues a cualquier contenido. Dice, OK, bien. Aquí hay un montón de anuncios. Posiblemente de otro sitio que suena como la selva amazónica. Y aquí hay un montón de contenido. No está mal. Así es como funciona. Comienzas una conversación con un servidor. Obtiene un montón de data. Lo presenta en HTML como un sitio web.

Entonces, si tuviéramos que implementar esto en React como un componente de React, ¿cómo se vería? Bueno, creamos un componente. Llamémoslo un componente de aplicación. Puedes ver el código. Está bien. Puedes ver las diapositivas más tarde. Crearás un componente de aplicación que tiene un encabezado, un pie de página, y escribirás cinco componentes para tus anuncios, imágenes, videos, noticias y vuelos, que toman un montón de data y lo renderizan. Lo pasarás a algo. Así que obtendrás los data antes de renderizar el componente. Dirás, hey, dame todos los anuncios para la selva amazónica, dame las imágenes y videos. Obtén todo y luego renderiza a una cadena. Esto es lo que sucede en el servidor. Por lo general, un metaframework como ExJS se encarga de esto, pero dices obtén los data y renderízalo en él. ¿Seguro? De acuerdo. Así es como funciona. No es genial. Hay algunas compensaciones con este modelo que quizás hayas notado. Una de ellas es que no puedes realmente ubicar las solicitudes, digamos, obtener data con el componente real que lo solicita, especialmente en el servidor. Probablemente podrías hacer esto en el lado del cliente, pero en el servidor, porque es algo de una sola vez, no puedes juntarlos, tienes que obtener todos los data primero y renderizarlo, o tienes que hacer, como, otras cosas. Bloquea toda la página en los data. ¿Puedes imaginar, como, no podrás ver ninguna de las fotos hasta que todos los videos también se hayan obtenido, o si uno de ellos es más lento, los otros están bloqueados? Necesita obtener todos los data antes de que realmente lo renderice. Por eso terminas haciendo trucos, ¿verdad? Es genial, hay todo un ecosistema de frameworks por ahí como tu ExJS y bibliotecas de obtención como Apollo y Relay y un montón de cosas de GraphQL. Pero admitámoslo, es un poco chapucero que tengas que construir algo separado que no está dentro de React mismo para hacer estas cosas. Al principio estaba bien porque implicaba experimentación, pero ahora tienes que unir todo y usar un metaframework para hacerlo. Es un poco ew. No es perfecto, ¿verdad? Te sientes un poco incómodo con la situación. Siempre tienes que hacer compensaciones. ¿Haces toda tu compilación cuando construyes la página? ¿Y si es un sitio con cien mil páginas? ¿Tienes que hacerlo dinámicamente? Es un poco extraño. Pero este es el estado en 2021. Está bien. Quiero decir, se han creado muchas startups y empresas multimillonarias en torno a esta API y otras cosas, por supuesto. Por supuesto, es el sitio web el que te dio el dinero. No creo que debamos conformarnos con esto. Podemos hacerlo mejor. Esta es una comunidad que se basa en la experimentación y la innovación. Así que dejemos eso de lado por un momento y hablemos de una característica que tiene Internet. Es una idea llamada streaming. La idea es que deberías poder enviar los data tan pronto como estén listos, incluso antes de tener todo lo demás. No quiero entrar en demasiados detalles técnicos al respecto. Puedes buscar la codificación de transferencia por fragmentos para HTTP 1.1 y hay algo más para HTTP 2. Hay un montón de especificaciones. Intentaré explicarlo de la manera más sencilla posible. Así que tomemos el mismo sitio web y gíralo hacia un lado. Imagina que vienes de ese lado hacia este lado. No. Sí. Ese lado hacia este lado.

¿Verdad? En tu método de una sola vez, lo enviarías todo de una vez, pero en el método de streaming, lo estirarías como un chicle y enviarías los fragmentos tan pronto como estén listos. Podrías enviar un encabezado de inmediato, luego los anuncios tan pronto como estén listos y luego las fotos, los vuelos, las noticias, los videos y finalmente el pie de página. ¿Cómo se vería para un usuario cuando comienza a cargar el sitio? Comenzarías con el encabezado, esperarías un poco y luego aparecerían los anuncios, esperarías un poco más y aparecerían las fotos y los vuelos y las noticias y los videos y luego el pie de página. Eso es mejor. Al menos no estás bloqueando, como, solo la carga del encabezado, esperando a que se carguen cosas como el contenido, lo cual está bien. Y para ser justos, creo que Google realmente hace streaming. Pero no podemos hacer esto en el mundo de React hasta ahora, por supuesto, porque todavía es de una sola vez. Podemos hacerlo mejor. Cualquiera que me conozca sabe que este es mi lema. Lo bueno de ser un ingeniero de UX es que no hay límite superior en cuán buena puedes hacer la experiencia del usuario, ¿verdad? Simplemente puedes seguir mejorándola cada vez más. De todos modos. Eso fue el streaming. Así que mantengamos esa idea a un lado. Después de todo, esto es una conferencia de React.

Hace un par de años, se lanzó una función experimental en React Conf 2019. Vaya, eso fue hace dos años. Ha pasado un tiempo. De todos modos. Anunciaron una función llamada suspense. Puedes marcar componentes como React.lazy y se cargarán de forma asíncrona y usar suspense para marcar un spinner. También hay obtención de data. El problema es que realmente no funcionaba con la representación en cadena y la representación en el servidor. Algunas personas lo usan para aplicaciones del lado del cliente, y es bueno. Es un buen modelo. Así que vamos a sumergirnos rápidamente en ello y ver cómo se ve.

En este modelo, para el mismo flujo de página que acabamos de discutir, tendrías, digamos, un componente de anuncios que obtiene algunos data en su interior y luego representa ese data. Una cosa rápida a tener en cuenta es que hay un pequeño problema. Observa que no hay una declaración de espera, y la forma en que React lo hace es un poco peculiar. Si estás interesado en conocer los detalles, lanza una promesa. No importa para un desarrollador mientras lo estés usando. Simplemente lo escribes como un código síncrono y lo puedes usar. Por cierto, he estado usando GitHub co-pilot, y escribió todo el código por mí después de esto. ¿Todos lo han estado usando? Es un poco aterrador. Es IA para tu código. Completa tu código. De todos modos, también tendrías un componente de imágenes que simplemente toma el término de búsqueda, averigua qué imágenes hay para él y genera el HTML que, bueno, el árbol DOM que funcionaría para ello. De manera similar para videos y anuncios, y así sucesivamente. Y luego lo que harías es volver a visitar tu componente de la aplicación y envolver todo esto con un componente suspense y darle un fallback. Digamos un spinner. Y lo bueno de la experiencia para esto, cuando es una aplicación del lado del cliente, es que tendrás un spinner que espera a que todos los data se carguen y luego finalmente los representa eso. Así que la experiencia sería, hey, renderizarías un encabezado y un pie de página y un gran spinner en el medio. Debería elegir uno mejor. Por ahora está bien. Lo enviaré. Espera por ello. Espera por los data y tan pronto como eso esté hecho, representa el contenido. No está mal. Pero podemos hacerlo aún mejor. Ese es el mantra para hoy, ¿verdad? Digamos que también puedes marcar cada uno de los componentes con un límite de suspense. Y digamos, por el bien de la discusión, que cada uno de ellos tiene el mismo spinner. Los envuelves a todos. Y luego la experiencia de carga para ello es, hey, comienza con cinco spinners. Tal vez los vuelos se carguen primero. No está mal. Luego, después de eso, tal vez los anuncios se carguen. Luego, tal vez cerca uno del otro, las noticias y los videos se carguen. Y luego, justo después de eso, se cargan las fotos. Eso tampoco está mal. Al menos no espera por todo. A medida que llega el contenido, se representa. Aún no es genial. Quieres cargarlo al menos en orden, incluso si el data se resuelve. Podemos hacerlo mejor. Uno de mis componentes favoritos, un componente llamado suspense list.

Ahora, marca eso en verde. Puedes ver el código más tarde. Pero en realidad puedes agrupar componentes de suspense. Y puedes decir, hey, revela estos en un orden adelante. También puedes hacerlo al revés. Puedes hacerlo todo junto. Es muy divertido. Siéntete libre de probarlo.

De todos modos, puedes decir, hey, asegúrate de que los anuncios se carguen primero. Al menos se renderizan primero, incluso si los data para los demás se cargan más tarde. Solo para que quede claro, los data de todos ellos se están cargando al mismo tiempo. Asegúrate de que se renderice el primero. Y luego agrupo los otros cuatro y establezco otra lista de suspense. Lista de suspense anidada. Eso es genial. Y digo que también quiero que esos se carguen adelante. De acuerdo. Entonces, ¿cómo se ve la experiencia para eso? Nuevamente, comenzamos con aproximadamente cinco spinners. Puede haber data para que los anuncios se carguen. Es posible que se haya cargado algún contenido para los demás, pero hemos marcado que necesita cargarse en este orden. Se cargan las fotos. Y el siguiente se carga muy rápido, por lo que tus vuelos, noticias y videos se cargan. Esa es una experiencia de usuario mucho mejor.

Pero el problema aquí, por supuesto, es que ahora es una aplicación completamente renderizada en el lado del cliente, ¿verdad? Así que tenemos estas dos compensaciones. Uno, podemos generar todo el HTML en el lado del servidor, pero tienes este modelo de programación desordenado y tienes que asegurarte de tener hacks o una gran cantidad de optimizaciones. Eso no encaja muy bien con el modelo de React. O puedes hacerlo completamente en el lado del cliente y tener ostensiblemente una mejor experiencia de usuario una vez que se cargue todo el JavaScript, pero el rendimiento de carga es peor. Se tarda mucho tiempo en cargar el JavaScript y luego las solicitudes tienen que ir desde el navegador. Así que tienes que elegir una u otra. ¿Verdad? El mantra. Podemos hacerlo mejor.

Esta es la API de la que he estado hablando. Toma render to string, que hemos estado usando durante los últimos cinco años y ha sido bueno. Y lo reemplaza con render to readable stream. Así que ahora podemos hacer representación en streaming con React. Solo quiero resumir lo bueno que es esto. ¿De acuerdo? Así que vamos a resumirlo. Vamos a ver lo mismo que vimos justo antes de esto. La representación en streaming tradicional se ve así. Se estira como un chicle o una banda elástica, supongo, lo que sea. Y comienza a cargar las cosas una tras otra. Entonces se carga el encabezado. Luego se cargan los anuncios. Fotos. Y todos estos espacios en blanco. Lo cual está bien. Pero se está cargando. ¿Verdad? Y videos y el pie de página. Así es como se vería si hubiéramos utilizado la representación en streaming tradicional. Lo cual no podemos, solo para que quede claro.

Y posiblemente cómo Google ya lo hace. Pero con render to readable stream. Puedes comenzar con los spinners. Espera un poco. Se cargan los anuncios. Las fotos. Los vuelos. Las noticias. Los videos. Y aquí está lo interesante. Toda esa experiencia ocurre antes de que se cargue cualquier JavaScript. Toda esta experiencia está sucediendo en el HTML. Puedes tener una experiencia de usuario superior sin JavaScript en tu página.

Entonces, ¿cómo lo hace realmente? Es bastante genial. Tengo una diapositiva para mostrarte esto, pero realmente deberías profundizar en ello después de esta charla. Lo que hace es enviar esa estructura por adelantado. Y lo sabe porque ese es el modelo de componente que hemos creado. Pero tan pronto como la página termina, comienza a introducir pequeños divs ocultos con el contenido dentro. No es tan sofisticado como parece. Es bastante ingenioso. Y tan pronto como se cargan cada uno de estos fragmentos, es como una línea de JavaScript. Una llamada de función que simplemente dice, hey, toma este div y reemplaza el spinner con este contenido. No hay React en la página, nada. Incluso puedes eliminarlo y aún obtienes la misma experiencia. Así que eso es bastante genial, creo. Y esto es bastante fundamental para el resto de React. Innovación que probablemente veremos en el próximo año. Componentes del servidor, lo nuevo construido sobre esta tecnología. Cualquier idea que tengas para nuevas bibliotecas de CSS y JS, porque ha pasado un tiempo desde que tuvimos una nueva. Podrías hacer 12 más en el próximo año. Es posible que desees asegurarte de que funcione bien con el modelo de representación en streaming. Ahora, la obtención de datos se vuelve mucho más interesante, ¿verdad? Ahora, en lugar de que el paso de hidratación sea un bloque de datos que simplemente inyectas allí, puedes hacerlo pieza por pieza si quieres. Muchas cosas divertidas.

De todos modos, solo para recapitular. Las nuevas características del servidor que tenemos, una vez que reemplaces render to string con solo una línea, que es render to readable stream, el suspense simplemente funciona. Esto es muy importante. No ha funcionado durante los últimos dos años, por eso mucha gente ni siquiera lo ha usado en aplicaciones de React, pero ahora, simplemente funciona. React.lazy, todo eso. Puedes crear patrones de carga nuevamente sin tu paquete de JavaScript en la página, simplemente funciona. Como, puedes usar suspense list y suspense boundaries. Muy genial. Esto es lo que más me gusta. Los spinners funcionan, en realidad, sin el paquete de JavaScript en la página y en un orden que puedes decidir. Honestamente, siento que todos los frameworks deberían robar esta idea. Y, por supuesto, ellos roban de React todo el tiempo y dicen... Oh, ya somos mejores. Publicas antes que React, lo cual es como... ¿Ves por qué no me querían en el equipo? Pero luego hay una característica adicional.

Y en realidad no lo incluí aquí porque no pensé que tendría tiempo. Así que la página puede comenzar a competir con tu paquete de JavaScript utilizando la transmisión del servidor. Al principio, cuando inicias, comienza a transmitir todos estos servidores... Todo este HTML. Pero también puedes comenzar a cargar el JavaScript. Por lo general, la primera vez que visitas la página, el paquete de JavaScript puede tardar un poco más en cargarse. Pero la segunda vez que visitas la página, está en caché. Lo que significa que el paquete de JavaScript se carga de inmediato. En este punto, React le indica a la página que ya no es una página renderizada en el servidor, ahora es una aplicación del lado del cliente. Y de inmediato se encarga para que pueda cargarse aún más rápido que la página renderizada en el servidor. Una característica increíble. Simplemente me encanta. Por lo tanto, puede aumentar tanto el lado del cliente como el lado del servidor. Estas son todas características geniales. Pero hay compensaciones. Eso es lo otro que digo. Nada de esto es realmente gratuito. Lo que debes hacer ahora es ejecutar tu propio servidor. Algunos de ustedes pueden haber estado usando algo como una aplicación de React o algo que era solo del lado del cliente. Pero si deseas obtener estos beneficios de rendimiento y un mejor modelo de programación, simplemente feliz para tus usuarios, ahora debes invertir en un servidor. Por lo tanto, tienes dos opciones principales para hacer esto. Una es Node.JS. Amo Node. Me llevó de ser un desarrollador de UX de JavaScript de juguete a ser efectivamente un desarrollador full stack. Lo amo. No tuve que cambiar mucho. Solo JavaScript básico. Saludo a cosas. Fue un día bastante genial, hace unos diez años. Pero lo que haces es que debes alquilar hardware, un VPS o una de esas cosas con un host como Heroku, DigitalOcean, no sé, no lo he hecho en años. Supongo que hay otros en el mercado. Relájate, es solo una tos seca. Estoy bien. Sí. Entonces eliges una de estas máquinas y luego debes configurarla. Debes configurar monitores de procesos, como, en el momento en que se detiene, debes reiniciarlo y supervisarlo. Está bien, supongo. Estoy emocionado por cosas como fly.io. Sé que intenta brindarte metal pesado en el borde, solucionar un montón de ciudades y puedes elegirlo y implementar tu código en él. Saludo a Ken, implementó su sitio en él y es un servicio realmente rápido y excelente. Están haciendo cosas muy interesantes. Parece que han contratado a un montón de personas interesantes. Pero aún no es trivial trivial. Como, aún tienes que lidiar con tu servidor. O haces lo que se llama informática sin servidor. ¿Verdad? Que es tu AWS Lambda o Vercel. Lo cual está bien. Pero el problema es que en realidad no admiten la transmisión. La API supuestamente sí. Pero lo que hace es almacenarlo en búfer y solo una vez que se completa, envía el contenido por el conducto.

Lo cual arruina un poco el efecto que deseas. Quieres que se cargue temprano. Esa es la primera opción. Esa es la primera opción. Puedes hacerlo hoy. Apuesto a que algunos de ustedes tienen sus cosas en Node. No es una mala elección. Además, Node no está realmente diseñado para el caso de uso de Lambda. Que es el caso de uso suicida. Toma alrededor de 200ms. La última vez que lo comprobé. Puede que esté equivocado en estos números. Toma de 100 a 200 milisegundos solo para iniciar. Puedes buscar el tiempo de inicio en frío y verás a la gente hablando de ello, supongo.

La segunda opción es esta nueva generación de informática sin servidor que está sucediendo en todo el mundo. Mi empleador tiene algo llamado workers. Fastly tiene algo llamado edge compute. Si alguien lo ha usado, avíseme. Es difícil de usar en este momento, pero he escuchado cosas geniales al respecto. El recién llegado es demo. Tienen algo llamado demo deploy. Shopify tiene algo interesante. Tienen su propio marco para implementar componentes de Shopify. Y creo que alguien hablará de ello más adelante en la conferencia. Estoy muy emocionado por eso. Un trabajo muy emocionante. Gatsby ahora se ejecuta. Gatsby solía ser un generador de sitios estáticos, pero ya no tanto, pero no lo admiten abiertamente, y ejecutan algo llamado Gatsby Cloud. Es genial, por cierto. Se llama DST. Creo que Siddhartha está aquí. Hablará de ello más tarde. Y hay más. Habrá más. Habrá muchas más personas que lo intentarán. Y hay algunos patrones habituales. Me gustaría hablar sobre CloudFlare workers. Los elegí. Págame por esto. Es bastante agradable. Entonces, CloudFlare workers. Es un tiempo de ejecución basado en estándares. Puedes hacer cosas como fetch, solicitudes y respuestas regulares, un montón de API web estándar. No hay API del DOM, pero no necesitas eso en el lado del servidor. Tienes React allí, por supuesto. Lo cual es agradable. El código es súper simple. No tienes que iniciar y decir un puerto. No.

Simplemente exportas una función llamada fetch que responde a una solicitud y devuelve una respuesta. Muy bueno. Está presente en 250 ciudades de todo el mundo. 250 ciudades, como si fuera un número pequeño y un número grande. Creo que es la red más grande en este momento. Y tienen acuerdos con alrededor de 10,000 socios o algo así. Por cierto, a los empleados no se les dice dónde se encuentra el centro de datos real en las ciudades. Así que nos gusta bromear entre nosotros que está debajo del tubo, o está en la torre de tráfico aéreo en Heathrow. Porque ahí es donde se obtiene la mejor recepción. Es eso o la torre BT. No estamos seguros. Pero es una red masiva en todo el mundo. Y los números son bastante impresionantes. Debido a que tienen una gran red, están a unos 20 milisegundos del 80% del mundo conectado. Y a unos 50 milisegundos del 95% del mundo conectado a Internet. Y para mostrarte lo rápido que es, quiero que todos intenten algo conmigo. ¿De acuerdo? Bien. Quiero que parpadees lo más rápido que puedas. ¿De acuerdo? Y veremos qué tan rápido puedes hacerlo por segundo. ¿Listo? Soy como el meme del parpadeo, ¿verdad? De todos modos. Puedo hacerlo unas 3 a 5 veces por segundo. Pero Cloudflare puede hacer entre 10 y 50 solicitudes en la misma cantidad de tiempo. Lo que significa que si realmente escribes bien tu sitio, puedes cargar todo tu sitio web en, digamos, un segundo, tal vez dos. Es realmente rápido. Es increíblemente rápido. Y lo que realmente me gusta de cosas como Workers y otros entornos de ejecución es que todos tienen un tiempo de inicio cero. No hay tiempo de inicio en frío ni nada de eso. Simplemente se inicia. Puedes iniciarlo, React se inicia, toma algunos data, lo envía por el camino. Pero no es suficiente tener un runtime que ejecute tu JavaScript. También necesitas algún tipo de persistencia. Porque tenemos JavaScript aquí, pero tu base de datos está a medio mundo de distancia, todavía no es genial. Entonces, Workers también proporciona un pequeño almacén de clave-valor, que es simplemente, para esta clave, almacena este data. Puedes obtenerlo donde quieras. También se replica en toda la red, lo que significa que el runtime y los data están, bueno, en la parte superior de BDTar. Y también tenemos esta cosa de ciencia ficción llamada objetos duraderos, que es lo más genial que he escuchado. Son literalmente objetos JavaScript que pueden moverse de centro de datos a centro de datos, dependiendo de quién lo solicite. Es increíble. Lo que significa es que, digamos que yo... Y puedes usarlo para, como, WebSockets y sincronización y cosas así. Lo que significa que, digamos que estoy hablando con un amigo en, digamos, San Francisco. No sé nada sobre geografía estadounidense. Pero digamos que Nueva York está entre Londres y San Francisco. Tal vez. Digamos. En algún lugar intermedio. Probablemente en algún lugar en el... No sé. Entonces, el objeto duradero que usamos para establecer una conexión WebSocket entre nosotros podría migrar a Nueva York para que obtengamos los mejores data para hablar entre nosotros. Y luego digamos que se une una tercera persona desde China, en cuyo caso, como, tal vez las figuras del objeto duradero son el centroide de estas tres ubicaciones. Es todo muy de ciencia ficción.

Esto es, como, estamos tratando de descubrir cuál es la historia de la database aquí. Pero es una invención muy novedosa y estamos ansiosos por ver qué construyen las personas con ella. Y hay mucho más.

Y cuando digo mucho más, me refiero a que Cloudflare tiene un amplio portafolio de servicios, y definitivamente deberías echarle un vistazo. También hay muchas cosas geniales que estamos construyendo y que aún no puedo contarte. Pero puedes comprarme una cerveza justo después de la conferencia y comenzar a hablar un poco. ¡Pero no puedo hacerlo en pantalla! ¡Oye, jefe gerente! En fin. En fin.

Así que puedes explorar más en workers.Cloudflare.com. Hay una startup, una CLI que puedes usar, y puedes comenzar a escribir JavaScript y funciona. Pronto mejorará. Pero la visión real para los workers y supongo que para todos estos otros entornos de ejecución, es que quiero dejar de llamarlo serverless. Lo que realmente me gustaría imaginar es que es como un solo servidor que envuelve al mundo como una buckyball con tu database rodeándolo todo. ¿Alguien está tomando una foto de esto? Seguro que parezco un maniático. Así que puedes envolver todo el mundo en esta malla. En este momento son 250 ciudades. Podrían ser miles en el futuro. Podríamos darte algún hardware que simplemente puedas colocar detrás de tu lavadora y luego puedas conectarte por FTP y configurar tu sitio web como en los años 90. Sería genial. Por lo tanto, las redes de borde como esta se adaptan muy bien al modelo de streaming de React. Es instantáneo. Podemos ofrecer experiencias mucho mejores que las que se han tenido en los últimos 30 años. La web está envejeciendo.

Entonces, si bien habrá una historia incremental en la que mejoraremos todas estas cosas, lo que realmente creo que va a suceder es que este es un gran momento de reinicio para React. Por supuesto, todas las bibliotecas populares seguirán funcionando con el modelo existente. El equipo mismo está colaborando con los autores de bibliotecas de CSS y JS, y los autores de bibliotecas. Funcionan bien. Pero creo que hay potencial para hacer más. Por ejemplo, Node no se ejecuta en estas redes, lo que significa que Next.js no se ejecuta en ellas. No sé. Los chicos de Next.js podrían hacer algunos cambios allí. Pero sería genial si comenzáramos a explorar. Si tuviéramos que construir algo desde cero, el streaming como modelo. Obtención de data, bibliotecas mucho más ligeras y la capacidad de comunicarse con APIs, como objetos duraderos y almacenes KB. ¿Qué podríamos hacer? Quiero dejarte con esa idea. Quiero que comiences a pensar en lo que esto significa para React en el ecosistema. Muchas de las quejas sobre React han sido, como, paquetes más grandes y sobreingeniería, y fatiga de JavaScript. Pero tal vez este sea un momento para comenzar a eliminar la fatiga, a simplificar eliminando las partes que hemos necesitado solo para poder tener una pila competente. Y tal vez podríamos tener, como, una historia diferente. No lo sé. Voy a intentarlo. Espero que todos los demás también lo hagan porque ya no suelo lanzar mis bibliotecas. Pero hay personas por ahí que me mirarán y dirán que aceptan el desafío. Y me encantaría ver eso. Hay algunos enlaces. Bueno, simplemente puedes buscar React18 working group en Google y encontrarás un montón de detalles sobre lo que estaba hablando hoy, cómo actualizar a la nueva API, guías para autores de bibliotecas sobre cómo actualizar sus autores, cómo podrías construir un nuevo JavaScript runtime si el próximo gran emprendedor serverless está en la multitud aquí en algún lugar o viendo esto en el futuro. Hay una lista completa de cosas que puedes hacer para mejorarlo. Y sí. Espero con ansias eso.

Estoy súper emocionado por esta API muy simple que no espero que muchas personas usen a mano, pero espero que redefina la experiencia de React en el futuro.

Mi nombre es Sunil. Puedes encontrarme en Twitter como Sunil3.1, lo cual es lo peor para deletrearle a alguien por teléfono cuando quieres decirles cuál es tu dirección de correo electrónico. Sí, es Sunil3.1, todas las palabras, sin números, sin puntos. Puedes contactarme allí. Estoy feliz de hablar contigo después de esto. Y espero hablar con todos ustedes en la conferencia y tomar una cerveza después de esto. Muchas gracias. Gracias. Muchas gracias, Sunil. ¿Te gustaría entrar en la guarida de preguntas y respuestas? Oh, ni siquiera necesitas traer tu propia agua aquí. Tenemos agua en la guarida de preguntas y respuestas. Es un lugar bastante especial.

¡Hola! ¿Cómo estás? ¿Cómo estás? Estoy bien. ¿Cómo estás? No está mal. Gracias por una maravillosa charla, como siempre.

Soy un usuario de K-beam. Soy un usuario de K-beam. Hago todo el trabajo. Soy un usuario de K-beam. Hago todo el trabajo.

Soy un usuario global de K-beam. Soy un usuario global de K-beam. Soy un usuario global de K-beam. Soy un usuario global de K-beam. Soy un usuario global de K-beam. Soy un usuario global de K-beam. Soy un usuario global de K-beam. Soy un usuario global de K-beam. Soy un usuario global de K-beam. Soy un usuario global de K-beam. Soy un usuario global de K-beam. Soy un usuario global de K-beam. Soy un usuario global de K-beam. Soy un usuario global de K-beam. Soy un usuario global de K-beam. Soy un usuario global de K-beam. Soy un usuario global de K-beam. Soy un usuario de K-beam. Soy un usuario global de K-beam. Soy un usuario global de K-beam. Soy un usuario global de K-beam. Soy un usuario global de K-beam. Soy un usuario global de K-beam. Soy un usuario global de K-beam. Soy un usuario global de K-beam. Soy un usuario global de K-beam. Soy un usuario global de K-beam. Soy un usuario global de K-beam. Soy un usuario global de K-beam. Soy un usuario global de K-beam. Soy un usuario global de K-beam. Soy un usuario global de K-beam. Soy un usuario global de K-beam. Soy un usuario global de K-beam. Soy un usuario global de K-beam. Soy un usuario global de K-beam. Soy un usuario global de K-beam. Soy un usuario global de K-beam. Soy un usuario global de K-beam. Soy un usuario global de K-beam. Soy un usuario global de K-beam. Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam. Ahora puedes ver que en realidad soy un usuario global de K-beam. Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.

Soy un usuario global de K-beam.