React 19: Evolution and Features

Hola, muchas gracias a todos por estar aquí. Sé que ahora mismo en el gran teatro hay algo así como el futuro de React. Todo va a estar llegando en el futuro. Y estaba realmente emocionado de tener la oportunidad de estar en una sala más pequeña con personas para hablar sobre lo que React realmente significa para nosotros hoy.

Durante los últimos, supongo, como cinco años, he estado haciendo educación para desarrolladores con varios equipos. Trabajé en Storybook y Chromatic por un tiempo, y más recientemente con WorkOS, tratando de resolver el tema de la autenticación para todos. Y antes de eso trabajé como arquitecto de front-end para una empresa durante, como, diez años. Y algo que tuve que hacer fue comunicar cómo íbamos a migrar con éxito a cualquier cosa nueva a la que necesitábamos migrar y elaborar un plan para eso.

Así que en esta sesión, verás muchos diffs, verás muchos, ya sabes, gráficos, opiniones sobre cómo se verá, como, hoy, la próxima semana, los próximos meses para ti mientras comienzas a migrar tus aplicaciones y construir con React 19. Así que si estás dentro, vamos.

Bien. Así que cometí el error no aconsejable de hacer todas estas diapositivas una página web en mi sitio web. Así que puede ser un poco problemático, pero tendrás acceso a ellas. Así que si quieres abrirlas, puedes revisarlas, hacer clic, hacer de todo. Deberías estar viendo todo lo que estoy viendo. Si no, lo siento. Debería resolverse en algún momento pronto. Tengo, como, mi marco es un poco raro. No sé si hice algo.

Bien. Así que primero, soy Chan Tastic en, como, redes sociales. Solía hacer un podcast que quizás hayas escuchado llamado React Podcast. Lo dejé hace un tiempo debido a mi crisis de mediana edad, desafortunadamente. Así que ahora solo, ya sabes, publico tonterías sobre microplásticos en mis redes sociales. Así que si quieres escuchar más de ese gran contenido, puedes ir allí. Y como dije, trabajo para una empresa llamada WorkOS. Hacemos la mejor caja de inicio de sesión del mundo, y es gratis para un millón de usuarios activos, y te llevará de todo, desde un prototipo hasta listo para empresa. Es bastante genial. Así que con eso fuera del camino, hablemos.

Quiero asegurarme de que si tienes que irte, como, en cinco minutos, que obtengas lo máximo de esta charla. Así que la gran característica de alto nivel o tipo de cosas que estamos aprendiendo sobre React 19 son, hasta donde puedo decir, como, cuatro grandes cosas. Así que primero y ante todo, si miras los documentos de migración, hay un gran énfasis en realmente fomentar TypeScript. Verás que muchas de las características de seguridad de tipos en tiempo de ejecución que han estado en React anteriormente están desapareciendo por completo. Y como la mitad del documento de migración solo habla sobre mejoras en los tipos, tipo, como, asociaciones con el TypeScript definitely typed, etcétera. También se está respaldando la filosofía de la biblioteca de pruebas, donde pruebas desde el exterior hacia adentro. Esto beneficia la accesibilidad de tus componentes. Es realmente la mejor manera de probar. Hace que tus pruebas sean más duraderas. Nos estamos alejando de las utilidades de prueba y el renderizado superficial y todo ese tipo de cosas. Vamos a cubrir eso.

También estamos adoptando compiladores. Otros frameworks como Svelte han estado haciendo esto desde el primer día. Y estamos empezando a ver mucho movimiento en eso. No vamos a cubrir eso. Sridhar dio una muy buena charla que incluye muchos más detalles sobre el compilador. Los documentos probablemente sean el mejor lugar para eso. Realmente es como una cosa de integración en este punto.

Y finalmente, hay muchas cosas donde están adoptando la plataforma un poco mejor. Como hablaremos de esas características. Pero están adoptando la plataforma de una manera que realmente me emociona como alguien que creció aprendiendo HTML y CSS. Y siempre me he sentido un poco en desacuerdo con React por cuánto lo abarca todo y te convierte en un desarrollador de React. Así que estamos volviendo un poco a la web.

Ahora, esto es un poco, hice un pequeño gráfico de cuadrantes, si quieres, de cómo veo estas características influyendo en tus aplicaciones en tu vida hoy. Así que hay cosas que son internas a React. Así que cosas que son fundamentales para la biblioteca de React. Hay cosas que vienen con un framework, ya sea Next.js o Remix o Redwood u otros frameworks que ni siquiera han sido inventados aún. Hemos eliminado APIs en React 19 y nuevas APIs. Ahora estoy pensando en esto un poco como hoy, lo que puedes hacer. Así que hay una versión React 18.3, que es 18.2, que es la versión que hemos tenido creo que como dos años ahora. Pero tiene, advierte sobre todas las APIs que van a ser eliminadas. Así que esto es algo a lo que puedes actualizar hoy, tener todo tu código seguro para React 19 cuando finalmente se lance. Y luego, ya sabes, mañana, tenemos algunas cosas que son como un poco en este borde donde las bibliotecas van a tener que actualizarse de algunas de las estrategias que han usado. Y esto puede ser tu responsabilidad actualizar o arreglar algunas de tus dependencias, de lo que hablaremos un poco.

No vamos a hablar de este cuadrante aquí arriba, RSCs y acciones del servidor, solo porque realmente no se aplican a todos los desarrolladores de React todavía. Y vamos a hablar sobre acciones, metadatos, scripts y hojas de estilo, las nuevas APIs que tenemos. Así que una hoja rápida para que mires. Estas son todas las APIs que van a desaparecer en React 19, y recibirás advertencias en 18.3. Así que prop types, muerto. Default props, muerto. Context types, get child context.

String refs, create factory, module pattern factory. Algunas de estas cosas, quiero decir, como que puede que nunca las hayas visto en tu vida. Test utils, React on render, React on hydrate, unmount component at node, find DOM node, la biblioteca de prop types está muerta, React test renderer, shallow está desapareciendo.

Ahora, algo que realmente me encanta es que el equipo de React ha estado muy dedicado a proporcionar code mods para todas estas cosas, y los he encontrado muy bien documentados. Así que puedes revisar el repositorio de code mods. Te dan instrucciones sobre cómo ejecutarlos. Es una forma bastante buena de migrar tu aplicación sin tener que tocar todo el código.

Ahora, algo emocionante sobre React es que ya no puedes ser despedido por usar internals secretos. Eso es bastante emocionante. Pero también, significa que puedes tener muchas dificultades para actualizar si tienes muchas dependencias antiguas sin mantenimiento. Así que estamos cambiando el prefijo de internals secretos, y se va a cambiar de internals secretos no usar o serás despedido a no usar o advertir a los usuarios que no pueden actualizar. Ahora, hice una pequeña búsqueda rápida en GitHub, y parece que hay, déjame abrir esto en el correcto. Sí, parece que esto realmente creció desde que obtuve este número. Ahora hay 12.3 mil archivos con referencias a internals secretos no usar. Y así que casi puedo garantizar que algo de lo que dependes hoy probablemente requerirá una actualización. Y algo que siempre me gusta decir es que eres dueño de lo que instalas. Así que este es tu problema. Podría ser un problema para ti muy pronto. Así que echa un buen vistazo a tus dependencias.

Bien, entonces la seguridad de tipos en React 19. Así que vas a ver muchos diffs en este punto. Tenemos cosas realmente emocionantes. Este es un código histórico. Este es el tipo de cosas con las que comencé. Esta fue mi primera experiencia con la seguridad de tipos, poder usar prop types, y realmente me introdujo al concepto de seguridad de tipos, y es, no sé, tiene un lugar especial en mi corazón. Sin embargo, TypeScript es mucho mejor, y ahora incluso tenemos características de lenguaje en JavaScript moderno que nos permiten proporcionar valores predeterminados para algunas de nuestras cosas. Así que todas estas APIs están desapareciendo. Eso es genial. Ups. Fui demasiado lejos.

Tenemos mejores tipos de useReducer. Así que toda esta tontería que tenías que hacer para, como, hacer que useReducer funcionara bien con TypeScript, eso se ha ido, y puedes simplemente escribir un reducer, puedes poner tus tipos allí. Súper genial. useRef ahora requiere un argumento, y eso es, no sé, bueno, supongo. Así que nos permite deshacernos de algunos tipos, así que hay un tipo de ref mutable, que te permitiría cambiar el valor con el tiempo si alguna vez fuera nulo, y ahora eso simplemente desaparece ahora que React requiere ese valor desde el principio.

No voy a pasar demasiado tiempo en todos estos, pero obtienes una limpieza de ref que ahora es necesaria para la seguridad de tipos, y el elemento React ha cambiado a unknown desde any... También hay un pequeño cambio en el espacio de nombres JSX. Ahora tienes que poner eso dentro de React para eliminar cualquier colisión con otras bibliotecas. Y sí, las pruebas ahora son oficialmente solo useTestingLibrary ya. Ahora, una cosa que sabrás, con todas esas APIs desapareciendo, todas las utilidades de prueba desapareciendo, ACT, que es un método muy importante para las pruebas, se ha movido a la biblioteca propia de React, por lo que deberías poder deshacerte de esa dependencia de testutils por completo.

Bien, entonces, ahora, una cosa que históricamente me ha encantado, vamos a cambiar un poco de marcha aquí, leí este libro hace mucho tiempo, se llamaba simplemente Refactoring, creo, probablemente debería haber averiguado el título real de eso, pero me hizo pensar sobre las formas en que pensamos sobre la migración de código, y cómo, para cada tipo de transición que tu código podría atravesar, hay estos pequeños pasos que puedes hacer para llevarlo de un lugar a otro, son predecibles, son repetibles, y pueden darte una sensación de seguridad al hacer cambios que podrías no haber tenido la intención de hacer, o cambios de biblioteca, etc.

Así que vamos a comenzar hoy, voy a mostrarte un puñado de visualizaciones para introducir algunas de las nuevas características de React, comenzando con algo que me entusiasma mucho que es useActionState, aquí es donde realmente traemos algunas de las grandes APIs de formularios del navegador, no grandes, pero APIs de formularios familiares a la biblioteca de React. Así que vamos a comenzar con lo que ves en pantalla aquí, es solo este clásico contador de clics tienes algún tipo de useState, onClick vas a incrementar, vas a llamar a esa función de actualización e incrementar. Así que useState simplemente se convierte en useActionState, vamos a tomar nuestra función de incremento y la vamos a poner dentro de nuestro useActionState. Ese es uno de los principales movimientos, es que la acción va dentro de useActionState cuando estás haciendo esta migración. Después de eso, vas a llamar a formAction, y formAction es una API que realmente se añade a input, button, y submit, ¿tal vez? Creo que hay otro. Pero todos los elementos relacionados con formularios puedes llamar a formAction. Luego simplemente cambias esto a un formulario, y todo funciona como lo hacía antes con tu contador de botones, pero ahora realmente estás usando elementos de formulario adecuados, lo cual es súper emocionante. Comenzaremos a ver por qué eso es genial en solo un segundo.

Así que por definición, en React 19, una acción es algún tipo de funcionalidad asincrónica. Así que mientras estamos usando useActionState aquí, porque este no es un manejador asincrónico, técnicamente no es una acción. Así que podemos hacer esto asincrónico, sigue siendo lo mismo, pero ahora lo hemos desacoplado de ser inmediato. Y ahora podemos hacer cosas como esperar algún tipo de acción. Así que ahora mismo, solo estoy simulando con tiempo que alguna solicitud de red va a suceder. Algo va a suceder que no sabemos cuánto tiempo va a tomar. Y porque es asincrónico, esto va a ser manejado por nosotros. Ahora voy a abrir un playground para esto, para que podamos ver eso. Puedes ver cómo funciona esto. Así que pasamos de ese tipo de ejemplo clásico de botón con el que estamos familiarizados, y a través de acciones, hemos podido hacer esto asincrónico. Y si hago clic en esto, verás un pequeño retraso. Y luego ese número aumenta. Ahora odiamos los retrasos, sin embargo. Los retrasos apestan. Así que también tenemos métodos para manejar eso. Así que useOptimistic es una forma en la que podemos mantener la inmediatez de lo que teníamos con el estado, pero luego también en segundo plano, ejecutar este proceso asincrónico. Ahora con el código que teníamos arriba, veamos. Así que tenemos nuestra acción aquí. Vamos a introducir un nuevo hook. Este es React useOptimistic. Vamos a tomar el conteo que obtenemos de nuestro useActionState.

Y vamos a implementar un conteo optimista. Así que este es un valor que se actualizará de manera optimista independientemente de cuánto tiempo tome la solicitud. Lo siento, déjame alejar esto un poco. Bien, genial. Luego, al igual que useState, vamos a tener una función actualizadora que vamos a definir en línea. Tenemos acceso tanto al estado como al conteo optimista que se nos envía a través de esta acción, que es, veamos, cuando lo estamos llamando, ¿verdad? Oh, aún no lo he llamado. Y luego todo lo que tenemos que hacer es llamar dentro de nuestra función asincrónica, este update optimistic con nuestro valor nextCount, y cambiar nuestra función de renderizado para usar el conteo optimista. Ahora, lo genial de esto es que con solo estas tres líneas de código, hemos podido rastrear estos datos, o React automáticamente rastrea estos datos por nosotros.

Así que vamos a abrir nuestro playground para este. Y puedes ver cómo ha mejorado nuestra experiencia. Así que vamos a hacer clic en esto, y el número se actualiza automáticamente. Así que el número sube, pero luego tenemos este spinner mientras ese proceso asincrónico continúa. Esta es una experiencia increíble para los usuarios, poder, por ejemplo, pensar en un cliente de chat donde las personas pueden publicar cosas y tener esa sensación de tiempo real, aunque en realidad está yendo a una red, puede tomar un poco de tiempo, puede haber retrasos.

Así que una API realmente genial aquí alrededor de las acciones de formulario. Nos quedan 57 segundos. Veamos cuánto más podemos avanzar. Ahora no necesariamente pasaré por todos estos entonces. Las acciones no están limitadas a los botones. En realidad, prefiero manejarlas en el formulario. Y lo genial de cuando haces esto en el formulario, tienes acceso al tipo de datos de formulario estilo navegador. Así que si ponemos un campo oculto en esto, en realidad podemos tomar los datos del formulario como el segundo argumento para nuestras acciones, y hacer lo que queramos con ellos. Así que una API súper genial que realmente trae los formularios web de vuelta al juego.

Y en realidad, creo que 15 segundos, podemos hacer el último. Así que hay una nueva API llamada use. Es súper impresionante, e interactúa muy bien con el contexto. Así que el contexto, ahora puedes eliminar estos proveedores. Así que eso es bastante genial. Puedes simplemente cortarlos del camino. Ahora podemos usar use para renderizar condicionalmente cosas que de otro modo habrían usado hooks. Así que como use context y demás. Esto es súper genial porque use no es un hook. Nos permite evitar algunas de esas reglas estrictas requeridas de los hooks que hemos llegado a odiar. Así que de todos modos, creo que eso es todo. Creo que acabamos de llegar al tiempo. Espero que algunos de estos te ayuden. Nuevamente, todos estos ejemplos están en mi sitio web. Y estoy realmente emocionado por lo que el corto plazo de React nos permite hacer. Integrando la grandeza de los formularios web y HTML con React.

Así que eso es todo. Muchas gracias por tu tiempo, y contáctame si tienes alguna pregunta.

Entonces, en primer lugar, ¿hay un beneficio en definir tus funciones de acción fuera de tus componentes? Sí. Quiero decir, creo que siempre hay un beneficio en dividir las cosas solo porque puedes reutilizarlas. Yo tiendo a no sacarlas a menos que vaya a reutilizarlas. Pero eso es solo yo. La primera aplicación de React que construí, fue antes de las bibliotecas de estado. Era este componente masivo, no sé, de 15,000 líneas con un montón de... Ni siquiera era useState entonces. Era como setState, creo. Y fue genial. Me encantó.

Creo que siempre corres el riesgo de sacar el código. Terminas, ¿cómo lo digo? Cuando extraes el código demasiado pronto, tiendes a tomar peores decisiones porque estarás mirando ese código y dirás, oh, hey, esto necesita una condición aquí que me permitiría llamarlo de una manera diferente desde otro lugar. Versus si está en línea, lo cambias allí. Es como por qué a todos les encanta Tailwind ahora mismo. No tienes que pensar en toda la aplicación en tu cerebro para decir que esta cosa aquí necesita menos padding. Así que creo que hay un beneficio. Pero solo sería en esos casos donde sabes que esa acción exacta se comparte a través de un par de cosas. Así que hay un riesgo de sacar las cosas prematuramente.

Oh, sí. Sí. Algunos de los peores códigos que he visto fueron porque alguien dijo voy a sacar esto porque parece que debería estar aislado o repetido. Quieres simplemente echar un vistazo a todo lo que tienes en su conjunto y luego tomar decisiones desde allí. Sí. Sí. Es como si estuvieras quitando ese contexto muchas veces, ¿verdad?

Porque estás sacándolo y tal vez poniéndolo en un archivo diferente.

Y ahora alguien tiene que abrir, ya sabes, como 50 pestañas solo para entender qué hace este maldito formulario.

Oh, tenemos más preguntas llegando. ¿Qué pasa si useOptimist falla? ¿Revierte el estado? Sí, lo hace. No cubrimos eso. Pero si hay un pequeño botón de documentación en algunos de los ejemplos, definitivamente miraría los documentos porque tienen muy buenos ejemplos de cómo manejar casos de falla. Probablemente te familiarizarás mucho más con los límites de error y cómo utilizarlos. Estos son ejemplos muy simplistas para mostrarte cómo cargar la función en tu cerebro. Pero sí, hay formas incluidas, como baterías incluidas, para retroceder el estado allí. Oh, eso suena muy útil. Sí. Genial.

Bien. ¿Puedes ayudarme a entender qué hace que use sea mejor que lo que ya es posible con use context? Parece que podría invitar a algunos anti-patrones. Sí. Así que eso es algo que todavía estoy tratando de entender por mí mismo. Sin embargo, muchas veces, ya sabes, context no es como, utilizar context no es como una operación gratuita. Y a veces puedes saber que ese componente no necesita ser renderizado, ya sabes, por virtud de algún otro estado. Y al renderizar el componente, y luego poner la condición dentro del render, has incurrido en el costo de renderizar ese componente y hacer esa búsqueda de context. Sí. Y aquí, puedes simplemente optar por no hacerlo completamente, como, oye, este computador, este, este componente, sabemos que este componente no se muestra, como, no busques el context en absoluto, como no hagas esa conexión. Y así creo que allí, como, no sé, tal vez haya riesgos, pero es una oportunidad de optimización para subvertir algunas de esas, ya sabes, reglas de hooks, lo cual es agradable.

Sí. ¿Qué piensas sobre el nombre use? Quiero decir, lo vi, como, use qué? Oh, solo use? Todo es, sí, todo es use en React. Ahora, especialmente si eres un desarrollador de Next, es como, use cache, use server, use como, lo que sea. Quiero decir, es legible, supongo. Sí.

Es divertido. Bien. Siguiente pregunta. ¿Por qué crees que fue necesario crear use action state?

¿Qué problema resuelve el hook que otros hooks o funcionalidades no pudieron? Sí. Así que este es, este es un área donde he estado en desacuerdo. Como alguien que creció en HTML, CSS, como mejora progresiva, como todo eso, soy como muy viejo. Así que, me enamoré de muchas de las APIs de la web, ya sabes, como la primera cosa que construí fue un formulario en PHP y me encanta ese flujo de formularios y usar formularios, datos de formularios, usar formularios de manera holística como un solo objeto con el que estás trabajando. Y creo que los formularios han sido realmente problemáticos en React porque siempre han recomendado usar componentes controlados. Sí. Y odio los componentes controlados en los formularios. Como que simplemente apestan.

Y siempre he sido alguien que dice, oye, solo envía un formulario, toma los datos del formulario. ¿Verdad? Y eso nunca ha sido la forma de React. Es como, puedes hacer eso si eres un idiota y realmente amas la plataforma web por alguna razón, pero como, esa no es la forma en que hacemos las cosas en React. Usamos cosas, estado controlado, etcétera. Lo genial de use, uh, use action state es que esas cosas pueden coexistir ahora. Y tienes los beneficios de, ya sabes, React, conociendo este formulario y teniéndolo integrado en el marco.

Y luego también puedes usar formularios de la manera en que estaban destinados a ser usados en la web. Así que es como si se hubiera reintegrado en React y, um, ya sabes, la intención de React para el control y, um, finalmente se ha encontrado con, con, con la web. Y por eso estoy tan emocionado con la API porque ahora no tenemos que hacer algo que no sea la forma de React nunca más. Puedo simplemente, ya sabes, está incorporado. Es genial.

He estado, sí. He estado criticando el estándar durante mucho tiempo. Simplemente, uh, sí. Y por eso estoy emocionado al respecto. Genial.

Bien. Entonces, ¿cómo resumes las cosas que se deben hacer cuando alguien actualiza a React 19, uh, cosas como, ¿cuáles son algunas de las cosas que esperas que se rompan? Sí, entonces las cosas que se deben hacer van a ser, um, uh, bla, bla, bla, bla, bla. Así que toda la lista de todas las, um, tipo de eliminaciones de API, um, eso va a ser como un problema del día uno. Um, y tienes esa especie de versión suave de, uh, React 19, tres, uno, creo que es la última versión allí. Eso te dará esas advertencias. Um, y hay modificaciones de código para todas esas cosas. Así que debería ser como una migración bastante fácil. Um, creo que muchas de esas cosas son APIs muy antiguas que, um, la gente puede que nunca haya usado. Um, y así creo que, um, el día uno va a ser simplemente como, ya sabes, eliminar todos esos errores, ejecutar las modificaciones de código, etcétera.

Sí. Creo que el problema más difícil va a ser esa pieza comunitaria de la, estas bibliotecas. Hay muchas bibliotecas de las que mucha gente ha llegado a depender. Creo que muchos de nosotros vamos a tener que ensuciarnos las manos en algunas de esas bibliotecas, tal vez bifurcarlas, como, ya sabes, realmente poseer ese código por primera vez. Um, o, ya sabes, tal vez darse cuenta de que no son necesarias. Es algo que no tuvimos tiempo de cubrir fue, um, uh, ya sabes, hay, hay nuevas APIs o nueva funcionalidad que te permite simplemente poner scripts, ya sabes, metadatos y hojas de estilo, como directamente en el componente. Y hará toda la deduplicación por ti, manejará el, ya sabes, precarga y, y demás. Hace todo eso por ti, lo que en realidad elimina la necesidad de un puñado de bibliotecas que históricamente pueden haber tenido una razón legítima para usar algunas de las, ya sabes, las APIs privadas. Así que, um, puede que descubras que ya no necesitas ciertas bibliotecas.

Oh, bien. ¿Sería agradable? Sí. Bien. Así que siento que este es un punto de inflexión para que la gente reflexione sobre si las cosas son necesarias o no. Sí. Sí, absolutamente.

Sí. Definitivamente miraría tus dependencias de manera crítica, um, y no solo asumiría que tienes que seguir arrastrando una biblioteca que no se está manteniendo, uh, contigo. Genial.

Bien. Uh, algunas personas no están convencidas de que RSC debería ser parte de Core React. Viendo que han 'jumped the shark' y se han convertido en más que una biblioteca de UI. ¿Opiniones? Siempre soy fan de cualquiera que use 'jump the shark'. ¿Alguien sabe de dónde viene esa referencia? No tengo idea. ¿No? Pensé, sí. Bien. Hay un, hay un episodio de Happy Days. Oh, bien. Donde el Fonz está en una moto de agua o como que está esquiando y literalmente salta sobre un tiburón en el agua. Es tan estúpido. Y es, es como ampliamente considerado como el momento en que este programa comenzó a apestar. Y así, así que 'jumping the shark' es cuando, ya sabes, haces, haces una acrobacia estúpida y como que comienzas a apestar. Uh, podría ser. Cosas que aprendí. Sí. Sí.

Um, uh, podría ser, creo, como, um, no sé, intencionalmente no incluí mucho sobre, uh, RSEs y server actions solo porque, um, realmente no están aquí todavía. ¿Sabes? Y así creo que lo que vemos hoy es como una, como una luz tenue de lo que realmente serán, ya sabes, um, creo que olvidamos que, como anunciaron este concepto de cómo hacer esto, como hace siete años. Uh, es como, es muy como, ha estado en proceso durante mucho tiempo y aún no está aquí. Lo que significa que es como, todavía está evolucionando, ya sabes, um, Next obviamente tiene como una solución que está como impulsando el lenguaje y como el, ya sabes, los, los pensamientos de ello y cómo creen que debería verse. Pero como, Remix tiene una implementación muy diferente de ello. Teóricamente, esto debería, esto debería funcionar en cualquier framework, ya sabes, podrías, ya sabes, tener como PHP, um, hacer como server components para ti o server actions, pero es muy, es muy integrado. Como que requiere, como que está integrado en el framework, integrado en el empaquetador. Um, y creo que, ya sabes, probablemente me alineo con ese sentimiento de, me gusta, uh, me gustan las cosas que están más cerca de la web, ya sabes, como, quiero decir, como hablamos sobre con los formularios o lo que sea. Y así, estoy emocionado por esas cosas. No me gusta, realmente me gustan, um, ya sabes, aplicaciones solo del lado del cliente.

Y así no está, no está haciendo mucho por mí. Um, creo que son muy geniales y creo que hay, uh, aplicaciones que tienen mucho sentido. Pero como, quiero decir, cuando miras las cosas que se están construyendo, um, como Next está realmente invirtiendo mucho en, es mucho de cosas de comercio electrónico y como, no estoy construyendo sitios de comercio electrónico. Como la mayoría de las cosas que estoy construyendo, como la gente solo quiere como una, como una UI agradablemente optimista, ya sabes, actualizada, uh, como una aplicación de una sola página.

Y así creo que si tienes ese problema, um, es genial que haya como una solución para ti y sabes, vas a estar en la vanguardia y va a, ya sabes, doler y vas a tener muchos cortes y moretones en el camino. Pero, um, no sé. Simplemente no es lo que estoy construyendo ahora mismo. Sí. Así que lo aprecias, pero no es para tu caso de uso.

Sí. Como, me gustaría, me gustaría verlo, um, ya sabes, desarrollado un poco más antes de introducir algo en mi aplicación que voy a tener que como seguir persiguiendo durante los próximos como, ya sabes, cinco años mientras es como, oh, en realidad nos gusta más esta API. Como, ya sabes, lo teníamos todo mal antes. Es como, simplemente no estoy interesado en ello. Sí. Sí. Puedes simplemente esperar. Estar al margen por un tiempo.

Sí, solo espera. Puedes esperar. Es como, ni siquiera está aquí todavía. Y la gente está como, oh hombre, es como, ya sabes, es tan increíble y lo que sea. Y es como la mayoría de la gente no puede usarlo. Así que eso es decir, sé, sé paciente. Sí. Ni siquiera sabemos si hemos saltado el tiburón todavía, supongo que esa es tal vez la respuesta. Sí. Sí. Bien. Así que esas son todas las preguntas para las que tenemos tiempo. Muchas gracias por tomarse el tiempo para hablar sobre ReaNyteam. Aprendí mucho. Quiero decir, aprendí la frase saltar el tiburón hoy. Si necesitábamos algo, eso era. Sí. Vengan a hablar con Michael después si tienen alguna pregunta.