Tanstack Start - Un Framework de React de Full-Stack Primero del Lado del Cliente

Encuestamos a miles de desarrolladores, y se demostró que cuanto más ruidosa es una audiencia, mejor es la presentación. Así que me gustaría escuchar cuán ruidosos van a ser durante mi presentación. Gracias, y eso me ayuda a mantenerme motivado.

Muy bien, aquí vamos. En los últimos años, ha habido un cambio notable en el desarrollo de aplicaciones web. Hemos pasado de una larga temporada de prosperidad para las aplicaciones renderizadas del lado del cliente a este enfoque hiperconcentrado en arquitecturas server-first. Esto sin duda ha mejorado drásticamente nuestras capacidades full-stack como desarrolladores web, pero ha tenido un costo para el ecosistema. Porque, por un lado, hay herramientas maravillosas que están empujando los límites, pero están aumentando significativamente la complejidad. Hay una mayor carga cognitiva, y ha habido una especie de divergencia del enfoque tradicional centrado en el cliente que hemos llegado a amar y usar.

Por otro lado, hay herramientas que están tratando de abrazar este nuevo mundo, enfocándose en estándares y primitivas, pero en mi opinión, aún están quedándose cortas en poder y control y seguridad y experiencia general del desarrollador. Pero lo peor de todo, me temo esta nueva obsesión que tenemos con el servidor, porque parece que estamos dejando al cliente en decadencia. Eso me da mucho miedo. Porque el cliente es muy importante. Es crítico, y es poderoso. Es una de mis partes favoritas de construir aplicaciones web. Es donde comencé. Con este gran cambio, he sentido en los últimos años que estoy perdiendo algo especial para mí, y crítico para lo que consideraría crítico para entregar lo que mis usuarios necesitan.

Así que decidí tomar un gran riesgo y construir mi propio meta-framework llamado Tanstec Start. Es un nuevo meta-framework para React, y se basa en más de diez años de experiencia que he tenido construyendo SaaS intensivo en datos, renderizado del lado del cliente, y también construyendo herramientas de código abierto que hicieron eso posible en el camino. Así que Tansec Start podría sonar familiar. Está basado en el mismo conjunto de herramientas del framework que impulsa a nuestro framework primo, Solid Start. Pero sus objetivos son muy similares, y su misión es simple. Queremos ofrecer la mejor experiencia de autoría del lado del cliente posible, y luego agregar primitivas del lado del servidor potentes y flexibles que no sacrifiquen el rendimiento o la experiencia del desarrollador. Así que diría que está enfocado sin disculpas en proporcionar el mejor enrutamiento, almacenamiento en caché, y seguridad de tipos que puedo imaginar. Tres características muy importantes que históricamente han sido despriorizadas o subinvertidas en nuestra industria, pero son cruciales si quieres ofrecer la mejor experiencia de desarrollador y usuario. Para lograr esto, comencé Start construyendo sobre Tansec Router. El enrutamiento es el corazón de cualquier framework, y también donde debería ocurrir la mayor parte de la gestión del estado del cliente. Tansec Router es perfectamente adecuado para esta tarea. Así que es 100% seguro en tipos, lleva todo a un nuevo nivel, seguridad de tipos inigualable. También tiene gestión de estado de URL incorporada, lo cual explicaré en un momento.

Y tiene primitivas de obtención y almacenamiento en caché de datos profundamente integradas, no solo el router en sí, sino con algunas otras cosas que también abordaremos. Pero comencemos con la seguridad de tipos. Así que todo es completamente seguro en tipos. Y cuando digo seguro en tipos, no me refiero a que fue escrito con TypeScript. Quiero decir que está completamente inferido. Puedes escribir una aplicación Tansec Router completamente segura en tipos y nunca ver ningún TypeScript en tu código. No hay más dudas si tu enrutamiento se romperá cuando llegue a producción. No más dispararse en el pie con enlaces incorrectos o parámetros de búsqueda faltantes. Y esto se aplica a toda la API de navegación, esencialmente.

Más allá de estos conceptos básicos, hemos ido más allá para admitir cosas como navegación relativa estricta parámetros de búsqueda anidados, middleware de ruta seguro en tipos, y hay muchas otras características de enrutamiento de próxima generación que simplemente no encontrarás en otras soluciones existentes. Y nos hemos asegurado de que esta experiencia con el proveedor de servicios de lenguaje TypeScript, esa es una gran palabra, pueda escalar con los tipos más complejos. Miles de rutas usando esquemas Zod muy complejos e inferencia, podemos escalar eso a básicamente tanto como queramos sin comprometer en absoluto el rendimiento del IDE. Es un gran logro. Y necesito quitarme el sombrero ante algunos de mis mantenedores por ahí. Sabes quién eres. Chris Arobin, también. Se merece un aplauso. ¿Puedo recibir un aplauso para Chris? Es la persona más inteligente en TypeScript que conozco. Y él es lo que ha hecho posible mucho de esto. Así que, ya sea que estés construyendo diez rutas en tu aplicación o 10,000, no notarás una diferencia.

También tiene gestión del estado de URL. Lo tomamos muy en serio. Porque no solo deberías estar almacenando más de nuestro estado del cliente en la URL para que pueda ser compartible, marcable, también, por cierto, está integrado deshacer y rehacer justo en el navegador, solo para que lo sepas. Es muy genial. Pero merecemos mejores herramientas para gestionar este estado en la URL. Para hacer esto posible, el router se envía con validación de parámetros de búsqueda profundamente integrada. Esto permite que las rutas anidadas apilen esquemas de validación solo para los parámetros de búsqueda que necesitan. Y luego puedes obtener esta fiabilidad a prueba de balas que esa caja de entrada mágica en la parte superior del navegador está produciendo un estado utilizable en tu aplicación. Y sí, es JSON. Puedes almacenar JSON en la URL.

No sugiero hacerlo sin pensarlo primero. Pero puedes hacerlo. Y es increíble. Lo que también significa que necesitamos APIs de navegación más potentes que puedan manejarlo.

Así que construimos la gestión de estado directamente en la API de navegación. Este es un componente de enlace seguro en tipos que puede actualizar los parámetros de búsqueda. Aquí hay otro usando una función reductora que mantiene los parámetros de búsqueda existentes mientras actualiza algunos de los otros. También hay versiones imperativas, obviamente.

Lo que creo que es realmente asombroso, sin embargo, es que puedes actualizar todo sobre la URL con soporte JSON completamente validado y seguro en tipos en una sola transacción. Y esto mantiene tu pila de historial realmente agradable y limpia. Pero honestamente, almacenar el estado de la aplicación en la URL es mucho más difícil de lo que parece. Hay tantos casos extremos. No los ves venir. Pero no necesitas preocuparte por muchas de estas cosas porque hemos logrado resolver todo para ti.

Cosas como estabilidad referencial, actualizaciones inmutables entre renders y serialización y análisis, y toneladas de optimizaciones de rendimiento que llegan hasta los adaptadores de bajo nivel que realmente escriben en la URL. Y luego está el santo grial de las suscripciones de estado de grano fino, donde los componentes y hooks solo se volverán a renderizar cuando la parte del estado de la URL de la que dependen cambie. Solo las piezas que usas. Es increíble. Y empodera aplicaciones de muy alto rendimiento. Puedes almacenar estado en la URL que puedes actualizar tan rápido como quieras. Es increíble.

Así que eso es todo solo TanStack Router. Y en el cliente. Podría detenerme aquí, y sería un gran framework solo del lado del cliente. Y lo es. Ya hay muchos desarrolladores usando TanStack Router solo por sí mismo para aplicaciones renderizadas del lado del cliente. Pero la verdadera diversión comienza cuando traemos el servidor. Así que para ir a full stack, TanStack Start necesitaba soportar renderizado del lado del servidor extremadamente simple, lo cual no es una hazaña fácil. Pero esto esencialmente significa que necesitábamos poder elevar datos críticos para el renderizado fuera de React y dentro del router. Nos inspiramos en Remix.

Aplaudamos a Remix. Construimos una API de cargador de alto rendimiento, muy similar, directamente en el router, lo que permite asegurarte de que los datos estén listos, o al menos preparándose, antes de que cualquier código de React se ejecute. En TanStack Router, sin embargo, los cargadores son isomórficos. Se ejecutan tanto en el servidor durante SSR como en el cliente antes de cada navegación. Pueden preparar cachés, obtener activos e incluso devolver sus propios datos, que luego se serializan al cliente durante SSR y se rehidratan con tu aplicación.

Este patrón de cargador es fantástico, y he disfrutado usándolo a lo largo de los años a través de Remix. Pero por sí solo, creo que viene con algunos inconvenientes importantes. Uno de ellos es el más obvio. Supongamos que dejas esta página y vuelves más tarde. ¿Realmente vas a hacer que tus usuarios esperen por ese cargador de nuevo? Espero que no lo hagas. Así que para resolver este problema, nuestro router necesita comenzar a entender más sobre nuestros datos, y principalmente cómo almacenarlos en caché. En este punto, espero que estés pensando lo mismo que yo. Bueno, eso suena como un trabajo perfecto para TanStack Query. ¡Woo! No. Sería genial, y lo será. Solo espera, sin embargo. Porque normalmente, tendrías razón. Sin embargo, se sentía mal obligarte a usar TanStack Query si querías usar Start, aunque sea genial. Tampoco se sentía bien dejar a TanStack Router en el polvo en cuanto a almacenamiento en caché. Si algo más simple puede hacer el truco, ¿por qué no? Así que hice algo realmente genial. Construí una versión en miniatura de TanStack Query directamente en el router. Eso es muy genial. En realidad, es el 5% del tamaño, y es el 5% del tamaño de React Query. Tiene almacenamiento en caché incorporado que se basa en una combinación del nombre de la ruta y los parámetros de búsqueda seleccionados, al igual que una clave de consulta. Y con esta pequeña adición, el router ahora por sí solo admite patrones de stale while we validate, precarga persistente, validación granular, lo que significa que para tus usuarios, nuevamente, tendrás navegación instantánea, muy pocos spinners, si es que hay alguno, y potencialmente incluso menos ancho de banda, dependiendo de cómo lo configures.

Entonces, ¿dónde deja eso a TanStack Query? ¿Qué pasa si quieres usarlo? Bueno, hicimos más cosas geniales. Si agregas TanStack Query, obtendrás cosas como el polling, las consultas infinitas, soporte offline, actualizaciones optimistas, simplemente usando TanStack Query. Es genial. Pero lo que realmente me emociona es cómo el UseSuspenseQuery se integra mágicamente con el router. Te ofrece obtención de datos isomórfica con un solo hook.

¿Qué significa eso? Entonces, durante SSR, UseSuspenseQuery puede solicitar datos. Y si no están listos, se suspenderá para que React pueda renderizar el resto de nuestra aplicación, enviar al cliente. Y cuando la consulta resuelva esos datos en el servidor, transmitirá esos datos y el HTML restante al cliente. Bastante simple. Puedes hacer todo eso con solo este hook sin complicaciones.

Así que eso es genial. Y puedes hacer eso en otros frameworks. Pero una vez que llega al cliente, retoma justo donde lo dejó. Y ahora ya tienes el mejor motor de sincronización de datos del lado del cliente con un solo primitivo. Es muy flexible y poderoso.

¿Y qué pasa con los datos críticos? Necesitas tus datos, y no quieres esperar a que se transmitan. Simplemente los necesitas allí ahora mismo. ¿Cómo los obtenemos en la respuesta inicial? Bueno, podemos esperar los datos de la consulta en nuestro loader. Y podemos usarlos en un UseQuery, y los datos se enviarán automáticamente al cliente. No tienes que deserializar y serializar o transferir nada por ti. Simplemente sucede automáticamente. O puedes hacer lo mismo sin ReactQuery usando solo el router, lo cual es bastante genial.

Simplemente esperas los datos, los usas directamente en tu componente. Si has usado Remix, esto probablemente te resulte bastante familiar. Si necesitas renderizar lo antes posible y transmitir datos más tarde, también puedes hacerlo. Así que simplemente puedes eliminar el await del loader, y los datos se transmitirán cuando estén listos. Y nuevamente, puedes hacer esto sin ReactQuery, solo usando el router. Quita el await, usa nuestro pequeño componente await, o en React 19, usa el hook use, y funcionará exactamente igual.

Oh, pero Tanner, ¿qué pasa si no quiero elevar mis datos al loader? Sí, algunos de nosotros todavía no queremos hacer eso. Está bien. Así que para obtener una transmisión completamente dinámica, simplemente puedes usar SuspenseQuery. No necesitas elevar nada. Eso es todo lo que necesitas. Y los datos se obtendrán lo antes posible en el servidor. Se transmitirán automáticamente al cliente cuando estén listos, y no tienes que configurar nada.

Y nada ha cambiado si deseas usar la obtención de datos solo del cliente. Simplemente usa query como lo has estado haciendo. Así que espero que ahora estés pensando, start se ve bastante bien. ¿Se ve bastante bien? Muy bien.

Lo loco es que solo hemos hablado de router y query. Ni siquiera he comenzado a hablar de start. Lo cual realmente habla del poder de estos primitivos. No te preocupes. La Navidad llega temprano. Finalmente hablemos de Tansec Start.

Así que ahora que hemos aprendido que start es básicamente 90% Tansec router y algo de Tansec query opcional, lo único que queda es hablar del servidor. Sé que has extrañado hablar de ello. Está aquí. No necesitas tener ningún síndrome de abstinencia, ¿de acuerdo?

Así que las características del lado del servidor de Tansec Start están construidas sobre Benchy, un kit de herramientas de framework de pila completa basado en Nitro, un kit de herramientas de servidor universalmente desplegable basado en Vite, el inevitable y asombroso empaquetador y servidor de desarrollo. Estas herramientas son increíbles por derecho propio. Pero juntas, otorgan a Tansec Start algunos superpoderes realmente geniales.

El primero es, oh, olvidé eso. El primero es la renderización del lado del servidor. Todo lo que se necesita es un pequeño archivo de entrada SSR para enrutar la solicitud al router y luego una pequeña entrada del cliente para manejar la hidratación. Con esos dos cambios, ya estás preparado para la transmisión, empaquetado y despliegue a cualquier proveedor, todo gracias a Benchy, Nitro y Vite. Eso es bastante dulce.

Así que ahora que tenemos un servidor, finalmente podemos hacer las cosas divertidas. Podemos adentrarnos en patrones realmente geniales y divertidos del lado del servidor como las rutas API. Todo el mundo dice, quiero rutas API. Por favor, dámelas. Las tenemos. Vienen con ellas de serie. Incluso puedes usar una útil utilidad de rutas API basada en archivos o puedes traer la tuya propia. Puedes usar herramientas como tRPC, Hano, Express, lo que sea. Cualquier cosa que desees usar para manejar solicitudes, puedes usar.

Eso es realmente genial. Nuevamente, si nos detuviéramos aquí, sería bastante genial, pero no pudimos evitarlo, así que añadí funciones del servidor. Y sé que algunos del equipo central de React están aquí. Así que simplemente las llamaremos funciones RPC del servidor. Gracias, React, por robar ese término. Pero createServerFunction es el primitivo que hemos añadido para comenzar a construir funcionalidad del lado del servidor. Ahora, usando este primitivo, podemos escribir código del lado del servidor en cualquier parte que queramos en nuestra aplicación y obtener una función del servidor. Podemos llamar a esta función desde cualquier parte que queramos en toda nuestra base de código. No tiene nada que ver con el router, nada que ver con query, nada de eso. Simplemente, puedes llamarla en cualquier parte. Y es solo una función asíncrona. Incluso puedes definir la validación de entradas que funciona tanto en el servidor como, opcionalmente, en el cliente, y convenientemente hace que toda la API sea completamente segura en tipos.

Entonces, ¿qué serían las funciones del servidor y la funcionalidad del servidor sin middleware? Puedes usar la función createMiddleware para crear middleware componible para tus funciones del servidor. Puedes usarlos para autenticar usuarios o realizar registros o incluso solo compartir código común entre múltiples funciones del servidor, o incluso entre otros middlewares también. Así que una de las mejores partes de este middleware es su realmente poderoso sistema de contexto. Así que al igual que el router, puedes extender cualquier contexto de middleware con datos adicionales. Y es completamente seguro en tipos e inferido para cualquier otro middleware o función del servidor que lo consuma. Y además de eso, también decidimos incluir la serialización de contexto que puede ir del cliente al servidor y del servidor de vuelta al cliente, todo aún completamente inferido. Y esto va a desbloquear algunas cosas realmente geniales. La API de funciones del servidor y la API de middleware por sí solas, ya estamos cocinando algunas integraciones realmente profundas y cosas realmente geniales que podemos hacer con estas. Y no están listas para mostrártelas aún. Pero con suerte las tendremos listas para la versión 1.0.

Hasta entonces, tendrás que disfrutar de algunas de las otras cosas geniales que obtenemos con Start de forma gratuita, como el control total sobre las solicitudes y respuestas web. Cualquier cosa que puedas hacer con H3 y Nitro y Vinci, puedes hacerla en 10-Stack Start. También tendrás la capacidad de hacer streaming. Creo que vimos a Jack Harrington mostrar algo de streaming anteriormente con 10-Stack Start. Obtenemos WebSockets y otras primitivas en tiempo real. Pre-renderizado estático. Podemos hacer algunas cosas realmente divertidas, porque todo es Nitro y Vite y Vinci bajo el capó. Así que cualquier cosa que puedas hacer con esos, puedes hacerla con esto.

Realmente estamos comenzando. Broma de papá. Una última cosa que sé que todos se están preguntando. ¿10-Stack Start soportará RSCs? No está listo para el horario estelar todavía. No voy a darte una demostración que simplemente no le haría justicia. Pero hablaré sobre ello. Descubrimos que va a ser tan fácil como devolver elementos de React o JSX desde una función del servidor. Eso es todo. Ya te dimos la API para funciones del servidor. Todo lo que tienes que hacer es devolver cosas de React y nosotros nos encargaremos del resto por ti. ¿Es genial? Creo que es bastante genial. Lo que significa que podrás usarlos en tus loaders. Puedes usarlos durante SSR. Podrás usarlos en useQuery. O prácticamente en cualquier lugar. Podrías llamar a una función del servidor desde cualquier lugar que desees. Porque los RSCs son realmente solo flujos de texto. Y estos flujos de texto representan el estado del servidor. Y si alguna vez me has escuchado hablar sobre el estado del servidor, sabes exactamente a dónde voy con esto. No tengo tiempo para entrar en esto ahora mismo. Pero los RSCs llegarán pronto. Puedes esperar algunas características nuevas y geniales que creo que los harán aún más flexibles y manejables de lo que has visto hasta ahora.

Una más, una última cosa. Los últimos seis meses han sido una locura. Me dediqué a tiempo completo a 10stack hace seis meses hasta la fecha. Lo cual es realmente humilde y asombroso que haya podido hacer eso. Y ha estado en alfa desde entonces. Pero creo que finalmente es hora de anunciarlo. A partir de, como, justo antes de subir al escenario. Ahora está en beta. Así que... Gracias. Por favor, pruébalo. Tendrá algunos bordes ásperos. Pero necesitamos tu ayuda para pulirlos y llegar a la versión 1.0. Estoy realmente emocionado por el futuro. Quería agradecer a muchas personas. Pero Vercel, Clerc, AGgrid, están aquí. Convex, CenturyUI.dev, Nozzle. Estas son empresas que se preocupan profundamente por el código abierto y el futuro de la web. Y ha sido increíble trabajar con ellos para ser parte de ese futuro. Así que quiero agradecerles a ellos y a estos pequeños patrocinadores de GitHub, y a todos ustedes, por ser una gran audiencia. Gracias.

Oh, este es interesante. Oh, mierda. ¿Son deterministas las rutas de funciones del servidor? ¿Cómo manejas la desviación de la API y la observabilidad en ellas? Eso no es una pregunta.

Bien. ¿Cuál fue la primera? ¿Son deterministas las rutas de funciones del servidor? No. Pero tenemos algunas discusiones iniciales ahora mismo sobre la capacidad de simplemente proporcionar una ruta estática a una función del servidor. Y simplemente se volverá pública. Lo cual es realmente genial. Es como un reemplazo para las rutas de API, si lo piensas. Pero todavía estamos experimentando con eso. No me lo tomes como definitivo. Eso es realmente genial.

La segunda parte de esto fue, ¿cómo manejas la desviación de la API y la observabilidad en las rutas de funciones? He visto muchas formas diferentes de manejar la desviación de la API. Quiero apoyar algunas de las más ingenuas donde es como, oh, algo salió mal, así que simplemente vamos a recargar y recuperar y hacer lo que podamos en el cliente, entre el cliente y el servidor. Pero también quiero apoyar algunas de las más sofisticadas. Funciones como Vercel tiene una que puedes enviar encabezados con solicitudes y se asegurará de que vaya determinísticamente a la versión correcta de la función del servidor que desplegaste. Así que hay muchos enfoques diferentes y queremos asegurarnos de poder apoyarlos todos. Genial.

Esta es, de lejos, la pregunta más formulada. Las dos principales son variaciones de ¿qué usaste para esta presentación? Es hermosa. Keynote. Keynote. Muy bien. Genial. Volviendo al contenido real. ¿Cuáles son las limitaciones de usar la gestión de estado en la URL? Hay un punto en el que puedes romper la URL. Tuvimos personas que saturaron la URL como 60 fotogramas por segundo, tratando de actualizar valores. Incluso añadí lógica para agrupar solicitudes en la URL, porque Safari es mucho más sensible a esto que otros. También puedes encontrarte con problemas de serialización. Tienes que almacenar cosas que sean relativamente simples de serializar en la URL.

Si almacenas demasiado en la URL, podrías tener URLs truncadas. Realmente hemos llevado los límites al máximo con Nozzle, compartiendo URLs de paneles con ocho widgets. El panel tiene sus propios controles que se están sincronizando todos en la URL. La URL es así de larga. Depende de dónde envíes esa URL. Algunos servidores pueden manejarlo, otros no. Solo ten en cuenta la truncación. Eso es más un límite de los sistemas y navegadores y no del router.

Claro. Esta es un poco sarcástica. ¿Puedes leer encabezados y cookies en el servidor en start paréntesis, a diferencia de next paréntesis? Genial. ¿En qué se diferencia TanStackQuery de RTKQuery? Oh, TanStackQuery, RTKQuery, no lo sé. Uno de ellos no está basado en Redux.

No sé cómo responder mejor a esa pregunta. Solo que así es como son diferentes. Esa es una diferencia bastante grande. OK. No sé quién hizo esta pregunta. Alguien llamado Theo, ¿cuándo obtendremos TanStackShop o es TanStackStop? ¿Cuándo obtendremos TanStackStop? Stop. Necesitas retirarte pronto, amigo. Nunca dejes de parar.

OK. Volvamos al contenido. ¿Cómo manejas la validación del tipo de estado en la URL? Validación del tipo de estado en la URL. Puedes manejarlo como quieras. Es enchufable. También estamos trabajando en un nuevo estándar de validación, por lo que muchas de las bibliotecas de validación están adoptando un nuevo estándar donde no necesitas usar un adaptador, así que puedes pasar cualquier tipo de validador que desees a una ruta, y podría ser un esquema Zod que diga, los parámetros de búsqueda necesitan verse así. O podría ser YUP, o podría ser Valobot, o Archetype, o lo que sea. E incluso admite establecer valores predeterminados y completar valores vacíos si es necesario. Hemos construido un sistema muy flexible para admitir tantos validadores como podamos.

Genial. Esta es la última pregunta de la lista, así que todos, ahora es un buen momento para hacer su pregunta a continuación. Si mi comprensión de la implementación correcta de RSC de TanStack tendrá la capacidad de renderizar solo partes de la UI en una ruta en lugar de volver a renderizar toda la página, ¿es eso correcto? Correcto. No planeo construir un router RSC-primero. Por favor, no me hagas hacer eso. Lo tendremos en cuenta. ¿Cómo manejas el secuestro del estado en la URL? Primero que nada, lo validas. Hay modos que puedes dar a tus validadores para descartar el estado incorrecto. Y en última instancia, lo manejas como cualquier otra entrada de usuario. Si lo envías al servidor, deberías validarlo en el servidor estrictamente solo para lo que necesitas y tener mucho cuidado con la inyección. Es solo otra caja de entrada en la ventana del navegador.

Eso es justo. Para el caso de uso empresarial, ¿qué empresas deberían usar TanStack Start y cuáles no? No lo sé. Si estás construyendo una aplicación React, probablemente deberías usar Start. Al menos el router. Eso es muchas empresas. Bueno, sí. Genial. Esta no es una pregunta. Es un salvavidas. Más uno.

Genial. Volvamos al contenido. ¿Puede TanStack Router funcionar en React Native con deep linking? Estamos trabajando en ello. TanStack Router, inicialmente lo escribí para que fuera agnóstico. Gran parte del núcleo no tiene nada que ver con React. Pero decidí unirlo todo y lanzarlo primero en React para obtener un producto y probar el concepto. Tan pronto como lancemos la versión 1.0 de Start, planeo investigar una estrategia basada en adaptadores para el router. Sé que sería muy sencillo para nosotros admitir React Native, definitivamente, y Solid también. Los otros, no estoy tan seguro. Estamos trabajando en otras características en el router muy pronto que nos ayudarán a tener paridad de características con algunos de los otros routers nativos que podrías esperar si los usas.

Esta es una pregunta para mí entonces. ¿Ves un mundo donde cada parte de él, digamos la UI, sea enchufable y jugable? ¿Podrías intercambiar React, Solid, y así sucesivamente? Absolutamente. Eso es realmente emocionante. Sí. ¿Cuál es la historia detrás del nombre TanStack? Bueno, sé que todos piensan que soy solo un maníaco egocéntrico. Pero la verdadera historia es que Sean Wang, o Swix, si lo conoces por Swix, me seguía llamando TanStack en React Rally hace como 6 años. No paraba. Me estaba molestando mucho. Y dije, oye, tengo un problema, porque React Query ya no va a ser solo React y no quiero marcarme a mí mismo con todos estos diferentes nombres de frameworks. Así que necesito un nombre comercial. Y él dijo, bueno, deberías usar TanStack. Y al principio lo resentí por eso hasta que lo busqué en Google. Cero competencia de SEO. Y realmente gran reconocimiento de marca. Puedes deletrearlo a la primera. Y tiene tres iniciales, tres letras de mi nombre ahí. Lo construí. Puedo poner eso ahí si quiero. Pero así es como surgió. Simplemente me incliné hacia ello.

Nadie lo está pronunciando mal. Sí. De acuerdo. Entonces, ¿puedo tener confianza para construir sobre TanStack Start y que estará presente en unos años? Sí. Me dediqué a tiempo completo a esto porque es a largo plazo para mí. No planeo ir a ningún lado. Así que voy a estar trabajando en esto durante bastante tiempo.

Ahora está en beta, lo que creo que denota que no planeamos romper nada más. ¿Deberías usarlo en producción? Quiero decir, ya hay personas usándolo en producción. Solo fíjalo a diciembre para que no se actualice automáticamente. Y prepárate para tener que migrar a través de algunos bordes ásperos. Si no quieres hacer nada de eso, entonces solo espera a que sea 1.0. Pero hemos estado lanzando TanStack.com en TanStack Start durante los últimos nueve meses. Lo cual es bastante genial. Eso es muy impresionante.

Gracias. Última pregunta. ¿Es TanStack open source? Sí. Eso fue un sí muy rotundo. Muchas gracias por el gran Q&A, a todos, y por supuesto, Tanner, también conocido como TanStack, muchas gracias. Esto fue fantástico.