No necesitas Next.js: por qué migramos de Next a React

• Resultados obtenidos al migrar el dashboard de ComfyDeploy de Next.js a React:
  • El tiempo de build se redujo de 3 minutos a 18 segundos
  • El hot reload mejoró a menos de 200 ms
  • El equipo quedó mucho más satisfecho
• Al principio empezamos con una aplicación full-stack usando Next.js, y gracias a Drizzle y Server Actions funcionaba bien con seguridad de tipos y código limpio, pero surgieron los siguientes problemas:
  • Un usuario específico generó altos costos de API en Vercel por $2,000
  • Mayor complejidad en las pruebas de API: mezcla de Server Actions y rutas de API
  • Tiempos de build lentos y un entorno de desarrollo local ineficiente
  • Incluso cambios pequeños provocaban una recarga completa de SSR
• Problemas
  • Mayor complejidad de Next.js: el enfoque all-in-one (full-stack) de Next.js provocó complejidad de desarrollo a medida que la app creció
  • Nuestro dashboard está basado principalmente en React y no necesita las funciones de servidor de Next.js
• Cambio de Next.js a React
  • Se hizo la transición de Next.js a React usando TanStack Router y Rspack
    • Inicio del servidor de desarrollo: menos de 2 segundos
    • Tiempo de build en Vercel: 18 segundos
  • Mejoramos la configuración de la API, eliminamos dependencias innecesarias y simplificamos el código, aumentando la productividad
• Comparación de rendimiento
  • Next.js 15 (usando modo Turbo)
    • Build de la primera página: 10.4 segundos
  • React + TanStack Router + Rspack
    • Cálculo de rutas: menos de 200 ms
    • Build del bundle inicial: 1.67 segundos
• Trade-offs
  • Lo que perdimos
    • Co-location del código de frontend y backend: al separar frontend y backend, los límites quedaron más claros
    • La funcionalidad de caché de Next.js: como tenemos muchos datos con actualizaciones en tiempo real, la reemplazamos por caché personalizada
    • Prerendering y carga inicial: en lugar de Static Generation, implementamos una mejor UX; ya no se muestran botones deshabilitados
    • Componentes y acciones de servidor: perdimos la “magia” de los server components, pero mejoramos con un diseño de API más intencional
  • Lo que ganamos
    • Mejor diseño de contratos de API
    • Implementación de caché solo donde hace falta
    • Diseño más cuidadoso del flujo de datos y la gestión de estado
• Conclusión
  • Next.js es adecuado para tareas como landing pages y SEO, pero para la mayoría de los productos introduce una complejidad excesiva
  • Seguimos usando Next.js para landing pages y trabajo de SEO
  • El dashboard se migró a Pure React + TanStack Router + Rspack
  • La API corre en un servidor Python FastAPI sobre Google Cloud Run y escala automáticamente según sea necesario
• Es importante elegir la herramienta adecuada, y para nosotros Next.js fue una opción excesiva

[zerocyber]

Justo cuando en nuestra empresa estábamos unificando/preparando la migración del frontend con Next.js, me encuentro con un artículo así y me deja pensando mucho....

[nemorize]

Solo operamos servicios donde es posible un enfoque mobile-app-first, así que en las áreas donde se necesita SEO ni siquiera usamos React (o algo similar) y las mantenemos muy ligeras.
La web la usamos solo como gancho para SEO y para dirigir a los usuarios a la app...

[beenzinozino]

"Elegir la herramienta adecuada es importante, y para nosotros Next.js fue una elección excesiva"

Creo que la última línea es la clave.

Para elegir la herramienta adecuada, también parece importante haber pasado por muchos fracasos de uno y otro tipo.

[iolothebard]

Si necesitas SEO, eso significa que el contenido es lo importante,
pero como los componentes de UI (?) y el estado ocupan el lugar central... nacieron extrañas criaturas como SSR, ISR, Hydrate...

[schang124]

Estoy bastante de acuerdo con esto.
Yo jamás adopto Next.js a menos que sea necesario por SEO.
Como en el artículo de arriba, cuando se usa solo React hay muchas ventajas:

• Desaparece la complejidad y los patrones innecesarios propios de Next.js.
  • El mantenimiento se vuelve más simple.
• Te libera de gastar innecesariamente en SSR.
• Se amplía la libertad de elegir librerías para la infraestructura de frontend, como el router, el bundler, etc.

[jhj0517]

No lo sé bien, pero al parecer hay mucha diferencia en el tiempo de compilación.

[bichi]

Parece que todavía no sabe que React sigue siendo mucho más lento que otros frameworks.

[slowandsnow]

No es porque la velocidad no importe. Si importara la velocidad, expressjs no se seguiría usando. La comunidad y las librerías son abrumadoramente más numerosas.

[devheerim]

Parece que se enfocan en migrar de Next a React jaja

[bbulbum]

No sé si es una decisión fácil ir contra esto, ya que la comunidad de React dejó de lado CRA en una etapa temprana y se pasó a los frameworks.

[sacru2red]

La mayoría se pasó a vite, y el framework se sigue usando según la necesidad, incluso ahora.

[bbulbum]

En react.dev dicen que recomiendan usar un framework cuando se construye una aplicación nueva o un sitio completo con React.

Por eso~

[kandk]

Qué curioso. ¿Next es más pesado que React? Solo he probado configurar proyectos con Next, y fue súper sencillo armar el proyecto y empezar a desarrollar.

[cichol]

"Simple" <= para lograr esto, hay magia(?) oculta que trae consigo muchas compensaciones.

[beenzinozino]

Estoy de acuerdo. Debajo de Next.js hay una cantidad enorme de dependencias ocultas...

[GN⁺]

Opiniones de Hacker News

• Mucha gente está demasiado enfocada en si una idea puede escalar a miles de millones de usuarios. Por eso a veces usan Kubernetes aunque su sitio web apenas tenga 5 visitantes. También he visto estudiantes usar Next.js para crear sitios web que podrían hacer simplemente con HTML + CSS

• Construí proyectos con Next.js, pero me pareció complicado de usar. Es confuso que la API de acceso a cookies sea distinta entre cliente y servidor, y que a las variables de entorno haya que acceder como process.env.NEXT_PUBLIC_*, entre otras cosas. Quería escribir código que funcionara tanto en cliente como en servidor con cambios mínimos, pero no fue así. Sentí que el aprendizaje y la sobrecarga no valían la pena para lo que ofrece Next.js

• La base de código se volvió más simple y las páginas renderizan más rápido. Es una pena que la comunidad esté siendo empujada innecesariamente hacia este tipo de frameworks. La mayoría de la gente solo necesita npx rsbuild init. Con rspack y rsbuild obtuve un router sencillo y una simplicidad hermosa

• Lo uso desde el lanzamiento de Next.js v14 y estoy muy satisfecho. Con RSCs, gran parte de la app sigue funcionando bien incluso si el JS del lado del cliente está desactivado. Tiene la fuerza de simplicidad de una app en PHP, y permite incluir de forma fluida el sistema de tipos y componentes de cliente interactivos basados en estado en el "nivel hoja" del árbol de vistas

• Gracias a Rails y Hotwire pude salir del caos del ecosistema de React. Hay demasiadas opciones: librerías de manejo de estado, meta-frameworks, librerías de data fetching, etc. No hace falta volver compleja la tarea simple de mostrar en una página datos que vienen del servidor

• Trabajo en un CMS que usa NextJS (PayloadCMS), y NextJS es la peor tecnología que he usado

• Casi todos los proyectos que usan frameworks/librerías pesadas de frontend como Next.js, React o Vue estarían mejor usando una librería que procese plantillas en el backend. A veces el renderizado del lado del cliente con EJS tiene sentido. Me pregunto por qué usan un framework

• Uso Next.js por SEO y optimización para crawling. Si una página no necesita ser rastreada (por ejemplo, un dashboard detrás de login), entonces no hace falta Next.js y React puro sería más simple

• Me sorprende que Next.js se haya convertido en la opción inicial por defecto. Se siente como un cambio grande comparado con hace 2 o 3 años

• Estoy intentando reemplazar una app de NextJS usando Vike, y estoy satisfecho. Puedo construir a mi manera sin que se interponga

[aer0700]

Kubernetes para una app con 5 usuarios... impresionante.