El debate sobre qué framework elegir para construir aplicaciones en React suele centrarse en rendimiento en producción, SEO o facilidad de despliegue. Sin embargo, en muchas compañías la batalla real se libra antes: en el tiempo que tarda el equipo en arrancar el entorno local, navegar por el dashboard y validar cambios sin que el flujo de trabajo se convierta en una sucesión de esperas. Con esa idea como telón de fondo, Inngest ?una plataforma enfocada en aportar durabilidad a flujos serverless y arquitecturas event-driven? ha contado públicamente por qué decidió migrar su interfaz desde Next.js hacia TanStack Start, y cómo esa decisión recortó el tiempo de desarrollo local en un 83 %.
La historia, publicada a finales de enero de 2.026 por el equipo de ingeniería, parte de un principio que en Inngest tratan como norma interna: la experiencia de desarrollador no es un detalle estético, sino una ventaja competitiva. Si el producto exige APIs limpias y ergonómicas para que los clientes construyan rápido, el equipo también necesita sentir lo mismo al ?construir Inngest?. Separar ambas experiencias, vienen a defender, es casi imposible.
Cuando la promesa de Next.js empieza a pesar
Según el relato, Inngest fue un adoptante temprano de la nueva etapa de Next.js: se subió al App Router cuando aún estaba en beta, migró desde Vite en apenas un día y asumió que los React Server Components (RSC) representaban el futuro del ecosistema. La propuesta era seductora: evitar los ?pantallazos en blanco? típicos de muchas SPAs, reducir cascadas de red, aprovechar layouts anidados y streaming de forma nativa, y unificar en un único marco de trabajo lo que antes se repartía entre herramientas.
El problema, explica la compañía, es que Next.js optimiza muy bien un patrón concreto: equipos front-end dedicados que viven dentro del framework a jornada completa. En un grupo pequeño, donde la mayoría de ingenieros alternan funciones y tocan varias partes del producto, la fricción acumulada se volvió una carga difícil de justificar. Directivas como ?use client? y ?use server?, APIs de caché por capas y fronteras difusas entre RSC y componentes cliente elevaron el ?coste cognitivo? hasta el punto de que, para algunos perfiles, la sensación era estar peleándose con el framework más que entregando funcionalidad.
El síntoma que lo desencadena todo: la lentitud local
Como primera medida, el equipo intentó reducir su dependencia de RSC y priorizar componentes cliente, dejando un uso mínimo de componentes de servidor. La maniobra alivió parte de la complejidad, pero el siguiente golpe llegó por el lado menos glamuroso y más determinante: el rendimiento en desarrollo local.
Inngest relata que las primeras cargas de página en local se dispararon a un mínimo de 10-12 segundos. No era una queja ocasional; era un patrón repetido que, según cuentan, terminó cristalizando en mensajes recurrentes en Slack de frustración abierta con la lentitud del front-end. El diagnóstico interno fue directo: su propia experiencia de desarrollo se había convertido en un problema.
Turbopack no fue ?turbo? (al menos para su caso)
Con el objetivo de salvar la inversión ya realizada, el equipo actualizó Next.js y probó herramientas de perfilado de Vercel para identificar cuellos de botella. No funcionó. Luego llegó el intento con Turbopack? dos veces. La doble migración, describen, no fue trivial: exigió actualizar dependencias, refactorizar partes del código y, además, introdujo un inconveniente operativo importante: durante ese periodo el entorno local y el de producción no eran equivalentes, porque la plataforma de despliegue seguía apoyándose en Webpack para construir builds de producción.
El resultado final fue decepcionante: se ganaron apenas un par de segundos en tiempos de carga local, insuficiente para cambiar la dinámica del día a día. Con esa evidencia, Inngest concluyó que había llegado el momento de mirar fuera de Next.js.
Tres alternativas sobre la mesa: TanStack Start, Deno Fresh y React Router v7
En la evaluación, Inngest buscaba tres cosas muy concretas: arranque local más rápido, una API de router sensata y convenciones claras para separar lo que vive en servidor de lo que vive en cliente. Para ello prototipó con TanStack Start, Deno Fresh y React Router v7 (en la práctica, el heredero funcional del enfoque Remix).
El análisis, según describen, no encontró ?descalificadores? inmediatos en ninguno. Deno Fresh destacaba por su rendimiento y por un enfoque TypeScript-first atractivo, pero el largo intervalo entre su versión 1 y 2 generaba dudas. React Router v7 aportaba madurez y el peso de lo ?probado en batalla?, aunque los vaivenes de Remix (su integración y posterior separación en el entorno React Router) también invitaban a prudencia. TanStack Start, por su parte, se encontraba en fase release candidate ?y seguía estándolo en el momento de escribir el artículo?, lo que en otros contextos habría sido una bandera roja.
Por qué ganó TanStack Start: entusiasmo como factor técnico
La decisión final fue apostar por TanStack Start, una elección que Inngest reconoce como poco ?convencional? si se mira solo el estado de madurez. Pero aquí aparece un factor que muchas veces no figura en comparativas: el equipo ya utilizaba otras librerías de TanStack y confiaba en su dirección. Y, en palabras del propio relato, cuando la experiencia de desarrollo importa, que los desarrolladores estén motivados también importa.
TanStack, en paralelo, ha ido consolidando su posición como ecosistema de herramientas abiertas para el desarrollo web: su web oficial muestra más de 5.879.265.404 descargas en NPM, 118.918 estrellas en GitHub, 3.005 contribuidores y 1.304.800 proyectos dependientes. En lo específico, TanStack Start se presenta como un framework full-stack basado en TanStack Router y Vite, con SSR de documento completo, streaming y ?server functions?; y su propia página pública refleja 51.866.525 descargas en NPM, 13.413 estrellas y 676 contribuidores en GitHub.
La migración: arrancar la tirita de golpe
Una vez elegido el destino, Inngest tuvo que escoger el método: migración incremental o ?arrancar la tirita? de una vez. El enfoque incremental exigía convivencia de rutas, importaciones condicionales y un trabajo adicional de infraestructura por la dependencia de utilidades propias de Next.js. La alternativa brute force prometía velocidad, a cambio de asumir pull requests enormes difíciles de revisar de manera tradicional.
Ganó el método drástico. Inngest tenía dos ?cabezas? de aplicación en Next.js: un servidor de desarrollo y un dashboard. Empezaron por el primero, con un subconjunto de rutas, y el ritmo fue tan rápido que continuaron hasta convertirlo todo en unos pocos días: el servidor de desarrollo quedó migrado en aproximadamente una semana. El dashboard ?con más rutas y mayor complejidad? se alargó algo más, pero el esfuerzo total se mantuvo en el rango de ?un par de semanas? para un solo ingeniero, con ayuda de Inteligencia Artificial.
Resultados: de 10-12 segundos a 2-3 segundos
Tras el cambio, la compañía asegura que su experiencia de desarrollo mejoró de forma ?dramática?. La carga inicial local rara vez superaba los 2-3 segundos y, en muchos casos, solo en la primera ruta; el resto tendía a ser prácticamente instantáneo. En contraste, sostienen que con Next.js la primera carga local de cualquier ruta solía ser lenta de forma sistemática.
El precio del nuevo enfoque fue un cambio de filosofía: se pasó de un modelo ?convención sobre configuración? (a veces mágico y confuso, según su experiencia) a uno explícito y prescriptivo, con configuración de rutas y loaders de datos más visibles. Es decir: menos automatismo opaco, más claridad en qué se ejecuta en servidor y cómo se consume en cliente.
La Inteligencia Artificial, como herramienta de ?trabajo pesado? y control de riesgos
Inngest describe un uso muy pragmático de la Inteligencia Artificial. No la emplearon para decidir arquitectura, sino para acelerar tareas repetitivas: convertir rutas una vez definidos patrones, replicarlos a rutas similares y ayudar a resolver errores raros o problemas de TypeScript. El equipo revisaba lo producido, lo limpiaba y repetía el ciclo. Con esa estrategia, limitaron el tiempo dedicado a ?pozos sin fondo? y mantuvieron el impacto sobre el desarrollo de nuevas funcionalidades en niveles bajos: solo se bloqueó el avance de features durante dos o tres días en la fase final de fusión y pruebas de aceptación.
La compañía admite, eso sí, que el enfoque de grandes PRs obliga a compensar con pruebas intensivas y que llegaron a encontrarse con un caso lo bastante serio como para justificar un rollback inmediato, en un flujo de integración difícil de replicar fuera de producción. Con esa lección, concluyen que el enfoque incremental solo compensa en entornos extremadamente adversos al riesgo.
Por último, Inngest ha publicado el resultado de su migración como código abierto en su monorepo de UI, ofreciendo a otros equipos una referencia tangible de cómo se ejecuta un cambio de esta magnitud cuando el objetivo no es ?estar a la moda?, sino recuperar velocidad y salud operativa.
Preguntas frecuentes
¿Por qué una aplicación en Next.js puede volverse lenta en desarrollo local con App Router y React Server Components?
En proyectos grandes, la combinación de nuevas capas (RSC, separación servidor/cliente y mecanismos de caché) puede aumentar el trabajo de compilación y la complejidad del entorno, elevando los tiempos de primera carga local y la fricción del flujo de desarrollo.
¿TanStack Start es una alternativa real para migrar desde Next.js en 2.026?
TanStack Start se encuentra en fase release candidate y se orienta a SSR, streaming y ?server functions? con un modelo de rutas explícito. Puede ser atractivo para equipos que priorizan claridad y rapidez local, aunque conviene evaluar madurez y necesidades concretas antes de adoptarlo.
¿Qué papel puede jugar la Inteligencia Artificial en una migración de framework en React sin comprometer la arquitectura?
Puede acelerar la conversión repetitiva de rutas y componentes cuando el equipo ya ha definido patrones claros, además de ayudar a resolver errores específicos. La clave está en usarla como apoyo para tareas mecánicas y mantener revisión humana para consistencia y calidad.
¿Qué alternativas a Next.js suelen compararse en migraciones full-stack con React?
Además de TanStack Start, suelen aparecer opciones como React Router v7 (con herencia de patrones tipo Remix) y Deno Fresh, cada una con enfoques distintos en ejecución, enrutado, despliegue y convenciones de servidor/cliente.